ServiceM8 webhook not firing to Make.com

API & SDK
1

We have a Make.com integration listening for ServiceM8 job status change events via webhook, and it’s stopped receiving anything since 19 July - despite multiple jobs having their status changed to Work Order since then, which should trigger it every time.

Webhook URL: https://hook.us2.make.com/g3hmkrjkhyk1c9opl6uounryx7f6fuft

What we’ve confirmed healthy on Make’s side:

  • The webhook shows as attached and active (confirmed via Make’s own hook status check)
  • The scenario itself is active, not paused, no errors in the queue
  • We’ve re-saved/re-registered the trigger module twice
  • We’ve tested with several different jobs changing to Work Order, not just one
  • None of it has produced a single new execution

Given everything checks out clean on our end, it feels like the webhook subscription on ServiceM8’s side may have stopped sending, or silently expired. HelpDesk support pointed me here since this is API/integration specific.

Is there any way to check ServiceM8’s own outbound webhook delivery logs for this URL, to see whether ServiceM8 is even attempting to call it? Happy to provide specific job numbers/UUIDs and timestamps if that helps trace it - have a few ready to go. Thanks in advance for any pointers.

2

Hi Marc,

The documented ServiceM8-side check is to list webhook subscriptions and include inactive subscriptions, using GET /webhook_subscriptions?status=inactive, or status=all if you want to compare active and inactive subscriptions in the same response.

That response can show whether the subscription is active, along with last_failure_reason and last_failure_at for the most recent recorded failure, which is the key thing to check if delivery has stopped.

For a job status trigger, job.status_changed is a supported webhook event.

The callback URL also needs to return a successful 2xx response within 10 seconds, and repeated failed deliveries or timeouts can cause the subscription to be automatically deactivated.

If you find an inactive subscription, capture the failure details before reactivating or re-registering it, as the stored failure snapshot is cleared once a subscription is successfully reactivated.

If you still need us to trace ServiceM8-side evidence after checking the subscription status, email support@servicem8.com with the callback URL, affected job numbers or UUIDs, timestamps, and timezone, rather than posting those details publicly.

Thanks,
Cody