Skip to main content
Version 2 has two kinds of events. Connector events describe a connection: it linked, it synced, it failed, it needs relinking. Data events describe records: a sync created or updated records of one model. You subscribe to each event by name. There are no wildcards, so a webhook receives exactly the events ticked on it. Version 1 events are listed on Migrate from version 1.

​
Connector events

​
Data events

Data events are named <category>.<model>.<action>, where the action is created or updated. No event reports a deleted record. The names follow this pattern:
Every model Bindbee syncs has both. Each data event fires at most once per sync, carrying the ID of every record of that model the sync created, or every one it updated - see Webhook payload.

​
Order within a sync

Bindbee sends the events of one sync one at a time, in this order:
  1. connector.sync.started, before any data is read.
  2. Every created event, then every updated event. Within each half, parent models come before the models that reference them - hris.company before hris.employee, hris.employee before hris.employment - following the order of the table above.
  3. connector.sync.completed, last, so its sequence is the highest of the sync.
A failed sync sends connector.sync.started, then connector.sync.failed, then connector.relink_needed if the failure broke the connection. Each event’s delivery, including retries, finishes before the next starts. Across syncs and between connectors, order is not guaranteed, so sort by sequence - see Delivery and retries.

​
What this means for you

  • Subscribe to the models your handler processes, and nothing else.
  • Size your first-sync handling for every record of every subscribed model.
  • Wait for connector.sync.completed before acting on a sync as a whole, since the data events of that sync all precede it.
  • Handle connector.relink_needed by asking your customer to reconnect - see Relink a connector.
  • Run a periodic full read if you need complete data.