How should an integration handle webhook events that arrive out of order?

Assume notifications can arrive out of order. Treat the webhook as a *hint that something changed*, and let the live record be the source of truth.

*Diagram · webhook ordering*

What the event gives you

A typical record.updated / record.created body includes roughly:

• event — e.g. record.updated
• recordId, baseId
• changeRequestId — which change produced this notification
• fields — field snapshot at that merge, not a guarantee it is still the newest thing you will process

Delivery is asynchronous; two quick edits can land at your endpoint in either order.

Recommended receiver pattern

1. On every notification, read recordId (and log changeRequestId for audit).
2. Fetch the current record from Busabase with your integration key.
3. Upsert your copy from that fresh read (not from the event’s fields alone).
4. Optional guard if you must apply snapshots offline: store lastAppliedChangeRequestId / a content fingerprint; skip applying an older snapshot when you already applied a newer one — but still prefer re-fetch when online.

Why not “apply event fields directly”?

The payload’s fields are correct for the change that fired that event. If a newer update already merged (or arrives first), blindly writing the late event can roll your mirror backward.

How to verify

• Update the same record twice within a second; confirm your system ends matching the latest Busabase values regardless of arrival order.
• Temporarily delay processing of the first event; the second-then-first sequence should still converge after re-fetch.
• Use Webhook Test now only for connectivity — then prove ordering with two real edits.

Boundaries

• Do not use wall-clock “time we received the HTTP POST” as the version.
• Signature checks prove authenticity, not ordering.
• If you only need “something changed” triggers (cache bust, queue a job), you can ignore fields entirely and always re-read.

If you share whether your mirror must stay offline-capable, we can sketch the minimal fingerprint fields to keep.