Independent API referenceField notes updated 29 Aug 2026

Reliability pattern

Idempotent POST requests: prevent duplicate payments, orders, and jobs

Implement idempotent API writes with durable operation keys, atomic storage, input fingerprints, in-flight states, and retained results.

idempotent POSTduplicate chargeoperation keyexactly-once illusion

Reviewed Source: Stripe idempotent requests

Client-generated keys only work when the server handles them atomically. The idempotency record should be created with the write transaction or an equivalent lock, bind to normalized input, expose an in-progress state, and retain enough result data to answer a replay consistently.

Treat the complete response as an evidence record: status, headers, provider code, request identifier, method, and raw body. The sequence below separates what the response proves from the checks still needed before a safe retry or code change.

Diagnostic procedure

Work from evidence to recovery.

  1. 01

    Create before sending

    The caller generates one stable operation key before the first network attempt.

  2. 02

    Reserve atomically

    The server records or locks the key before executing side effects so two concurrent requests cannot both proceed.

  3. 03

    Replay the outcome

    Return the stored terminal response, or a documented in-progress result, for the same key and matching payload.

Before
timeout → caller cannot tell if payment happened → sends a new POST
Target-safe shape
same operation key → server returns original/in-progress outcome without a second charge

Interactive check

Test the evidence locally.

Use the related workbench to reproduce the decision with your own response, headers, method, or retry policy. Pasted values remain in the active browser tab.

01 / Retry policy
02 / Attempt timeline7.50s cumulative wait
#10 ms
#2500 ms
#31000 ms
#42000 ms
#54000 ms

Duplicate-side-effect riskPOST retries can repeat side effects. Add an idempotency key or a durable operation identifier before enabling automatic retries.

No account · no upload · no endpoint calledOpen the full retry planner and operating notes →

FAQ

Before you ship

Does APITC send this evidence to an API?

No. The matching and calculations in the linked workbench run in the active browser tab.

Should every idempotency response be retried?

No. Retry behavior depends on the method, idempotency protection, provider instructions, and whether the failure is temporary.

Protocol behavior checked against the Stripe idempotent requests. Recheck your pinned provider/API version before production deployment.