AroFlo publishes its API and caps it at 2,000 calls a day. We have not built against it, and here is what the documentation says.
AroFlo’s public API allows 3 requests a second, 120 a minute and 2,000 a day per organisation, signed with an HMAC on every request, with no webhooks, no batch endpoint and no published sandbox. We have not implemented against AroFlo. Everything on this page is AroFlo’s own documentation, fetched 3 September 2026.
What AroFlo publishes about its API
- Documentation
- Yes — apidocs.aroflo.com is readable without a login. API access must then be enabled per user in Site Administration, and the secret key is shown once. AroFlo API documentation, fetched 3 September 2026.
- Authentication
- An HMAC-SHA512 signature generated for every request, over encoded username, encoded key and encoded organisation values plus an afdatetimeutc header, sent in Authentication and Authorization headers. No OAuth. The timestamp must fall within a window of server time that AroFlo does not size. AroFlo API documentation, fetched 3 September 2026.
- Token lifetimes
- Not published.
- Rate limits
- 3 requests per second, 120 per minute and 2,000 per day, with a secondary daily limit of 20,000 for queries that fetch a single record by zone ID. All reset at 00:00 Australia/Melbourne time. AroFlo API documentation, fetched 3 September 2026.
- When you exceed one
- HTTP 429 for the per-second limit. The per-minute and daily limits return AroFlo status codes 6 and 7 — "Exceeded Rate Limit - Requests per Minute" and "Exceeded Rate Limit - Daily". Six X-RateLimit headers report the minute, daily and secondary-daily limits and what remains. AroFlo API documentation, fetched 3 September 2026.
- Pagination
- pageSize parameter, maximum 500 results per page, with currentpageresults, maxpageresults and pagenumber in every response. Responses are also capped at 3.5 MB and queries at 60 seconds. AroFlo API documentation, fetched 3 September 2026.
- Webhooks
- No. The API documentation contains no webhook, callback or push mechanism. The help centre lists a Zapier integration alongside the API. AroFlo API documentation, fetched 3 September 2026.
- Event verification
- Not published — no payload signature scheme.
- Retry behaviour
- Not published — no retry policy.
- Bulk operations
- None. Inserts and updates are separate operations and each must be sent as its own call. Default response format is XML; JSON requires Accept: text/json. AroFlo API documentation, fetched 3 September 2026.
- Test environment
- Not published — no sandbox terms.
- Data location
- Not published — the vendor does not say where the data is stored.
- Cost of API access
- Not published as a separate charge. AroFlo publishes no plan prices at all — the pricing page names one plan, AroFlo Premium, and a Request Pricing button. AroFlo pricing, fetched 3 September 2026.
Every line above is the vendor’s own documentation, fetched 3 September 2026, linked so you can check it yourself. 5 of the 13 fields are not published at all — those are marked, and they are the ones that cost you time. The full capability register puts this beside the other systems.
What the AroFlo API does and does not allow
Melbourne-built job management for trade and service crews, part of the Simpro Group since late 2021. The API is public, HMAC-signed and metered at 2,000 calls a day. We have not built against it.
We have not built against AroFlo. That is the first thing to say and it shapes everything after it: this page ranks nothing, measures nothing and recommends nothing on experience. What it does is put AroFlo’s own published API documentation — fetched 3 September 2026, linked line by line — beside the systems we have built against, so you can see the shape of an AroFlo integration before anyone quotes one.
That comparison is useful precisely because AroFlo does publish. Its API documentation is public, readable without a login, and specific about limits in a way several better-known systems are not. Five of the thirteen fields we track are absent, and they are marked. The capability register shows the same thirteen for every system, and our job management round-up explains why AroFlo is described there rather than ranked.
Two thousand calls a day is the design constraint
AroFlo allows 3 requests a second, 120 a minute and 2,000 a day, with a secondary daily allowance of 20,000 for queries that fetch a single record by zone ID — a GET for one task by TaskID, for example. All three reset at midnight Melbourne time (AroFlo API documentation, fetched 3 September 2026).
Put that beside the systems in this cluster. ServiceM8 allows 20,000 a day per app per account (ServiceM8 response codes, fetched 1 September 2026). Simpro allows 10 a second with no daily cap. AroFlo’s general allowance is a tenth of ServiceM8’s, and the 20,000 only helps once you already know which record you want.
What that forces is a particular shape. A five-minute polling loop over three zones spends 864 of the 2,000 by itself doing nothing. So an AroFlo integration is built as wide, filtered pulls on a schedule — the WHERE syntax supports =, <, >, !=, IN and NOT IN, pipe-separated — with pagination at up to 500 records a page under a 3.5 MB response cap and a 60-second query timeout. Live is not on the menu. The documentation says so in numbers, and the client should hear it in the first meeting.
- KNDR·01Pull wide, pull rarelyOne filtered request per zone per interval, sized against the 500-a-page and 3.5 MB caps. A LastModified-style filter with a stored watermark, where the zone supports it.
- KNDR·02Spend the 20,000 on look-ups, not the 2,000Single-record fetches by zone ID draw on the secondary allowance. Design so that the expensive general queries find the IDs and the cheap ones fetch the detail.
- KNDR·03Watch three different limit signalsPer-second is an HTTP 429. Per-minute and daily are AroFlo status codes 6 and 7 inside a normal HTTP response. Read the X-RateLimit headers and stop before any of them.
HMAC on every request, and no OAuth
AroFlo does not use OAuth. Every request carries an HMAC-SHA512 signature computed over encoded username, key and organisation values plus an afdatetimeutc header, and the API secret key is shown exactly once when it is generated in Site Administration (AroFlo API documentation, fetched 3 September 2026). Access has to be enabled for the specific user, or the API returns "User logged in, but has no AroFloAPI Access enabled".
This is a perfectly workable scheme and it is older than the OAuth flows on Xero or ServiceM8. The operational difference is that there is nothing to refresh and nothing that expires — which is convenient — and also that the integration runs as a named AroFlo user with that user’s permissions, so the user you create for it matters. Give it what it needs and nothing else.
The one thing to get right on day one is the clock. The signature includes a UTC timestamp and AroFlo allows "a small window of difference" from server time without saying how small. A server drifting by a couple of minutes fails authentication in a way that looks exactly like a wrong key, and you will spend an afternoon on it unless you know.
Rate limits and what breaks at scale
The failure modes are documented, which is more than MYOB manages. Exceed 3 a second and you get an HTTP 429 with "Too Many Requests Per Second (max x3)". Exceed 120 a minute and the response carries AroFlo status code 6; exceed 2,000 a day and it carries status code 7. Six response headers — X-RateLimit-Limit, -Remaining, -Daily-Limit, -Daily-Remaining, -Secondary-Daily-Limit and -Secondary-Daily-Remaining — tell you where you stand on every call (AroFlo API documentation, fetched 3 September 2026).
What breaks at scale is the initial load. There is no batch endpoint — inserts and updates are separate operations and each is its own call — so writing 3,000 historical jobs into AroFlo is a two-day job at the daily cap, before you account for the customers and sites they depend on. That is a scheduling problem, and a cost that belongs in the quote rather than in week three.
Responses are XML unless you send Accept: text/json, there is no version in the path, and the documentation contains no deprecation statement. None of that is a flaw exactly. It is an absence of published promises, and an integration should be built as though the shape can change.
What AroFlo does not publish
Five of the thirteen fields we track are absent from AroFlo’s documentation: token lifetimes, which is fair because there are no tokens; how to verify an event and what happens when delivery fails, both moot because there are no events; what a test environment gives you; and where the data physically sits.
The residency gap deserves a sentence. AroFlo is Melbourne-headquartered and describes itself as 100 percent Australian-operated with more than 2,800 businesses across Australia and New Zealand (About AroFlo, fetched 3 September 2026), and it has been part of the Simpro Group since AroFlo, Simpro and ClockShark shared a US$350 million investment from K1 in November 2021 (AroFlo, from the CEO, 25 November 2021). Its personal data protection policy URL now redirects to a PDF hosted on Simpro’s domain. Where the data is stored is not stated on either. For a trade business that is usually immaterial; for one handling health or disability information it is a question to ask before connecting.
The pricing gap is the other one. AroFlo publishes a single plan name, AroFlo Premium, and a Request Pricing button (AroFlo pricing, fetched 3 September 2026). Any comparison that puts an AroFlo price beside ServiceM8’s published $29 to $349 a month has invented the AroFlo number, and we are not going to.
What we have not built, and what we would do first
We have not implemented against AroFlo. Nothing on this page is a Kindra measurement or a Kindra opinion about how AroFlo behaves; it is AroFlo’s published documentation, read closely. If you are on AroFlo and want an integration, that changes the shape of the engagement, not whether we would take it.
What changes is the first increment. Before quoting the build we would spend a short, fixed block proving the two things the documentation cannot: what the daily cap really means for your record volumes, and how the specific zones you depend on behave under the WHERE filters. You would get those numbers, dated, whether or not they made the build look good. If they said a polling integration cannot meet the responsiveness you need, you would hear that first.
The alternative worth putting on the table is the one AroFlo itself lists beside its API: Zapier. For a modest volume of one-way events it may be the whole answer, and Zapier versus a custom build works through where that line sits. Either way, start with a Leak Check.
The questions people actually ask.
01You have not used AroFlo. Why should we listen to you about it?
You should weigh it accordingly, which is why we said so in the first line. What we can do without having built against it is read the documentation the way an integrator reads it — for the limits, the absences and the failure modes — and put it beside nine systems we have built against. That is a narrower claim than "we know AroFlo", and it is the one we can back with links. The moment we have measured it, this page will say so with a date.
02Is 2,000 calls a day actually a problem for a business our size?
For a small crew doing forty jobs a day with a nightly sync, no — it is generous. It becomes a problem in two shapes: anything that needs to react within minutes, because polling frequently enough to do that burns the allowance on empty checks; and any initial load or migration, because with no batch endpoint each record is a call. We would size both against your actual job and customer counts before quoting, not after.
03What happens when AroFlo changes its API?
It will, and AroFlo publishes no versioning or deprecation policy, so there is no promised notice period to rely on. That argues for a thin, well-isolated connector where the AroFlo-specific parts are in one place, and for a monitoring alert on unexpected response shapes rather than waiting for a user to notice. You own the code, so the fix does not depend on us being available.
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.