Design webhook handling for duplicates, ordering and safe replay

Separate receipt from completion

Draw the point at which the sender receives an acknowledgement and the point at which the business record becomes complete. Keep event time distinct from receipt time, together with the event identifier, target and state. When processing continues after acknowledgement, the operator still needs a durable way to find unfinished work. A successful HTTP response should not be used as the only evidence that every downstream action finished.

Acknowledging receipt should not be treated as proof that downstream writes and notifications completed. Distinguishing accepted, in-progress, complete and needs-review records gives the operator a way to identify remaining work after a partial failure.

Define the identity of an operation

Choose identity from the operation being performed. An order identifier may be insufficient when creation and shipment are separate events, while a fresh random identifier assigned on every receipt cannot recognise redelivery. Inspect the identifier maintained by the sender and the constraints at the destination. Document the scope of the deduplication decision, including whether the same event should be allowed again after a previous attempt failed.

Consider a sender event ID or a business order ID plus operation type. Some APIs, such as Stripe, support idempotency keys, but retention and retry semantics must be checked for the particular API rather than assumed universal.

Distinguish ordering from concurrency

Identify the records that actually require ordering. Updates to one order may need coordination without forcing every unrelated order through one serial queue. Compare the delay caused by a slow record with the risk of concurrent updates to the same destination. A tool’s local processing order does not automatically impose that order on every external service, so validate the final record rather than relying only on the editor setting.

Make documents parallel and ordered processing. Even when one flow is ordered, separate entry points and upstream systems may not share that order; consider checking a record version or event time before applying a stale update.

Define the replay boundary

After a timeout, do not assume the destination performed no action. Use the business identifier or a documented lookup to determine whether the operation completed. Payments, inventory increments and customer messages have different replay risks from a simple replacement of a field value. Define who authorises a retry and how uncertain cases remain on hold when the destination cannot provide a reliable answer immediately.

For irreversible work, define how the destination’s result is checked before retrying. Verify each failure position with disposable data instead of assuming a platform’s general replay function guarantees business-level safety.

Use a failure-case checklist

Prepare ordinary delivery, repeated identity, an older update and a timeout after a destination write. Use synthetic records and non-customer destinations so the test does not create real duplicate messages or orders. Compare the input with the final register and the operator’s recovery notes. Each candidate must make unfinished work discoverable and the restart decision explainable; a successful normal-case demonstration is not sufficient acceptance evidence.

On Make, n8n or Activepieces, adoption depends on whether the team can maintain the necessary state, lookups and retry procedure. Preserve an independent reconciliation of expected receipts and completed business outputs.

Walk through the same event delivered twice

For a sequence of order events, check allowed state transitions as well as duplicate identity. An older event should not blindly move a cancelled or shipped order back into an earlier state. Decide what happens when the target order cannot yet be found: a fresh lookup or a pending review may be safer than creating a new order unconditionally. Preserve the reason for that decision in the operational record.

Check whether the sender supplies a suitable event ID, or whether operation type must join the business ID. Consider a second delivery arriving before the first completes, and choose state storage that handles competing checks and writes.

Use an identifier traceable to the appropriate record, with explicit retention and reprocessing procedures. An upstream API’s idempotency support does not automatically protect your own register and notifications too.

• Choose an automation tool by designing the first job
• Make vs n8n: daily batches, line items and operating cost
• Automate lead capture from receipt to accountable follow-up