Skip to main content
Every POST and PATCH to requests, opportunities and introductions needs an Idempotency-Key header. Without one, the call fails before anything is written:
Radar’s write endpoints (POST /radar/nodes/{id}/inquiries and the submission endpoints) accept and echo the header, but do not require it.

​
Using it

Generate one key per distinct intent. A random UUID works. Send the same key on every attempt of that call:
  • 1 to 255 printable ASCII characters.
  • Remembered for 24 hours from the first attempt.
  • Scoped to your key. Two different keys can use the same Idempotency-Key value without colliding.

​
Replays

Retry the same call with the same key and body to get the original response, not a second write. The response carries:
The replayed body is the same JSON value as the original response. Field order may differ, so compare values, not raw bytes.

​
Reusing a key for a different request

Using the same Idempotency-Key with a different request body fails with idempotency_key_reused (409). Use a new key for a new intent. Reuse a key only to retry the exact request it belongs to.

​
Concurrent retries

If a call with the same key is still running, a second call fails with idempotency_key_in_flight (409) and a Retry-After header. Retry after that interval to get the original response. After 5 minutes, a new attempt with the same key takes over the claim.

​
What gets stored

Only a successful response (2xx) is stored for replay. If the first attempt is refused, the claim on that key is dropped at once. That covers a validation error, a 409, a 429 or any other non-2xx answer. You can then retry with the same Idempotency-Key once the problem is fixed.

Rate limits

Writes have their own, smaller per-minute budget.

Errors

idempotency_key_required, idempotency_key_reused and idempotency_key_in_flight.