Idempotent API operations

Accept a stable idempotency key with an explicit scope, retention policy and request fingerprint. Two requests using the same key for different payloads should conflict rather than silently share a result.

Claim the operation and record its outcome durably in the same consistency boundary as the state transition when possible. Concurrent requests need a uniqueness rule, not a check followed by an unprotected insert.

Return the prior outcome or an explicit in-progress state. When a remote provider owns the side effect, forward a stable provider key and reconcile unknown outcomes; a local transaction alone cannot roll back the remote payment.