Handle Duffel API rate limits and safely retry high-volume flight search/order requests without creating duplicate bookings.

Steps

1. Read the ratelimit-limit, ratelimit-remaining, and ratelimit-reset response headers on every call to api.duffel.com (the documented default is 120 requests per 60 seconds for search, with other endpoints having their own separate limits).
2. When a request returns HTTP 429 with error type rate_limit_error (code rate_limit_exceeded), stop sending further requests until the time in ratelimit-reset (RFC 2616 format) has passed, then retry.
3. Since Duffel does not expose a client-supplied Idempotency-Key header for POST /air/offer_requests or POST /air/orders, send your own x-client-correlation-id header on each request so you can match retries back to your internal request log for debugging/support.
4. Before retrying an order-creation POST after a timeout or 5xx, check the offer's expires_at and, for ambiguous outcomes (200/202 responses), poll the order or wait for a webhook rather than blindly re-POSTing, since a retried order-create can produce a duplicate paid booking.
5. For webhook consumers, dedupe incoming events using the idempotency_key field included in each webhook payload, since Duffel's webhook delivery is at-least-once and failed deliveries are retried for a limited window.
6. For sustained high-volume search needs above the default quota, contact Duffel to request a higher rate limit for your account.