ServiceM8’s webhooks tell you something changed. They do not tell you what.

What the ServiceM8 API does and does not allow

Job management for small field-service teams. Australian company, priced by jobs a month rather than by seat.

Everything in the strip above is ServiceM8’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.

The thin webhook, and the arithmetic it forces

ServiceM8 tells you a job changed and which fields moved. It does not tell you what they changed to. To know that, you fetch the record — a second HTTP call, against the same 180-a-minute allowance that the webhook did not consume.

For most small trade businesses this never matters. Forty jobs a day generates a trickle. But the pattern that does bite is a bulk edit: someone reprices a hundred jobs, or a scheduled process touches every open job at once, and you receive a hundred events in a few seconds and go out to fetch a hundred records. That is most of a minute’s allowance spent on one person clicking one button.

The design that survives it is a queue with a token bucket in front of the fetch, and deduplication by record ID inside a short window — because five field changes on one job in ten seconds is five events and should be one fetch. None of that is exotic. It is just work that a thicker webhook payload would have made unnecessary.

• Deduplicate by record, not by event Collapse everything for one job inside a short window into a single fetch. On bulk edits this is the difference between comfortable and rate-limited.
• Rate-limit your own fetches A token bucket in front of the follow-up call. The webhook did not cost you budget; the fetch does.
• Treat the payload as a hint Since it is unsigned, the only thing you should trust is what the authenticated fetch returns. That is good practice anyway and here it is necessary.

Unsigned events, and what to do about it

ServiceM8 verifies your endpoint once, at subscription time, with a challenge it expects you to echo back. That proves you control the URL on the day you set it up. It proves nothing about any POST that arrives afterwards.

Compare that with Simpro, which signs every payload with an HMAC, or Stripe, which signs and includes a replay-tolerance window. ServiceM8 publishes neither. Anyone who learns or guesses your callback URL can send you events that look real.

This is manageable, and the mitigation is the same thing the thin payload already forces: never act on the contents of the webhook, only on what an authenticated fetch of that record returns. A forged event then costs you one wasted API call rather than a wrong decision. Use an unguessable callback path as well. But it should be said plainly that the platform is not doing this part for you, and most integration pages will not tell you that.

Rate limits and what breaks at scale

One hundred and eighty requests a minute and twenty thousand a day, and — usefully — applied per application per account rather than per application. Two client accounts get a separate allowance each, so a multi-tenant integration does not have its clients competing with one another. That is a better arrangement than several systems in this register offer and it deserves credit.

Filtering is where ServiceM8 constrains you rather than throttles you. Ten conditions maximum, AND only, no OR, no NOT, no parentheses, and no greater-than-or-equal or less-than-or-equal — only the strict versions. A date range that includes both endpoints is expressed with two strict comparisons and a careful think about boundaries, or with two requests and a merge.

The one that catches people out is not a limit at all. Webhook timestamps are UTC; almost everything else in ServiceM8 is in the account’s local timezone. In Brisbane that is a silent ten-hour error in anything that compares the two, and it will look like a scheduling bug rather than a timezone bug for as long as you let it.

What ServiceM8 does not publish

4 of the thirteen fields we track are simply absent from ServiceM8’s documentation: any bulk or batch limit, what the test environment gives you, where your client’s data physically sits and whether API access itself costs anything.

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 ServiceM8 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 ServiceM8 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.