What Is Idempotency?

Retrying without repeating the effect

An idempotent operation has the same intended effect when repeated as when performed once. This is useful when an integration loses a response and cannot tell whether the server completed the request. The uncertainty is important: a timeout at the client does not prove that the server did nothing. Repeating an operation blindly can create a second record or repeat another externally visible action.

HTTP defines certain methods as idempotent in their intended semantics, while an API can provide additional mechanisms for particular operations. Some services accept an idempotency key and remember the outcome associated with it. The scope, retention period and behavior for changed parameters are provider-specific. Adding a header with an invented name does not create support on a server that does not implement it.

An outbound workflow example

Suppose a CRM creation request succeeds but its response is lost. A controlled retry should use the API's documented mechanism or reconcile the destination record before creating another one. Separately record whether later steps, such as campaign enrollment, completed. Preventing duplicate record creation does not automatically make the entire chain of writes and notifications behave as one idempotent operation.

Distinguish keys and identities

A request key identifies a logical operation within the provider's supported rules. A contact email identifies a possible data match and can be shared or changed. These are different boundaries. Deduplicating a list by email is not equivalent to making each downstream write safe to retry, and generating a new request key for every attempt can defeat the intended duplicate protection.

Document the operation, key scope, retry window and readback procedure. Test uncertain outcomes with controlled records before applying the pattern to production work. The useful guarantee is narrow: the supported retry does not repeat the intended effect. It is not a blanket promise that every event arrives once, every response is identical forever or every connected workflow is automatically duplicate-free.