# Idempotency (/docs/api/idempotency)



Networks fail after a request reached us but before the answer reached you. Send an `Idempotency-Key` header on every `POST`, `PATCH` and `DELETE`, and a retry cannot create a second post.

```bash title="cURL"
curl -X POST https://feedhorizon.com/api/v1/posts \
  -H "Authorization: Bearer fh_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 3f1c9a52-6b0e-4a43-9a51-0c9f1e7d2b11" \
  -d '{ "profileId": "YOUR_PROFILE_ID", "platforms": ["linkedin"], "content": "Hello" }'
```

How it behaves [#how-it-behaves]

* The key is any string of 1 to 255 characters. A UUID per logical operation works well.
* The first request with a key runs normally, and its response is stored for 24 hours.
* A retry with the same key and the same request (method, path and body) returns the stored response with the same status, plus the header `Idempotent-Replayed: true`. Nothing runs twice.
* The same key with a different request is refused with `422 idempotency_key_reused`.
* A retry while the first request is still running gets `409 idempotency_request_in_progress`. Wait a few seconds and retry.
* Server errors (`5xx`) are not stored, so a retry after one runs again.
* Keys belong to your organization: two of your API keys share them.

Without the header, every request runs. FeedHorizon does not block posts because their text matches an earlier one, so recurring posts like "We are open today" work without workarounds.