Skip to main content

idempotency_key_in_flight

HTTP 409, type conflict_error.

A request with this Idempotency-Key is still being processed.

Why it happened​

This is a distinct code from a reused key on purpose. A reused key is your bug; this is not. The original request has not finished, so there is no result to return yet and no way to know whether it will succeed.

It most often means a retry fired faster than the first attempt settled.

How to fix it​

Retry the same request with the SAME key, backing off between attempts, for example after 1, 2, 4 and then 8 seconds. When the original finishes, the same key returns its result. This is the only path that cannot charge twice.

What the API does not tell you. It does not bound how long an original request may run, and this response carries no wait time. This code also has a second cause today: a request that was refused, or that failed, while it was being processed keeps its key in this state for up to 24 hours and never returns a result. The response cannot tell you which cause you have.

So:

  • Do not switch to a new key because a read shows nothing happened. Reading the resource the request would have created or changed shows whether the original has taken effect so far, not that it has stopped. For a new payment, list GET /payments with created_gte set to just before you sent it. For a capture or a void, read GET /payments/{id} and its status. For a refund, list GET /payments/{id}/refunds. For a saved card, list GET /payment_instruments for the customer. For a customer, list GET /customers filtered by your reference or email. For a plan, list GET /plans. For a checkout session, list GET /checkout_sessions. For a new subscription, list GET /subscriptions filtered by customer, and for a change to one, read GET /subscriptions/{id}.
  • If the same key still answers idempotency_key_in_flight a few minutes after you first sent it, stop retrying it and contact support with the request_id before you send anything under a new key. Retrying past that point only repeats the same answer: a request held by the second cause above does not finish, and it stays held for up to 24 hours.
  • Do not reuse the key more than 24 hours after you first sent it. After 24 hours it expires, and the next request that uses it is treated as new and runs again, whatever happened to the first one.

Retrying: safe to retry unchanged, with the same Idempotency-Key, for a few minutes, as described above. Past that, contact support rather than retrying further.