• State Verified Answer
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 9 views
  • Users 0 members are here
Options
Related

Webhook not firing on job completion — only fires on creation

Devon Marsh

Hey folks — running into something that feels like a configuration issue but I can't pin it down.

I've got a webhook endpoint set up and it's firing perfectly on work_order.created. I can see the payloads hitting my server, signature verification working, all good there.

But I'm also subscribed to work_order.status_changed and I'm not seeing anything when a tech marks a job complete in the mobile app. I've waited a few minutes, checked logs, no delivery attempts at all.

What I've confirmed so far:

  • Webhook shows as "Active" in the dashboard
  • Event subscription includes both work_order.created and work_order.status_changed
  • Tested status changes from both mobile and web — same result
  • No failed deliveries showing in the webhook logs (just... nothing)

Is there something about how status changes get batched or delayed? Or maybe work_order.status_changed doesn't fire for the "Completed" status specifically? Worth noting I'm on the standard plan if that matters for event coverage.

Anybody else seen this? YMMV but figured I'd check before opening a ticket.

Parents
  • 0

    From a spec perspective, is this a UI state management issue (i.e., optimistic updates without confirmation) or a transactional consistency problem between the webhooks service and the subscription store?

    I'd expect the subscription API to return the ground truth regardless of UI rendering, but the behavior Devon describes suggests the UI may be reflecting intended state rather than actual.

    Eli — is there a ticket I can reference for this? Want to track when the fix lands to evaluate whether we need client-side verification in our integration.

Reply
  • 0

    From a spec perspective, is this a UI state management issue (i.e., optimistic updates without confirmation) or a transactional consistency problem between the webhooks service and the subscription store?

    I'd expect the subscription API to return the ground truth regardless of UI rendering, but the behavior Devon describes suggests the UI may be reflecting intended state rather than actual.

    Eli — is there a ticket I can reference for this? Want to track when the fix lands to evaluate whether we need client-side verification in our integration.

Children
  • 0 in reply to Omar Hassan

    Good question — it's the latter, a consistency issue between the subscription service and the UI's read replica. The UI shows what the user selected; the API returns what's actually in the primary store. Under normal load they're in sync, but there's a known race when event types are added to a plan (i.e., when you upgrade or when we roll out new events).

    Ticket is ENG-4421, internal only right now. I can update here when it ships. For production integrations, I'd recommend verifying the subscription response after any create/update — especially if you're programmatically managing webhooks.