Events for real changes
Transactions posted, invoices issued, payments received, approvals granted, agents escalating, periods closing — business events rather than raw row-level change notifications.
Platform · platform & data
Webhooks are simple to send and difficult to depend on. The failure that costs you is not an endpoint returning an error — that gets retried. It is the delivery that succeeded, was processed halfway, and left two systems disagreeing without anybody being told.
What it does
Transactions posted, invoices issued, payments received, approvals granted, agents escalating, periods closing — business events rather than raw row-level change notifications.
HMAC signature with a timestamp and a rotating secret, so your endpoint can verify a delivery came from us and is not a replay of an old one.
Every delivery carries a stable key so your handler can safely dedupe. At-least-once delivery means duplicates are a certainty, not a possibility.
Events about the same object arrive in the order they occurred. Global ordering is deliberately not promised, because it would cost latency you would not want to pay.
Exponential backoff over 24 hours, then the endpoint is marked failing and you are notified — rather than quietly dropped after three attempts.
Seven days of event history queryable and replayable, so a deploy window that dropped deliveries is a five-minute fix rather than a reconstruction.
Everybody signs payloads and everybody retries. The gap in most webhook implementations is what happens after retries are exhausted: the event is gone, and your system is missing a fact it will never be told about again.
That is how a deploy window on a Tuesday becomes a discrepancy discovered at close three weeks later, with nobody able to say which records are affected. Seven days of queryable, replayable history turns that into a filter and a replay.
Exactly-once delivery over a network is not achievable, and vendors who imply it are describing something they have not built. We deliver at least once, attach a stable idempotency key, and expect your handler to dedupe on it.
Being explicit about this is not pedantry. A team that believes deliveries are unique writes handlers that double-post on a retry, and the resulting duplicate transactions are tedious to unpick because each one is individually valid.
Events about a single object arrive in order. Events across different objects do not carry a global sequence, because guaranteeing that would require serialising delivery in a way that would make the system slower for everyone to solve a problem almost nobody has.
Every event carries the object version it describes, so a handler that receives something stale can detect it rather than apply it.
A webhook is a notification that something happened. It is a poor foundation for keeping two systems in agreement, because it has no reconciliation and no way to detect what it never told you about.
Where the goal is agreement rather than notification, use a connector with its daily reconciliation behind it. We will say so rather than letting you build a synchronisation layer on a notification primitive and discover the drift later.
Limits
It is not achievable over a network. We deliver at least once with a stable idempotency key and are explicit about it rather than implying otherwise.
Per-object ordering only. Cross-object sequencing would cost latency for a guarantee almost no handler genuinely requires.
Longer histories are available on Enterprise. Beyond the window, the API is the recovery path rather than the event stream.
Questions
Describe what your systems need to know about and we will point you at the right event.