Skip to main content
Bindbee sends each event as a POST to your URL and waits up to 10 seconds for a response. A 2xx means delivered. Anything else is retried or given up on, depending on the status. These rules apply to version 1 and version 2 webhooks alike.

​
Retries

A Retry-After header on a retried response can lengthen a wait to at most 5 seconds. Every attempt for an event finishes within about a minute.
After the last attempt, the event is not sent again. Bindbee has no redelivery and no replay, so an event your endpoint missed has to be recovered by reading the data - see Recover missed events.
A failing endpoint stays enabled. Bindbee keeps sending new events to it, so it recovers on its own once it answers again.

​
What your endpoint should return

Respond 200 as soon as the signature verifies, then process the event. A handler that does its work before responding runs into the 10-second timeout under load, and each timeout spends an attempt. A 4xx is final, so don’t return one for a temporary problem. A 400 from a validation layer that rejects an unfamiliar field loses that event for good.

​
Deduplicate events

Your endpoint can receive an event more than once, for example when it processes the event but times out before responding, and Bindbee retries. Every copy carries the same id in the body and the same webhook-id header. Store each id you process, and skip an event whose id you’ve already stored. The id is the same on every webhook that receives the event, so the same check collapses one event arriving at two of your endpoints. Version 1 events carry no ID. For those, sync.sync_id combined with the event name identifies an event within a sync.

​
Order events

Events can arrive out of order across syncs and connectors, and your own queue can reorder them. Use sequence to put them back in order. sequence is per connector, and a later event always has a higher number. Expect gaps. Numbers are shared across every webhook in your organization, so events you’re not subscribed to still take one. Compare numbers rather than counting them.
Skipping an older event is safe when you re-read records rather than applying the event’s content. The IDs tell you what to read, and the read returns current data.

​
Recover missed events

An event can be lost when your endpoint is down for longer than the retries last, or when a webhook is disabled. Recover the data from the API:
  1. Find where the gap starts, from the delivery logs or from the last connector.sync.completed you processed for each connector.
  2. Read each model you subscribe to with modified_after set to the start of the gap - see modified_after.
Run the same read on a schedule as a reconciliation sweep, and a missed event costs you a delay rather than a record - see Syncing.

​
Monitor deliveries

Each delivery log entry records one event sent to one webhook, with the status of the final attempt. Individual retries aren’t logged separately.

​
In the dashboard

Delivery logs are on the Webhooks tab under Logs, and on each webhook’s own page. Click an entry to see the request Bindbee sent and the response your endpoint returned.

​
Through the API

List your webhooks to get their IDs, enabled state and when each last fired:
List deliveries with filters. Polling this with errors_only=true catches an endpoint that has stopped accepting deliveries:
Get one delivery for the full request and response:
last_triggered_at on a webhook updates on every attempt, including failed ones. It shows that Bindbee is sending. The logs show whether your endpoint is accepting.