Our zaps are failing even though the API key has been deleted that was relating to the webhooks, and any new API key generated is coming back with no event data to match previous webhook subscriptions to that account.
Can someone please please please assist here, as I am at a complete loss as to what to do to fix this.
You might need to be a bit more specific about the type of webhooks you’re referring to. Are these event webhooks or object webhooks?
If an API key has been revoked you shouldn’t continue receiving webhook events tied to that key. In most cases if the endpoint Zapier or another service was listening on is deleted those webhook calls will just fail and eventually stop once they hit gateway errors.
It’s also worth checking whether there are existing webhook subscriptions still active on the account. Those can continue firing depending on how they were originally registered.
If you can share a bit more detail about the setup such as event vs object webhooks, how they were registered, and what endpoint you’re seeing requests from it will be easier to narrow down what’s going on.
Happy to help troubleshoot. We deal with ServiceM8 integrations pretty regularly. If you want to see what we do you can check out trademagnet.com.au.
From what you’ve described, there are two common causes of “limit reached” style failures with Zapier/n8n style webhook workflows: REST API throttling (HTTP 429) and webhook callback delivery being throttled/cancelled when the receiving URL doesn’t respond as expected.
Check whether you’re hitting the REST API rate limits
ServiceM8 API usage can be throttled, and when the threshold is exceeded you’ll receive HTTP 429 (Too Many Requests). The documented limits are 180 requests per minute and 20,000 requests per day (per application and per account).
Confirm your webhook receiver is returning HTTP 200 (and not 429/4xx/5xx)
Your webhook callback URL should always return HTTP 200 when invoked by ServiceM8. If your endpoint responds 429, webhook request volume will be throttled for 15 minutes for the account, and if it responds 4xx/5xx it’ll be retried for up to 72 hours before being automatically cancelled (and a 410 response will cause the webhook to be unsubscribed).
If your “new” webhook payload looks like it has no data, that can be expected
ServiceM8 webhook updates do not include the value of the changed fields, and you’ll need to use the REST API (via the provided resource_url) to retrieve the full record and its field values.
Verify what webhook subscriptions currently exist, then recreate as needed
You can list current webhook subscriptions using the Webhooks API (GET /webhook_subscriptions). If you need to remove subscriptions, the Webhooks API supports deletion via DELETE /webhook_subscriptions (optionally filtering by object, event, and/or unique_id).
If you’ve regenerated/deleted API keys while troubleshooting, it’s also worth confirming the automation tool is using a valid key because API key requests must include the key in the X-API-Key header, and invalid credentials will return HTTP 401.
Email support@servicem8.com with the Zapier/n8n error log showing the HTTP status code(s) and a timestamp, and we’ll check what’s happening on the ServiceM8 side.
ServiceM8 webhook subscriptions are managed through the Webhooks API, so the quickest way to see what’s still active is to list the current subscriptions and remove any old ones.
Confirm which type you’re using
Event webhooks: business events like job.created/job.completed.
Object webhooks: changes to specific fields on an object (for example job, company).
If you don’t pass an object or event, it deletes all subscriptions for this app.
If you’re expecting “full record data” in the webhook
Webhook updates only indicate that a field changed, and don’t include the field values, so you’ll need to use the REST API to retrieve the record and its values.
If you’re seeing “limit reached” style failures
Your callback URL should return HTTP 200 when invoked by ServiceM8.
If your callback responds with 429, webhook volume will be throttled for 15 minutes for the account, and 4xx/5xx responses are retried for up to 72 hours before being automatically cancelled.
If you can’t locate or clear the subscriptions from your integration side, you can email us via the ServiceM8 app or dashboard by going to Help and then Contact Support Team, and we can check what’s registered on the account.
Using DELETE /webhook_subscriptions without specifying object or event removes all webhook subscriptions for the app you’re authenticated as for that request (it doesn’t delete every webhook on the whole account).
So it would only remove Zapier subscriptions if Zapier is using the same ServiceM8 app/credentials you’re making the DELETE call with; if Zapier is connected under a different app/credential set, it won’t be touched.
If you want to be more surgical, the delete call can be scoped by:
object (remove subscriptions for a specific object type) or event (remove subscriptions for a specific event), or
unique_id (scope deletion to a given integration).
Before deleting anything, it’s usually easiest to run GET /webhook_subscriptions and check which callback_url and unique_id values are currently active.