Blog
After Duffel: who books lounge, eSIM, and insurance?
Many AI travel stacks start with a modern flights API. Duffel is a frequent choice (and a real search phrase—“duffel api”). Once offers and orders work, the open question is: who books the rest of the trip?
This piece is complementary positioning, not a competitor teardown. Attribute flight behaviour to Duffel’s own docs; treat Ancilair as the non-ticket shelf.
What typically stays in the air API
From Duffel’s public documentation, builders can attach available services such as bags and seats to offers/orders (including post-booking bag flows). Their ancillaries component likewise centres on bags and seats. That is the right place for airline-tied extras.
See:
What usually sits outside the ticket
| Job | Why it is a different integration |
|---|---|
| Travel insurance | Insurer contracts, eligibility, async policy issuance |
| eSIM / connectivity | Telco wholesale, activation payloads |
| Lounge day access | Lounge networks / airports, not seat maps |
| Security fast track | Airport programmes and slot inventory |
| Entry requirements / eVisa checks | Document rules by nationality × destination |
Agents that only deep-link these categories break chat UX. Tools with quoted cost and idempotent booking keep fulfillment inside the session. See Build an AI travel agent that fulfills ancillaries.
A clean split for builders
[User / agent host]
│
├─ air.* → flights API (offers, orders, bags, seats)
└─ anc.* / esim.* / insurance.* / fasttrack.*
→ ancillary shelf (MCP / REST / CLI)
Shared state you own: passenger identity, PNR/order id, layover segments, destination country. Pass those into ancillary tools; tag calls with customer= / pnr= for support and reseller billing.
Ancilair’s hosted marketplace passes through supplier rates with 0% markup and quotes before the call—see ancilair.com. Bring-your-own supplier keys stay unmetered on the ladder’s upper rungs.
MCP-shaped agents
If the host is MCP-native, expose air and ancillaries as separate tool groups with clear names so the model does not invent a lounge booker on the flights server. Pattern guide: Travel MCP server for ancillaries.
Sources
Not affiliated with Duffel. APIs and supported service types change—verify against current docs.
Questions
- Does Duffel replace an ancillary marketplace?
- Duffel’s documented air ancillaries focus on services attached to the flight order—such as bags and seats. Lounge day passes, eSIM plans, and travel insurance are typically different supplier categories and contracts.
- Can an agent use Duffel and Ancilair in one session?
- Yes in architecture terms: air tools against your flights API, ancillary tools against the shelf, with shared traveller/PNR context in your agent state or metadata tags.
- Is Ancilair affiliated with Duffel?
- No affiliation is claimed. This article describes a common builder split: flights API + multi-ancillary tools.