A wall of illuminated ledger drawers in a port records room
Research · updated 1 September 2026

Thirteen facts about nine systems. And the 30 nobody publishes.

A register of what Australian small business software actually documents about its API — auth, rate limits, pagination, webhooks, verification, retries, bulk, sandbox, data location and cost. Every entry is the vendor’s own wording, fetched 1 September 2026 and linked. Where a vendor publishes nothing, the cell says so.

How to read the register

Nine systems down the side. Thirteen fields across, though the wide table below shows the five that change a design decision most often — the rest are on each system’s own page. Every value is quoted from the vendor’s documentation and linked to the page it came from, so nothing here has to be taken on trust.

The most useful cells are the empty ones. When a vendor does not publish its rate limit, that is not a formatting problem — it means the first time anyone finds the ceiling is in production, on a real business, usually on the busiest day of the month. We mark those rather than filling them in with a number from a forum thread.

Everything was fetched on one day, 1 September 2026. Three entries were changing that week, which is exactly why the date is on every cell rather than at the bottom of the page.

What we mean by tested

Two different claims get blurred together on pages like this one, so here they are separated.

  • Documented — what this page has The vendor’s published behaviour, fetched, dated and linked. Anyone can verify it. It is genuinely useful, and it is not a measurement.
  • Built against — what we can also say We have implemented against all 9 of these in production. That tells you we have solved each system’s problems before. It does not tell you a number.
  • Measured — what this page does not have Observed limits under load, real failure modes, what breaks at what volume, date last tested. That column is empty today. Publishing a plausible figure in it would make this whole register worthless, because you would have no way to tell which cells were real.
Nine containers connected by glowing conduits
Nine systems. The interesting part is always the three that were rerouted by hand.
The register · fetched 1 September 2026

The register — five of thirteen fields

Five fields shown here. Each system’s page carries all thirteen, plus the vendor-flagged constraints that actually change how you build.

Nine systems, five fields, fetched 1 September 2026 from vendor documentation. Empty cells are absences in the source, not omissions here.
System Rate limit Webhooks Event verification Pagination Gaps
Xero Accounting 5 concurrent calls, 60 calls per minute and 5,000 calls per day per tenant on Core tier and above — 1,000 per day on the free Starter tier Yes HMAC-SHA256 of the payload against your signing key, base64 encoded, compared to the x-xero-signature header Page size defaults to 100, maximum 1,000 1 of 13
MYOB Accounting Not published No Not published OData-style $top and $skip 5 of 13
QuickBooks Online Accounting 500 requests per minute per realm, 10 concurrent requests per second per realm and app, and 40 batch requests per minute per realm Yes HMAC-SHA256 of the raw payload keyed with your verifier token, base64 encoded, compared to the intuit-signature header Offset-based, inside the query language: STARTPOSITION and MAXRESULTS 2 of 13
ServiceM8 Job management 180 requests per minute and 20,000 per day, applied per application per account — so two client accounts get a separate allowance each Yes A subscribe-time challenge and echo, not a per-payload signature Cursor-based 4 of 13
Simpro Job management 10 API requests per second per client build Yes SHA1 HMAC hexdigest of the request body in an X-Response-Signature header, keyed with a secret you set on the subscription Page and pageSize parameters 3 of 13
Stripe Payments 100 requests per second in live mode, 25 in a sandbox, and 25 per second on individual endpoints Yes HMAC-SHA256 over timestamp plus a full stop plus the raw body, in a Stripe-Signature header Cursor-based: limit, starting_after, ending_before 2 of 13
GoHighLevel CRM and marketing 100 requests per 10 seconds burst, and 200,000 a day — counted per marketplace app per resource, where a resource is one location or one agency Yes Ed25519 signature in an X-GHL-Signature header, against a published public key Per endpoint rather than platform-wide 4 of 13
Zapier Automation platform 20,000 webhook requests per 5 minutes per user on instant triggers Yes Not published Zapier hands your integration a zero-based bundle 5 of 13
n8n Automation platform None published for the API Yes Basic auth, header auth, JWT auth or none Cursor-based, with a nextCursor on the response 4 of 13

Three findings fall straight out of it. 1 of the nine has no webhooks at all, which turns every integration with it into a polling loop with a running cost. 2 sends webhooks it does not sign, so the only safe pattern is to treat the event as a hint and trust the follow-up fetch. And 6 of the nine publish where your client’s data physically sits — two of them state plainly that it is the United States, and none offers an Australian region.

Where ‘no API’ still has a path

Two of the nine are automation platforms rather than systems of record, and they exist precisely because the answer to “does this thing have an API” is often no. Worth knowing what the fallbacks actually are before concluding a system cannot be integrated.

  • A published export is an integration A nightly CSV to a watched folder is unglamorous, hard to break, and enough for most reporting. It is not real-time, and it is usually the right first step rather than the compromise.
  • Email is an interface Systems that will not talk will still send a notification, a statement or a report. Parsing those is fragile in a way an API is not — but it is a path, and sometimes it is the only one.
  • The other side may have the API Integration needs one endpoint, not two. If the closed system can push a webhook or send a file, the open system can do the rest of the work.
  • When the honest answer is no Some systems genuinely cannot be automated without screen-scraping, and we do not build that — it breaks on a UI change nobody told you about. We will say so and the engagement stops there.

System glue covers the shape of this work in more detail, and the integration checker answers the narrower question of whether we have built against both sides of a particular pairing.

Systems we haven’t tested yet

Everything not in the table above. Tradify, AroFlo, Fergus, Buildxact, Ascora, Reckon, Sage, HubSpot, Salesforce, monday.com and every vertical product for a trade we have not worked in. Some of them publish excellent documentation. We have not built against them, so they are not here.

That is a deliberately narrow rule and it costs us pages. It would be easy to read Tradify’s help centre and add a row — but that row would say the same thing our comparison pages say about products we have not implemented, and this register is supposed to be the place where the bar is higher than that.

Tell us about a system we’re missing

If you run something not listed and you want to know whether it can be joined to the rest of your stack, that question is free to ask and usually quick to answer. Ring 0403 475 099 or email hello@kindraai.dev — we will tell you what its documentation says, and whether the answer is a build, a platform, or leaving it alone.

The register is published under CC BY 4.0 and available as machine-readable JSON. Reuse it, including commercially, as long as Kindra AI is credited and the fetch date travels with the figures — a rate limit without a date is worse than no rate limit.

Objections · answered straight

Before you ask.

Is this just vendor documentation rewritten?

Partly, and deliberately. Every fact here is the vendor’s own published documentation — that is the point, because it means you can check all of it against the link beside it. What is not in any vendor’s documentation is the comparison: thirteen identical fields across nine systems, fetched on one day, with every gap marked rather than quietly skipped. No vendor publishes a competitor’s limits beside their own, and nobody at all publishes the absences.

Why aren’t more systems listed?

Because these are the nine we have implemented against. Reading a vendor’s documentation is something anyone can do in an afternoon; we would rather the register only cover systems where we have also had to make one work at two in the morning. It grows when our experience does, which is slower and worth more.

Free 20-minute meeting

Stop bending.
Start shipping.

Bring the one flow that keeps costing you a Tuesday afternoon. We map it live and tell you what we'd build, what we wouldn't, and what it costs.

Book a meeting How we charge
Call0403 475 099 Emailhello@kindraai.dev

20 minutes. We find where the money's going. No pitch.