MYOB has no webhooks. Everything is polling, and that changes the design.

What the MYOB API does and does not allow

The other ledger. Long-established in Australian trade and manufacturing, with a desktop lineage that still shows in the API.

Everything in the strip above is MYOB’s own published documentation, fetched 1 September 2026 and linked to the page it came from. We have not paraphrased it into something friendlier, because the exact wording is what you need when a limit bites at four in the afternoon.

What follows is what those facts mean for a build — the constraints that change a design decision rather than the ones that are merely true. If you want the same treatment for the other eight systems side by side, that is the capability register. If you want to know whether we have built against both sides of a particular pairing, the integration checker answers that specific question.

No webhooks means a polling loop, and a polling loop has a budget

This is the defining fact about integrating MYOB and it is worth sitting with. Every other accounting system in our register can tell you the moment something changed. MYOB cannot. You find out by asking, repeatedly, and the answer is usually nothing.

MYOB’s own recommendation is to poll with an OData filter on LastModified, which works and is the right approach. The cost is that responsiveness becomes a dial you set rather than a property you get. Poll every five minutes and you have spent 288 requests a day per resource doing nothing. Poll every hour and a customer waits an hour.

The awkward part is that MYOB does not publish how much room you have. You are budgeting against a ceiling whose height is not documented. In practice this pushes the design toward fewer, wider requests — one filtered pull covering several record types on a schedule, rather than many narrow ones — and toward being honest with the client that "instant" is not on the menu here.

• Set the interval against the decision A supplier bill can wait an hour. A customer waiting on a quote cannot. Poll different things at different rates rather than picking one number for everything.
• Filter server-side, always $filter on LastModified with a stored watermark. Pulling everything and comparing locally works right up until the client has three years of history.
• Handle 403 as a rate limit Not as a permissions failure. Generic HTTP clients get this wrong by default and stop retrying entirely.

The desktop lineage still shows, and it is not all bad

MYOB serves cloud files and locally hosted AccountRight files through the same API, differing mainly in headers — bearer tokens and a company-file token for cloud, basic auth for local. That is genuinely useful in Australian trade and manufacturing, where a surprising number of businesses still run a file on a machine in the office because it has always been there and it works.

It also means an integration has to know which it is talking to, and that the two are not interchangeable in behaviour. The pagination is generous — 400 records by default and up to 1,000, which is four times Xero’s default — and the OData filtering is more expressive than most of the register. Those are real advantages that get overlooked because the webhook gap is louder.

The 29-second request timeout is the one to design around. It is short for a report-shaped query on a large file, and MYOB explicitly tells developers to adjust their code to it rather than treating it as a fault.

Rate limits and what breaks at scale

We cannot tell you MYOB’s rate limits, because MYOB does not publish them. What is documented is the shape of the failure: a per-second limit and a daily limit, both returning HTTP 403 with a message naming which one you hit, and no Retry-After header to tell you how long to wait.

That combination is genuinely hostile to a naive integration. A 403 reads as "you are not allowed to do this" to every HTTP library and most developers, so the usual response is to stop and log an authentication error. The sync appears to have broken for a permissions reason, someone re-authorises it, and it works again — until the next busy hour.

What breaks at scale, then, is not throughput so much as diagnosis. Build MYOB integrations with explicit handling for the two documented error strings, exponential backoff on both, and an alert that says "rate limited" rather than "auth failed". And build the initial historical sync as a resumable job, because you will find the ceiling during it.

What MYOB does not publish

5 of the thirteen fields we track are simply absent from MYOB’s documentation: the rate limit, what happens when a webhook delivery fails, how to verify an event actually came from them, any bulk or batch limit and where your client’s data physically sits.

This is the part of an integration page that competitors leave out, and it is the part that costs money. An undocumented rate limit is not an academic gap — it means the first time you find the ceiling is in production, on someone else’s business, usually on the busiest day of their month.

We are not going to fill these in with figures from a forum thread. Numbers circulate for most of them, and some are probably right, but we cannot show you where they came from and neither can the person who posted them. When we have measured MYOB properly under load, those figures will appear here with the date we measured them and the conditions we measured them under. Not before.

What we have built, and what we have not measured

We have implemented against MYOB in production. That is a real fact and it is also a limited one — it tells you we have solved this system's problems before, and it does not tell you how fast, how reliably, or at what volume.

The honest position is this. Everything on this page above the line is the vendor's published documentation, which we fetched, dated and linked rather than paraphrased. Nothing on this page is a Kindra measurement, because our measured register is not finished and publishing half of it dressed up as all of it would make this page less useful, not more.

What we would do on an engagement is measure the specific things that matter for your build — the endpoints you depend on, at your volume, with your data — and hand you those numbers whether or not they suit us. If they say the integration is harder than we quoted, you get told that too. Start with a Leak Check, or read how we work first if you would rather know the shape of it before talking to anyone.