Duffel Flights and Stays API vs LetsFG

Duffel Flights and Stays API

Self-serve sign-up and test mode with no card or contract. No OpenAPI document, llms.txt or official MCP server.

LetsFG

Hosted MCP with OAuth 2.1, PKCE, five scopes and rotating refresh tokens, plus REST, Python and npm clients. Tickets are bought by a LetsFG booking agent after the hold, 4 to 11 minutes per the docs, and bookings can pause with questions.

Duffel Flights and Stays API

1. Send Duffel-Version: v2 on every request or you get a version error
2. Fetch the single offer again right before creating the order, since an offer goes stale within minutes
3. Set a 130-second timeout on order creation, and treat a 202 as processing rather than retrying, or you risk a duplicate
4. Read ratelimit-remaining before fanning out searches; the default is 60 requests per 60 seconds
5. Count offer requests. Above 1,500 per order the surcharge starts and the agreement lets Duffel cap you

LetsFG

1. Start on /v1/sandbox/ with no key; the booking states, questions and timings match production
2. After book_flight, poll get_flight_booking every 20 to 30 seconds and answer questions before expires_at_ms; an unanswered price change fails the booking and releases the hold
3. Honour retry_after_seconds on a 429. Over MCP the limit is 10 searches per 10 minutes and 100 a day, and early retries lengthen the pause
4. Fetch results with get_flight_results and the search_id rather than searching again, which spends allowance
5. Send the same idempotency_key when retrying a booking after a timeout
6. Treat a 410 as a retired route and read the replacement path in its body