Idempotency

Networks fail: a request can time out after the API has already acted on it. To retry a write without doing it twice, send an Idempotency-Key header — any unique string up to 255 printable ASCII characters, such as a UUID you generate per operation:

curl -X POST \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Idempotency-Key: 6f1c2e9a-8b3d-4c47-9a51-0d2f7e4b8c13" \
  -H "Content-Type: application/json" \
  -d '{ … }' \
  https://api.reminix.com/v1/…

The first request with a key runs normally. Any retry with the same key and the same request returns the first response again — same status, same body — without running the operation a second time, and carries the header Idempotency-Replayed: true.

The rules

• Writes only. The header applies to POST, PUT, PATCH and DELETE; reads are naturally safe to repeat and ignore it.
• One key, one request. Reusing a key for a different request (a different endpoint or body) is a 409 with code idempotency_key_reused. Generate a new key per operation, and reuse it only for retries of that operation.
• Concurrent retries wait. A retry that arrives while the first request is still running gets a 409 with code idempotency_in_progress and a Retry-After header; retry after it.
• Failures you can retry. Responses with a 5xx status are not stored, so retrying the same key runs the request again. Any other response — success or a 4xx — is what every retry receives.
• Per credential, for 24 hours. Keys are scoped to the API key or token that sent them (two integrations never collide), and are remembered for 24 hours.

Sending a key is optional, and recommended on every write.