A timeout does not tell you whether an action happened

Automation duplicate prevention means deciding which repeated messages represent the same intended action and making the receiver handle them safely. Retry behavior is part of that design. When a sender times out, the receiver may already have completed the work; sending again without a stable identity can repeat it.

Imagine a fictional service team sending an appointment request from a website to an internal queue. A network interruption occurs after the queue stores the request but before the website receives confirmation. The safe question is not simply ‘should we retry?’ It is ‘how will both systems recognize the same request?’

Give the intended action a stable identifier

An idempotency key identifies one intended operation across retries. It should remain stable when the same request is resent, and should not be reused for a different request. Agree how long the receiver retains that identity and what happens if the same key arrives with changed content.

Do not confuse identifying identical content with identifying an operation. Two identical service requests may be separate legitimate actions, depending on the product. Decide the rule with the people who own the workflow before implementing a broad duplicate filter.

Make duplicate handling a receiver responsibility too

A sender cannot prove that a lost response means no work occurred. The receiver needs durable records that distinguish accepted, processing, completed and failed operations. Concurrent arrivals should not both win permission to perform the same effect.

A database uniqueness rule can help protect an identity, but marking a request as seen is not equivalent to completing it. Consider a crash after recording the identity and before creating the appointment. Recovery needs to know whether it should resume, reconcile or escalate that incomplete operation.

Bound retry attempts and make delays visible

Define which failures are retryable, how long to wait and the maximum attempts or elapsed time. A malformed request typically needs correction, while a temporary service failure may justify a delayed retry. Repeated authentication failure should lead to investigation rather than an endless retry loop.

Persist attempt counts if work can restart. Otherwise a process restart may accidentally reset the limit. If a receiver asks for a delay, respect it where appropriate. The goal is a controlled recovery path, not a background process that repeats the same failure indefinitely.

Authenticate the connection and limit what it can do

Protect the endpoint with a defined authentication scheme and validate incoming data on the server. OWASP recommends HTTPS for REST services and server-side validation. For signed callbacks, sender and receiver must agree on the exact bytes, headers and replay rules; vague claims of ‘webhook security’ are not enough.

Keep credentials out of source and logs. A notification integration should receive only the information needed for that notification. Separate test and production endpoints, and make activation a deliberate step rather than a side effect of importing a workflow.

Ask for a recovery demonstration before enabling the workflow

Test a lost response, concurrent duplicate delivery, a receiver crash, a restart and an exhausted retry limit. Use non-sensitive sample data and observe the actual receiver state. A successful single delivery demonstrates only the simplest path.

Treat delivery guarantees carefully. ‘At least once’ usually means duplicates are possible; safe effects depend on the receiver’s design. Ask the implementer to state the boundary of each guarantee, especially when a third-party service performs the final action.

  • What identifies one intended action across retries?
  • Where are processing and completion recorded?
  • What recovers an interrupted operation?
  • What limits attempts across process restarts?
  • How are unexpected failures surfaced to an owner?
  • Which effects still require human approval?

Common questions

Are retries always safe?

No. If the receiver completed the action before the response was lost, an unprotected retry can repeat the effect. Stable identities and receiver-side handling are needed.

Is a successful webhook response proof of final completion?

Only if the agreed contract defines it that way. Some responses acknowledge receipt while the actual work runs later.

Sources & further reading

Consult the original documentation for current behavior and implementation details.

Make it useful for your business.

Explore our services, or tell us about the problem you want to solve.

Share your project Explore services