Idempotency Replay

Overview

Idempotency replay is the resubmission of a request with the same idempotency identity so that the service can reproduce the original result without repeating the side effect. Idempotency replay is a reliability technique, not an unrestricted replay mechanism. A client may replay after a timeout, dropped connection, or uncertain response.

The server looks up the key, verifies that the request matches, and returns the stored status or response; if processing is still underway, it may return an in-progress or conflict response. These records support Duplicate API Request and let an operator reproduce the result from authoritative evidence rather than relying on a dashboard snapshot or a provider’s latest status alone. A replay after key expiration can execute as a new operation.

Idempotency Replay should remain distinct from Payment Retry and Duplicate API Request, because each can represent a different stage, record, control, or financial outcome.

Replaying a mutated payload creates a conflict, while returning a stale response without current access checks may expose data or mislead the caller. Important failure modes include duplicate or out-of-order delivery, incompatible schemas, lost acknowledgements, unbounded retries, stale consumers, forged messages, and replay that creates a second financial action.

Safe replay requires durable key storage, request fingerprinting, concurrency control, consistent response retention, and clear handling of server errors. Authentication and authorization must be reevaluated as appropriate rather than assuming the key itself grants permission. The final control should feed API Authentication , preserve the original evidence, and document any correction, override, or manual action. The contract should define identifiers, schema and version, authentication, ordering, idempotency, retry behavior, error handling, and the service responsible for authoritative state.