Building a Travel API for the AI Era

Most travel APIs were designed in the 2010s for mobile apps and websites. They assume a human is looking at search results, clicking through options, filling in forms. The API mirrors the UI flow.

AI agents don't work like that. They need structured data, clear decision points, and the ability to execute in a single flow. We built RunRelay from scratch for this new paradigm. Here's what we learned.

Decision 1: MCP-Native, Not REST-First

Our first instinct was to build a REST API and bolt on an MCP wrapper later. We're glad we didn't.

Model Context Protocol isn't just a transport layer — it's a way of thinking about tool design. MCP tools have structured inputs, structured outputs, and clear descriptions that help the model understand when and how to use them.

When you design MCP-first, your API naturally becomes more machine-friendly:

• Fewer endpoints, more semantic. Instead of /search, /offers, /offer-details, /pricing, /booking — we have search_flights,get_flight_details,book_flight. Each tool does one thing completely.
• Rich descriptions. Every parameter has a description that helps the AI understand constraints: "IATA airport code, 3 letters" vs just "string."
• Decision-ready responses. Search results include everything the agent needs to make a recommendation — price, duration, stops, airline, cabin class, baggage — in a single response. No pagination, no follow-up calls.

We still have a REST API (OpenAI function-calling compatible). But MCP is the primary interface, and the REST API is generated from the same schema. MCP-first, REST-compatible.

Decision 2: Hybrid Execution Architecture

The biggest technical decision was how to handle low-cost carriers. We had three options:

Here's how it works technically:

1. Search request comes in. We fan out to Amadeus (GDS) and our LCC search layer simultaneously.
2. Results merge. GDS and LCC results are normalized into the same schema. The AI agent (or end user) sees a unified list.
3. Booking routes automatically. GDS bookings go straight through the Amadeus API — fully automated. LCC bookings get routed to our operations queue.
4. Human agents execute LCC bookings on the airline's website, using the passenger details from the API call. Median completion time: 4 minutes.
5. Confirmation fires back through the same webhook/callback. The AI agent gets a confirmed booking regardless of which path it took.

From the API consumer's perspective, it's one endpoint. They don't know (or care) whether Amadeus processed it automatically or a human booked it on Ryanair.com. Same request, same response, same SLA.

Decision 3: Async-First Booking

Traditional travel APIs are synchronous: you call /book, wait 10–30 seconds, get a confirmation. This works for GDS but breaks for LCC (human execution takes minutes, not milliseconds).

We made all bookings async by default:

This has an unexpected benefit: it's actually better for AI agents. Instead of blocking on a 30-second API call (which can timeout, which the model might retry), the agent gets an immediate acknowledgment and can inform the user: "Booking in progress, I'll let you know when it's confirmed."

More natural. More resilient. Works for both GDS (fast) and LCC (slower).

Decision 4: Agent-Aware Responses

Here's something subtle: when an AI agent gets search results, it needs to explain them to a human. If you return raw GDS data (fare basis codes, booking classes, cryptic baggage policies), the agent either hallucinates an explanation or passes through gibberish.

We pre-process responses to be explanation-ready:

• Baggage policies in plain language: "23kg checked bag included" not "1PC/23K"
• Price breakdowns: base fare, taxes, fees — separated and labeled
• Change/cancel policies: "Free cancellation within 24h, then €50 fee"
• Comparison hints: "€42 cheaper than average for this route"

The agent doesn't need to interpret GDS codes. It gets data it can directly relay to the user. Less hallucination. Better UX.

What's Next

We're working on three things:

• Hotels. Same hybrid approach — major chains via API, independent properties via HITL. Same unified interface.
• Multi-city trip planning. AI agents are great at complex itineraries but need an API that can handle multi-segment bookings atomically.
• Real-time disruption handling. When a flight gets cancelled, the API should proactively notify the agent with rebooking options — not wait for someone to check.

The thesis is simple: AI agents will handle travel for hundreds of millions of people. They need infrastructure that's designed for machines, operated by humans, and reliable enough for real money and real trips.

That's what we're building.