Retry safely with request keys
Send an Idempotency-Key with every create, so a retry never starts a second request.
If a response is lost after you send a create, you can’t tell whether Truvo accepted it. Send the same request again with the same request key. If Truvo accepted the first one, it returns that request instead of starting a second.
Which requests need a key
These operations require the Idempotency-Key header:
Reads don’t take a key.
Choose a key
A key is 1 to 255 characters long, made of letters, digits, ., _, :, and -. Use a new key, such as a UUID, for each new operation, and keep it so that a retry sends the same key:
What happens when you send a key again
A key’s scope is one environment, one integration, one resource, and one operation. A key replays for at least 24 hours.
Over MCP, start_quote_request, send_test_event, and replay_event_delivery take the key in their request_key argument, with the same rules.
When to retry
- A timeout or a network error. Send the same body with the same key.
503with the retry actionretry. Wait for the time inRetry-After, then send the same body with the same key.409conflictwith the retry actionretry. The first call with this key was still running. Wait for the time inRetry-After, then send the same body with the same key.409request_key_reusedwith the retry actionuse_new_request_key. Your body is different from the first request with this key. To make a new request, use a new key.