Idempotency
Networks retry. A well-behaved integration can send the same request twice — on a timeout, a connection reset, or an at-least-once queue — and litecommerce should not double-apply the effect.
Some surfaces already encode this. Public signup, for example, is a no-op on a repeat submission for the same email rather than creating a duplicate pending request.
Status — partial. A general, opt-in idempotency-key mechanism for mutating endpoints is on the roadmap and will be documented here with the exact header, scope, and replay-window semantics. Today, idempotency is handled per-endpoint where it matters most (signup, provisioning). Don't assume a global idempotency key is honored until this page says so.
Related
- Error envelope — how conflicts (409) surface
- Webhooks — delivery retries on the inbound side