Why the assumption fails so often in practice
Idempotency has to be designed in deliberately — a unique request identifier checked against a store of already-processed requests before an operation executes — it doesn't happen automatically just because an API looks RESTful or because retries are configured with exponential backoff.
Teams that add retry logic without explicitly verifying the downstream operation handles duplicate requests safely are, in effect, adding a failure mode rather than removing one.
How to actually verify it, not just assume it
Require and document an idempotency key for every operation retries might be applied to, and explicitly test the duplicate-request path — not just the happy path — as part of the integration's test suite, the same way Stripe's widely cited idempotency key pattern is tested by any integration built against it.
Retry logic without a tested idempotency guarantee isn't resilience. It's a duplicate-request generator with good intentions.MNB Integration Practice
Key actions
- Require an idempotency key for every operation subject to retries
- Explicitly test the duplicate-request path, not just the happy path
- Never assume RESTful design implies idempotent behaviour automatically
- Audit existing retry logic for untested idempotency assumptions