Out-of-Order Webhooks: Can an Old Update Reopen Finished Work?
Start with the short answer ↓
A valid webhook can describe an older business state. Use an explicit per-record decision, supported version evidence and a bounded recovery path so late updates do not silently undo newer work.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
A later delivery is not necessarily a newer decision
An appointment is moved from Thursday to Friday. The operations system receives the Friday update, then a delayed notification restores Thursday. Both messages may be genuine; the second arrival is simply older business information. Checking a sender's signature or suppressing an exact duplicate does not resolve the order of two different, valid updates.
Stripe explicitly says that webhook events are not guaranteed to arrive in generation order. Its current guidance also warns that snapshot event creation times have second-level precision, so distinct events can share a timestamp. Do not treat that field as a reliable sequence or duplicate key. These are documented Stripe behaviors; inspect the actual delivery contract for every provider you connect.
Verify a delivery without confusing authenticity with permission to act
Decide whether you need the current state or every business effect
Start with what the receiving team must accomplish. Updating an appointment display to the current approved date is different from recording each authorized charge, refund or stock movement. A current snapshot may answer the first question but cannot automatically replace a history of required business effects. Do not discard an unseen transaction merely because a later notification arrived first.
For a state-copying workflow, an event can be a prompt to retrieve the authoritative record through a supported API rather than an instruction to copy an old payload. Stripe documents retrieving missing objects when related notifications arrive first. Retrieval still needs the correct account, access, request budget and a rule for what happens if the source is unavailable. It is not a guarantee that any provider offers a suitable current-state endpoint.
Microsoft's Event Grid documentation independently warns that delivery order is not guaranteed. Moving messages into another delivery service therefore does not, by itself, establish the business sequence. Ask the implementation team which specific ordering guarantees apply and to which record or stream.
Walk through one appointment in arrival order
The following is a proposed design exercise, not a customer incident or a claim about a delivered connector. Assume the source genuinely provides increasing revisions for this single appointment, and the destination already holds revision 10. Those assumptions must be verified; event IDs and unrelated timestamps must not be invented into a revision sequence.
| Arrival at destination | Source change | Expected decision |
|---|---|---|
| 10:02 — revision 12 arrives | Appointment moved to Friday. | Confirm authority and apply the supported newer state; retain revision 12 with the record. |
| 10:03 — revision 11 arrives | Earlier update still says Thursday. | Record the late event without replacing Friday or creating another assignment. |
| 10:04 — revision 13 arrives | Appointment was subsequently cancelled. | Apply the authorized cancellation and its agreed consequences; do not reject it merely because it reverses an earlier plan. |
| 10:05 — revision 12 is delivered again | The old Friday notification is repeated. | Preserve the cancellation; identify prior handling and expose any unresolved effect rather than reopening the appointment. |
Handle repeated actions separately from ordering distinct changes
Keep the ordering decision attached to the record
Write a small contract for each affected record type: its stable identity, authoritative fields, supported revision evidence, legal transitions and the consequence of an uncertain comparison. A cancellation or an explicitly authorized reopening may be legitimate newer work. A rule that always keeps the apparently most advanced status can lose those decisions just as surely as a rule that always keeps the last arrival.
Where the provider supports meaningful revisions, the check and update must remain safe when two workers handle the same record concurrently. Ask the team to demonstrate that an older worker cannot overwrite a newer accepted state between checking it and saving. Comparing numbers only in application memory is not an acceptance result. The appropriate atomic update, concurrency control or per-record processing mechanism depends on the systems being connected.
Do not impose a single global sequence on unrelated customers or appointments unless the business actually needs it. Equally, a queue that preserves receipt order cannot recover a source sequence that was already rearranged before receipt. If the source provides no usable ordering evidence, define a supported authoritative read or a visible review path instead of manufacturing certainty.
Give missing prerequisites a deadline and an owner
A valid update might refer to an appointment that the destination has not seen yet. Separate that missing prerequisite from an obsolete update. In the agreed design, the handler may retrieve the referenced record, hold the work briefly or route it for review. Define what can be checked, the permitted wait, and the action when that wait expires. Do not acknowledge success while leaving an invisible item parked forever.
The operator view should explain the source record, current accepted state, incoming event reference, decision and remaining work. Preserve enough redacted evidence to distinguish ignored older state from a failed downstream action. Avoid copying unnecessary customer details or credentials into logs. A periodic reconciliation can reveal unresolved differences, but it needs a defined scope and owner rather than a promise that everything will eventually fix itself.
Accept the workflow using deliberately rearranged events
In an isolated test environment, run the same appointment changes in normal order and reversed order, then repeat the old notification after cancellation. Add a missing initial record, an unavailable source read, two simultaneous workers and a legitimate later reopening. For each case, specify both the expected final state and the allowed business effects. Turning off production sending and consequential writes is part of preparing the exercise.
The release passes this exercise only when the final approved appointment state is correct, required effects are neither omitted nor duplicated, and every unresolved case has a visible owner and next action. Save the actual provider assumptions and observed outcomes with the release. This is a focused acceptance framework for one workflow, not a universal event-ordering algorithm or a guarantee that every integration supports the same solution.
Primary references
The guidance above is AgenticShip's proposed approach. These references provide technical background for the relevant recommendations.