Idempotency Window

Overview

Context and purpose

It differs from a network timeout or retry delay because it defines server-side duplicate protection over a longer business period. The main risks include retries after expiry creating duplicate operations, premature garbage collection, indefinite storage growth, and inconsistent windows across regions. After the window expires, the same key may be treated as new according to the API contract. In production, teams should define ownership and apply published retention duration, aligned record and result expiry, clock consistency, safe client retry guidance, and exceptions for long-running operations. Useful measures include late-retry count, records expired before final state, storage volume, and duplicate operations after window expiry. Idempotency Window is closely connected to Idempotency Record , Idempotency Scope , and Request Timeout . Operational review of Idempotency Window should separate successful recovery from repeated attempts that only increase latency or load.

How it works

The idempotency window is the interval for which a service promises to remember an operation key and its result. After retention expires, the same key may be interpreted as a new request depending on the API contract.

Practical checks and failure points

Document retention precisely, use durable business IDs for long-running reconciliation, and never assume key expiry equals payment expiry.

Related concepts

Callback Verification · Payment Event Delivery

Further reading

• docs.stripe.com official reference