Retries & Idempotency
Apply conservative retry controls to partner workflows and prevent duplicate state-changing operations.
Retry only when the operation and failure are known to be safe. A timeout does not prove that a state-changing request failed.
Decision Table
| Situation | Default action |
|---|---|
| Local validation failure | Correct input; do not retry unchanged request |
| Authentication or authorization failure | Correct access configuration; do not loop |
| Read-only query transport failure | Consider bounded retry with backoff and jitter |
| Quote request transport failure | Consider bounded retry if duplicate quotes are acceptable to the approved workflow |
| Purchase, payment, bind, or modification outcome unknown | Reconcile status through an approved read/status contract before retrying |
| Explicit throttling response | Follow documented server guidance; see Rate Limits |
Idempotency
The published API guide and streamlined purchase input reference an idempotencyKey. Generate a unique key per intended business action and reuse it only for a retry of that same action. Apply the scope, retention window, and replay behavior defined for the operation; otherwise reconcile an ambiguous result before replaying it.
Backoff Shape
Use exponential backoff with jitter within limits approved for your integration. Do not publish or hardcode an undocumented attempt count, delay, or timeout as a Travel Insured commitment.
Reconciliation Before Replay
For purchase, payment, bind, and modification operations:
- Persist the request correlation and carry-forward identifiers before sending.
- On an ambiguous outcome, mark the local transaction as pending.
- Query the approved source of truth or contact support with sanitized correlation data.
- Retry only when the prior attempt is confirmed not to have completed or the operation has a confirmed idempotency contract.