Networks fail. A request can succeed on our side while your client sees a timeout. Idempotency keys make the retry safe.

How it works

Send an Idempotency-Key header when you create an inquiry, a job, a product, or an order. Any string of 1 to 128 printable characters works; a purchase order number or a UUID is typical.

First request	The record is created. 201.
Same key, same content	The same record is returned with replayed: true. 200. No second record.
Same key, different content	409. Change the key for new content.
No key	Every request creates a new record.

A replay looks like the original record with one extra field:

{ "id": "2c5c95fc-0ec3-4a30-9d75-17d6e012c645", "status": "estimated", "next": "accept", "replayed": true }

Reuse with different content:

{ "error": "Idempotency-Key was already used with different content." }

The key is scoped to your API key. Two customers can use the same value without collision.

What counts as the same content

The request body after validation. Whitespace and field order do not matter. A changed value does.

Retrying other calls

GET is always safe to repeat.
Accept is safe to repeat: an invoiced job returns the existing invoice with 200; a job still waiting for a staff quote returns 202 again.
Cancelling an order is safe to repeat: a cancelled order returns 200 with the same order.
File upload has no idempotency key. If a retry would duplicate a file, list the files first.

503

If we could not save your request, the response is 503. Retry later with the same Idempotency-Key.