Skip to main content
Network requests fail. When that happens you want to retry, but retrying a mutating call risks doing the work twice (double-charging credits, creating two webhook subscriptions, queuing two renders). The fix is idempotency keys. Send a unique Idempotency-Key header on every POST mutation; if the server already processed it, it returns the cached response instead of redoing the work.

The contract

Which endpoints support it

Every POST mutation, most importantly:
  • POST /api/v1/facade/generate — the one that costs credits; a retried request with the same key is never charged twice
  • POST /api/v1/facade/brands and POST /api/v1/facade/brands/from-url
  • POST /api/v1/facade/webhooks (+ /test, /rotate-secret)
  • POST /api/v1/generate/sign
GET endpoints are naturally idempotent — no key needed. (Signed image URLs go further: the URL itself is the idempotency key — a unique URL renders and bills exactly once, ever.)

How to use it

Response headers

Errors

INVALID_IDEMPOTENCY_KEY (400)

The header value isn’t a valid UUID v4.

IDEMPOTENCY_CONFLICT (409)

You reused a key with a different request body, URL, or method. The server refuses to overwrite the cached response, and also refuses to silently replay a stale one.
Fix: generate a fresh UUID v4 for each new request. Only reuse a key when retrying the same request.

When to generate a new key

A useful mental model: one key per business operation, not one per HTTP call.

What if I don’t send a key?

The endpoint still works — but you give up the safety net. A retry could legitimately do the work twice. We strongly recommend sending a key on every POST mutation.