Receiving an event later does not prove that the event describes a later change. Network delays, retries, and parallel workers can make webhook arrival order differ from the order of the original changes.
An older update should not silently replace newer information just because its handler ran last.
Choose a documented ordering signal
Read the event contract for version numbers, revision fields, timestamps, or other ordering rules. Use only the guarantees it actually provides. A server receipt time measures your delivery path, not necessarily the underlying resource change.
If events mainly announce that something changed, fetching the current resource can be safer than applying an old payload as the final truth. Keep that refresh bounded so repeated events do not trigger uncontrolled reads.
For resources with supported revisions, compare the incoming revision with the stored one inside the update transaction. An earlier revision can be recorded as received without replacing the current state.
Simulate reversed delivery
Create two valid test events for the same controlled resource. Apply the newer change first, then the older one. Check the final visible title, status, or other affected field, not only the response codes from the webhook endpoint.
Repeat with parallel workers. A correct comparison outside the transaction can still lose a race when both handlers read the same old value before writing.
If the API does not provide a total ordering guarantee, document your reconciliation approach. Your integration should remain honest about what it knows. Treating arrival order as a hidden guarantee is an easy way to make a reliable-looking event handler restore stale data.