Skip to main content

Webhook Filter Troubleshooting

If a filtered webhook is not behaving the way you expect, work through the checks below in order. Most issues come from either an event type mismatch or filter IDs that do not match the event context.

Fast Checks​

  1. Confirm the webhook is Active
  2. Confirm the endpoint URL is reachable over HTTPS
  3. Send a test event to confirm connectivity
  4. Review the selected event types
  5. Review the configured filter IDs against the source record in Infodeck

What the Test Event Proves​

webhook.test is a delivery health check.

  • It confirms that Infodeck can reach your endpoint
  • It does not prove your real events match the configured filters
  • It ignores event filters and is delivered even when the webhook has filtering configured

If test delivery works but a real event does not arrive, the next place to check is the webhook's event type and filter criteria.

Common Problems​

ProblemLikely causeWhat to do
Test event arrives, but real events do notEvent type not subscribed or filter IDs do not matchCompare the webhook config against the actual record IDs in Infodeck
No filter fields appearNo event types selected yetChoose the event types first
Filter summary says All matching eventsNo filters are currently storedEdit the webhook and add at least one filter value
Wildcard webhook misses eventsFilters still apply to wildcard subscriptionsRemove or widen the filters
Save fails with validation errorToo many IDs or malformed valuesKeep each filter field to 50 IDs or fewer and remove blanks

Special Event Cases​

Work order completion can produce two events​

If the webhook subscribes to both:

  • workorder.status.changed
  • workorder.completed

then a transition into the Complete status can deliver both events. This is expected.

Use:

  • workorder.completed when you only care about completion
  • workorder.status.changed when you need every status transition

Auto-approved quotation submit can produce two events​

If a quotation is submitted and approved as part of the same business action, the webhook can receive:

  • sor.quotation.submitted
  • sor.quotation.approved

This is expected behavior. Your endpoint should handle the two event types independently.

How to Verify the Right IDs​

Check the record in Infodeck and confirm that the IDs you entered are the real IDs used by the event family:

  • assets: assetId, locationId, assetTypeId
  • work orders: workOrderId, locationId, assetId
  • bookings: siteId, resourceId
  • visitors: siteId
  • SOR: sorScheduleId, quotationId, workOrderId

If you are unsure which IDs to use, start without filters, confirm deliveries arrive, then narrow the webhook gradually.

Delivery Log Reading Pattern​

Use delivery logs to separate transport issues from matching issues:

  • no delivery log entry at all: the event probably did not match the webhook subscription
  • failed delivery entry: the webhook matched, but the endpoint rejected or timed out
  • successful webhook.test entry only: transport is working, but your real event selection or filters still need correction

When to Split a Webhook​

Create separate webhooks when:

  • one team needs asset or site-specific notifications
  • one integration only cares about one work order or quotation stream
  • you are approaching the 50-ID limit for one filter field

Splitting a broad webhook into smaller, focused subscriptions usually makes support and debugging easier.

Was this page helpful?