Idempotency-Key

A write that times out may or may not have happened. With an Idempotency-Key, sending it again is safe: Digize answers what the first one did instead of doing it again.

curl -X POST https://digize.com/api/v1/contacts \
  -H "x-api-key: $DIGIZE_API_KEY" \
  -H "content-type: application/json" \
  -H "idempotency-key: 5f1c2a8e-3b7d-4c55-9a0e-1f2d3c4b5a69" \
  -d '{"firstName":"Maya","email":"maya@northloop.example"}'

Every POST, PUT, PATCH and DELETE takes the header. Make a new key for each change you mean to make, such as a UUID, and use the same one only when sending that change again.

How a key is kept

A key is 1 to 255 printable characters without spaces. Anything else answers 400 invalid.
Keys belong to the API key that sent them, and are kept for 24 hours.
A request is the same when it has the same method, path and input. The order of a JSON object’s fields doesn’t matter.

What you send	What you get
The same key and request again	The first answer, with its status and body, and `Idempotent-Replayed: true`
The same key with a different request	`422` with `code: "invalid"`: use a new key for a new request
The same key while the first request is still running	`409 conflict`: try again in a moment

A request that was refused before it ran isn’t kept, so you can fix it and send it with the same key: a bad key, a missing permission, the rate limit, or input that isn’t valid. Neither is one that failed with a 5xx. Any other answer is kept, a 4xx from the operation as much as a success.

Checkouts from a site

A site’s storefront checkout takes an idempotency key the same way, per site, as idempotencyKey (or the Idempotency-Key header on https://digize.com/api/store/checkout): Storefront.