Idempotency-Key reused

409 · https://docs.rostergiving.com/errors/idempotency-key-reused

This Idempotency-Key belongs to a different request body on the same operation: a request that succeeded, is still running, or ended in a 5xx or a timeout. Nothing ran: no resource was created or changed, and no simulation was sent.

A key names one request. Repeating the same body with the same key is a safe retry and returns the original result. A different body is a different request, and returning the first request's resource would hand you, for example, another donor's session without any sign that it was not the one you asked for.

What to do: if you meant to retry, send the original body unchanged. If this is a new request, send a new key. Check how your system derives keys: a key built from too little (the church but not the donor, say) collides across requests that should be distinct.

The key belongs to its first body for 30 days from the moment that request arrives. After a 5xx or a timeout, the key stays with that body: repeat it unchanged to complete it, or send the corrected request with a new key. On an operation that creates a resource (POST /v1/churches, POST /v1/churches/import, POST /v1/church_consents, POST /v1/donor_sessions, POST /v1/manage_sessions, POST /v1/refunds and POST /v1/webhook_endpoints), a key whose request succeeded also keeps its body for as long as the resource it created exists, so this error can come after the 30 days too; on the other operations, the key is held for the 30 days only. A request refused with 400 does not hold the key, so you can fix the body and repeat it with the same key, unless an earlier attempt with it ended in a 5xx or a timeout. The same key on a different operation, or on a different church in the path, is a different request.