Comparison · the integration axis
As accounting packages, both are mature and the right answer depends on your bookkeeper. As things to connect to, they differ sharply: Xero publishes four rate limits and sends webhooks on six record types, MYOB publishes no rate limit figures and no webhooks at all. Both now charge developers for access.
It is not a features comparison. We have not audited either product as an accounting package, we do not know your chart of accounts, and your bookkeeper’s preference is a better guide to that question than anything we could write. Most pages that rank these two are either affiliate content or a partner writing about their own platform.
What we can compare, from documentation both vendors publish and we have linked, is the axis that decides whether the rest of your systems can talk to your ledger. That axis is rarely discussed and it is the one that costs money for years after the choice.
If nothing else will ever touch your accounting system, this page is not relevant to you and you should ignore it. If a job management system, a payment gateway, a spreadsheet or an automation is ever going to read from or write to it — which is most businesses within three years — this is the comparison that matters.
Xero sends webhooks. Contacts, invoices, credit notes, overpayments, prepayments and subscriptions, on create and update, signed with an HMAC, retried for 24 hours and replayed for up to 31 days if your endpoint was down. So a system that needs to react when an invoice is paid finds out within seconds and costs nothing while nothing is happening.
MYOB does not. Its own support documentation answers the question directly: it does not currently support webhooks, and recommends polling with an OData filter on LastModified instead. That works, and it is a materially different piece of engineering with a materially different running cost.
Polling means a loop that runs whether or not anything changed. Every five minutes is 288 requests a day per resource, most of them returning nothing. Responsiveness stops being a property you get and becomes a dial you set — and every notch you turn it costs requests against a ceiling MYOB does not publish the height of.
Xero publishes four: five concurrent calls, sixty a minute, five thousand a day per organisation on the Core tier and above, and ten thousand a minute across all your connected organisations. Exceed one and you get HTTP 429, a header naming which limit you hit, and — on two of the four — a Retry-After telling you how long to wait.
MYOB publishes none. Not a per-second figure, not a daily figure, nowhere in its developer centre or its API support site. What it does publish is the failure: HTTP 403, with a body saying the API key has exceeded either the per-second or the daily rate limit, and no Retry-After.
The 403 deserves its own sentence, because it is the difference between a limit and a trap. Every HTTP client and most developers treat 403 as a permissions error and stop retrying. An MYOB sync that hits its unpublished ceiling looks exactly like an authorisation failure, so somebody re-authorises it, it works, and it happens again next month.
| Xero | MYOB | |
|---|---|---|
| Rate limit published | Yes 5 concurrent, 60/min, 5,000/day per organisation on Core and above; 10,000/min app-wide. | No No figure anywhere in the documentation. Only the error strings and a 403. |
| Standard 429 on limit | Yes 429 with X-Rate-Limit-Problem, and Retry-After on the minute and daily limits. | No HTTP 403, which generic clients read as a permissions failure and stop retrying. |
| Webhooks | Yes Six record types, create and update, HMAC-SHA256 signed. | No Not supported. MYOB directs you to poll with a $filter on LastModified. |
| Replay after your endpoint fails | Yes Held for up to 31 days and replayed in order once the subscription is healthy. | Not assessed Nothing to replay. A wider polling window catches whatever was missed. |
| Refresh token lifetime | Yes 60 days unused, rotating on use, with a 30-minute grace period on a failed refresh. | Partly Up to one week, reduced from one year in January 2020. Rotates on use. |
| Page size | Partly 100 default, 1,000 maximum — but only nine endpoints paginate at all. | Yes 400 default, 1,000 maximum, with OData $top, $skip, $filter and $orderby. |
| Free for a developer to connect | Partly Starter tier is free to five organisations. Beyond that, $35 to $1,445 AUD a month since 2 March 2026. | No Developer program is $110, $220 or $630 a month including GST. No free tier published. |
Xero refresh tokens last 60 days if unused. MYOB refresh tokens last one week — reduced from a year in January 2020, a change MYOB footnotes on its own page.
That sounds like trivia and it is an operational fact. Any integration that goes quiet for eight days needs a human to log in and re-authorise it. A seasonal business over the Christmas shutdown, a client who takes a fortnight off, a workflow paused while someone thinks about it — all of those break an MYOB connection and none of them break a Xero one.
It is fixable. You keep the token warm with a scheduled refresh whether or not there is work to do. But it is a thing you have to remember to build, and if the person who built your integration did not know about the 2020 change, they did not build it.
This is the newest fact on the page and the one most likely to be missing from advice you read elsewhere. Xero made its API a paid, tiered product on 2 March 2026: free to five connected organisations on Starter with 1,000 calls a day, then $35, $245 or $1,445 AUD a month, with a metered data egress allowance on top and overage at $2.40 a gigabyte.
MYOB’s developer program has three paid tiers — $110, $220 and $630 a month including GST — with no free tier published at all.
For a single business connecting its own ledger, Xero is free and MYOB is not, which is a genuine difference. For anyone building something that connects many organisations, both carry a real monthly cost that belongs in the quote rather than turning up in month three. If somebody has quoted you an integration without mentioning either, ask them when they last checked.
If you are choosing today and you know other systems will connect to it: Xero, on the strength of webhooks and published limits. That is not a close call on this axis, and it is the only axis this page is competent to judge.
If you already run MYOB: this is not a reason to move. Migrating an accounting file is expensive, disruptive and occasionally goes wrong, and a polling integration against MYOB is perfectly workable — it just needs to be built by someone who knows about the 403, the one-week refresh token and the undocumented ceiling. Changing your ledger to make an integration tidier is almost always the more expensive choice.
If your bookkeeper strongly prefers one of them: listen to your bookkeeper. They use it every day and you do not. An integration inconvenience is a one-off engineering cost; the wrong accounting package is a daily one. The accounting software page covers the wider question, and build versus buy covers the one underneath it.
Everything you would normally want from a comparison of these two. Bank feed reliability, payroll, GST and BAS handling, inventory, reporting, the mobile apps, support response times, and how either behaves with a messy file. We have not tested any of it, and neither has most of what you will find written on the subject.
We also have not measured either API under load. Everything above is documented behaviour, fetched on one day and linked, and documented behaviour is not the same as observed behaviour. When our measured register exists those figures go here with the date they were taken.
If you want a view on the accounting side, ask an accountant who works with Australian trade businesses. That is a real specialisation and it is not ours.
No — and we would say so if we thought otherwise, since a migration is work we could charge for. Moving an accounting file is expensive and occasionally goes wrong, and an MYOB integration built properly works fine. The switch only makes sense if you were already unhappy with MYOB for accounting reasons, in which case the integration advantage is a tiebreaker rather than the argument.
Possibly, and we would genuinely like to be corrected. We searched MYOB’s developer centre and its separate API support site and found the error strings but never the figures. Numbers do circulate in MYOB community forum threads and some are probably right — but a forum post is not a source we can put our name to, and neither is a competitor’s blog. If MYOB publishes them somewhere we missed, tell us and we will link it.
20 minutes. We find where the money's going. No pitch.
Book a free Leak Check