Skip to content

Webhook integrations need rules for repeat deliveries

Control the business effects of repeated webhooks. A missing acknowledgement must not trigger another order without checking.

Tobias Krüger2 min read
Two overlapping envelopes with matching purple message symbols.

When planning a webhook integration, treat repeat deliveries as a possible operating condition. The software decision needs to address what happens to the business action when a message arrives a second time. A reliable connection alone does not answer that question.

A missing signal leaves the outcome uncertain

In a fictional customer portal, a notification triggers order creation in the ERP. The order is created, but the response does not reach the sender. The sender transmits the notification again. If every arrival blindly creates a new order, the same intended action produces two orders.

Stripe explicitly notes that events can be delivered more than once. This establishes a specific provider case. Check your own connection's contract to determine which repeats it can produce. A missing acknowledgement establishes neither certain success nor certain failure.

Judge the repeat by its business effect

The desired rule in this example is that the same notification can find the existing order instead of creating another. The integration needs an agreed identity and a dependable association with the processing result. The safeguard must also account for two copies arriving simultaneously; disconnected steps of checking and saving later leave that question unresolved.

In the acceptance scenario, check the order in the ERP, the response to the retry and the visible status in the portal. A transport acknowledgement and a completed order may represent different states.

The effort depends on the action

If a notification merely sets a displayed value to the same value again, repeating it may be harmless. Order creation or another effect intended to happen once needs more protection. This does not mean that every small connection requires an additional queue.

Repeats should remain visible. An increase can indicate a fault. We recommend handling expected repeats while retaining the ability to investigate unusual patterns.

Sources

Written by

  • Tobias KrügerEditor for Systems IntegrationTobias Krüger covers how different software systems work together at ASES. In his articles he explains how ERP, CRM and online shops are connected and how to deal with errors in data exchange.

Follow ASES

Read more

All articles

APIs & Integration with ASES

ERP, CRM and shop cleanly connected