• State Verified Answer
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 8 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.

  • 0

    Not a batching issue. Check your event subscription payload — the UI sometimes shows both selected but only one is actually persisted.

    Fix:

    1. Delete and recreate the webhook subscription
    2. Verify event_types array in the API response has both values
    3. Ensure endpoint returns 200 within 5s

    Docs: Setting Up Webhooks

  • 0

    That's it — the API response showed only work_order.created even though the checkbox was ticked for both. Deleted and recreated, now seeing both event types in the response.

    Just triggered a test completion and the webhook fired immediately. Thanks Leo, heads up on the UI/API drift.

  • 0 in reply to Devon Marsh

    Yeah this one tripped me up too when I first looked at it — the webhook subscription UI has a known sync issue where the checkbox state and actual API state can drift, especially if the subscription was created before the status_changed event type was added to your plan. It's on our backlog to fix.

    For anyone else hitting this, here's a quick curl to verify what you're actually subscribed to:

    curl -X GET api.fieldpulse.io/.../{subscription_id} \
  -H "Authorization: Bearer {token}"

    Check the event_types array in the response, not the dashboard checkboxes. If you're missing events, DELETE + POST is the reliable fix.

    Also worth noting: work_order.status_changed fires on any status change, not just completion. If you only care about completed jobs, filter on new_status == 'completed' in your handler. We've seen people burn through retries filtering at the subscription level, which isn't supported.

    Related troubleshooting: Webhook Not Firing on Job Completion

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

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