Quickstart

Quickstart: use idempotency keys on write requests

An Idempotency-Key header makes a POST safe to retry. Generate one UUID per logical operation, send it with the write, and reuse the same key on any retry — the API returns the original result instead of creating a second enquiry or consent record.

2 min read

Idempotency-KeyUUID per operation
reuseSame key on retry
409Conflict → you already have it

Generate one key per operation

The key identifies a logical action, not a physical request. Generate it once when the user submits, and reuse it if the network fails and you retry:

const key = crypto.randomUUID();
async function submit() {
  return withRetry(() => fetch(`${BASE}/enquiries`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json', 'Idempotency-Key': key },
    body: JSON.stringify(enquiry),
  }));
}

What the server does with it

On the first request with a given key the API processes it normally and stores the result. A repeat with the same key returns that stored result instead of doing the work again — so a timed-out retry is completely safe.

Scope and lifetime

Keys are scoped per endpoint and remembered for a window long enough to cover retries. Never reuse a key for a genuinely different submission, and never share one key across two users.

Frequently asked questions

Do I need idempotency on GET?

No. GETs are naturally idempotent. Add the key to POSTs that create or submit something — enquiries and consent, most commonly.

What if I reuse a key for different data?

You may get a 409 conflict or the original result back. Keys must map one-to-one to a logical operation; generate a fresh one for a new submission.

Where should the key be generated?

On the client, at the moment the user commits the action, so it survives across the retries of a single logical submission.

Funding for UK limited companies

Credicorp lends to your company, not to you personally — short-term working capital with no personal guarantee. See what your business could access.