Idempotency

Retry chargeable operations without creating duplicate work.

Where:

Operation	REST	MCP
Content generation	`Idempotency-Key` header required	`idempotency_key` argument required
Publishing preview	header required	`idempotency_key` optional (a random one is generated, so no replay)
Publishing operation	header required	argument required
Website `publish` action	`idempotency_key` in the body (required for `publish`)	same, inside `request`

Rules:

The key is any string of 1–255 characters (a UUID is recommended).
The record is scoped to (API key, surface, method, route template, key). The
same key on REST and MCP refers to two different records.
The request fingerprint is
sha256(METHOD + concrete path + canonical JSON body) together with the brand.
Same key + same request after success → the stored response, status and
Idempotent-Replayed: true.
Same key + different body or brand → 409 idempotency_key_reused
(retryable: false).
Same key while the original is still running → 409 idempotency_key_reused
(retryable: true, Retry-After: 2). Wait and repeat.
Original failed → the same key may be retried; the record is reopened for
exactly one retrier.
Records expire after 24 hours. In-progress records older than 1 hour are
marked expired by the daily purge.
Session principals cannot perform idempotent operations.