Travel and Hospitality Booking via AI Agents — GDS, NDC, and the Direct-Booking Path.

Fifty years of agent infrastructure — and four specific gaps AI exposes.

The Passenger Name Record, the e-ticket, the fare basis code, the Special Service Request — every primitive in the booking stack was purpose-built for agent-mediated transactions. The GDS was not designed for the open web; it was designed for agents booking on behalf of travelers. That makes travel the most agent-ready vertical in commerce, but it does not make it simple. The infrastructure is 50 years old, layered, and built around accreditation gates that AI agents must navigate rather than bypass.

The 4-Layer Model — Structured Data → API Endpoint → MCP Tool Description → UCP Compatibility — is already partially implemented by GDS infrastructure. Layer 1 structured data exists as GDS inventory records. Layer 2 API endpoints are the GDS REST and SOAP interfaces. Layer 3 is nascent — Sabre announced a proprietary MCP server in September 2025; Amadeus has not published an official MCP server as of this writing (re-verify before launch). Layer 4 UCP is where travel diverges most sharply from every other vertical.

Amadeus, Sabre, Travelport — what each gives an AI agent.

The three dominant Global Distribution Systems collectively process the majority of third-party flight bookings globally. Each aggregates seat inventory from airlines, room inventory from hotels, and car rental availability into a single searchable pool accessible to any certified travel seller. For AI agents, the critical distinctions are API protocol maturity, self-service access tier, production gating requirements, and announced agentic readiness.

Amadeus — the fastest self-service path

Amadeus (developers.amadeus.com) connects to 400+ airlines including 130+ low-cost carriers, and 150,000+ hotels via its Self-Service catalog. Any developer can obtain sandbox access and a free test quota in minutes — no travel agency credentials required. The Self-Service catalog covers flight search, pricing, PNR creation, hotel search, and hotel booking. What it excludes from Self-Service: American Airlines, Delta, British Airways, most LCC negotiated fares, and NDC content — those require the Enterprise tier, which demands IATA or ARC certification and a formal contract. Amadeus Self-Service per-call pricing: approximately $0.003–$0.046 per call depending on the API (re-verify before launch — pricing changes frequently).

Sabre — agentic-ready REST plus legacy SOAP

Sabre (developer.sabre.com) connects to 420+ airlines including 150+ LCCs. In September 2025, Sabre announced it was the first GDS to market explicitly agentic-ready REST APIs — Flight Shop, Flight Search, Flight Check, Flight Refresh, and Hotel Search, all labeled "Agentic ready" — alongside a proprietary MCP server. The legacy SOAP Bargain Finder Max remains in use for existing integrations. Production access to Sabre requires a Pseudo City Code (PCC) and formal contract negotiation; there is no self-service sandbox with the same breadth as Amadeus.

Travelport — widest airline coverage, modern REST migration

Travelport (travelport.com/products/apis) connects to 470+ airlines with 360 branded fares — the widest airline coverage of the three. Its legacy Universal API (uAPI) was SOAP/XML with WS-Security authentication. Travelport has published a migration guide from uAPI to its modern TripServices REST/JSON API, which uses OAuth 2.0 and returns payloads approximately 40–60% smaller than equivalent SOAP responses. Production access requires a PCC and certification.

GDS booking fees

GDS fees operate at two levels: platform/API fees charged by the GDS to the agency, and Distribution Cost Recovery (DCC) / segment fees charged by airlines to the GDS and passed through the chain. Lufthansa Group's published DCCs — the most transparent public data point available — are currently EUR 18.00/ticket on Amadeus, EUR 22.50/ticket on Sabre, and EUR 23.00/ticket on Travelport, effective for tickets issued from January 2026 (re-verify before launch — these rates are commercially confidential and subject to change). General per-segment fees for other carriers range roughly $3–$10 per segment; specific rates vary by contract and are not publicly disclosed.

(Re-verify all airline coverage counts, MCP server status, and fee schedules before launch — GDSs treat these as commercially confidential and update them frequently.)

Lufthansa Group DCC — the public fee benchmark

IATA's New Distribution Capability: richer offers, higher integration cost.

IATA's New Distribution Capability (NDC) is an XML-based (and increasingly JSON-capable) data exchange standard that allows airlines to distribute content directly to sellers without routing through GDS EDIFACT messaging. NDC enables capabilities EDIFACT cannot deliver cleanly: dynamic per-passenger pricing, rich ancillary merchandising (premium seats, bags, Wi-Fi, lounge access, pet fees), branded fare bundles, and real-time fare adjustments by loyalty tier. The message set governs the full shopping-to-order lifecycle.

The NDC message set

US carrier NDC adoption status

American Airlines is the most active NDC proponent among US network carriers. After an aggressive push in 2023 that restricted some fare content to NDC channels, AA adjusted its approach in response to corporate travel feedback. NDC capabilities are currently stable for corporate programs; adoption is driven through pricing incentives and expanded content access. United Airlines takes a commercially assertive NDC approach, selectively limiting Basic Economy fares in legacy EDIFACT channels — pricing discrepancies between EDIFACT and NDC-sourced fares are common. Delta Air Lines is the most cautious US carrier — Delta has explicitly stated it will not force NDC adoption via GDS surcharges or content withdrawals; initial NDC capabilities were rolling out with a target sustainable program expected in the months following a 2026 initial release.

NDC aggregators — the practical path for independent operators

A seller can connect to NDC in two ways: direct airline integration (one connection per airline, significant engineering overhead, separate accreditation per carrier) or via an NDC aggregator. Duffel (duffel.com) offers developer-first NDC access covering 30+ airlines via a single API, handling IATA/ARC accreditation on the seller's behalf. AirGateway and Travelfusion offer similar aggregation models. The aggregator path is the recommended starting point for operators who want NDC content without the per-airline integration overhead and without pursuing independent IATA/ARC accreditation (which involves a $2,300 ARC application fee plus a $20,000 bond requirement, per Duffel's published guidance — re-verify before launch).

<Request>
  <FlightRequest xmlns="http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersCommonTypes">
    <FlightRequestOriginDestinationsCriteria>
      <OriginDestCriteria>
        <CabinType>
          <CabinTypeCode>5</CabinTypeCode>  <!-- 5=Economy, 2=Business, 4=PremiumEconomy -->
          <PrefLevel><PrefLevelCode>Required</PrefLevelCode></PrefLevel>
        </CabinType>
        <DestArrivalCriteria>
          <IATA_LocationCode>JFK</IATA_LocationCode>
        </DestArrivalCriteria>
        <OriginDepCriteria>
          <Date>2025-06-15</Date>
          <IATA_LocationCode>LAX</IATA_LocationCode>
        </OriginDepCriteria>
      </OriginDestCriteria>
    </FlightRequestOriginDestinationsCriteria>
  </FlightRequest>
  <OfferCriteria xmlns="http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersCommonTypes">
    <FareCriteria>
      <FareTypeCode>70L</FareTypeCode>  <!-- Published fare -->
      <PrefLevel><PrefLevelCode>Required</PrefLevelCode></PrefLevel>
    </FareCriteria>
  </OfferCriteria>
  <PaxList xmlns="http://www.iata.org/IATA/2015/EASD/00/IATA_OffersAndOrdersCommonTypes">
    <Pax>
      <PaxID>ADULT_1</PaxID>
      <PTC>ADT</PTC>
    </Pax>
  </PaxList>
</Request>

Source: ndc.virginatlantic.com/docs/airshopping/rq

Five mandatory elements, IATA SSR codes, and the 13-digit e-ticket.

A Passenger Name Record is a database entry — held in the airline's Computer Reservation System or the GDS — that serves as the authoritative record for a specific trip. It is identified by a six-character alphanumeric record locator (e.g., RXGMKL). The GDS record locator and the airline's own record locator are distinct identifiers. Travelers receive the airline's code for check-in; the GDS code is internal to the agency workflow.

The five mandatory PNR elements

IATA SSR codes relevant to AI agents

Special Service Requests are structured requests sent from the agent to the airline via GDS SSR messaging protocol. The IATA SSR code vocabulary standardizes accessibility, dietary, and passenger-type requests. AI agents should build SSR defaults into traveler profiles and inject them automatically at PNR creation time.

The frequent flyer element is stored as FQTV AA 1234567890 P1 — associating American AAdvantage number 1234567890 with passenger 1. Seat assignments are stored as ST elements referencing segment numbers. The Transitional Stored Ticket (TST) is a pricing record that holds the fare basis code, taxes, and total amount that will appear on the issued ticket.

E-ticket structure and lifecycle states

An e-ticket is the electronic record proving payment and authorization to travel. It is issued against the TST by a certified ticketing entity — an IATA-accredited agency, an airline itself, or a consolidator. The e-ticket number is a 13-digit numeric string: the first three digits are the airline's ticketing code (001 = American Airlines, 016 = United, 180 = Korean Air), followed by a 10-digit serial number.

How travel changes every layer — and where the implementation diverges.

The full 4-Layer Agent-Ready Model is universal. Travel does not change the model — it changes the implementation of every layer, more deeply than most verticals. The table below maps the generic layer to the travel-specific implementation and flags where travel materially diverges.

The MCP tool surface for travel

For the MCP protocol primer — JSON-RPC envelope, tool schema format, transport options — see the MCP spoke. For the UCP identity delegation spec, payment model, and cancel/refund state machine, see the UCP spoke.

Expedia, Booking.com, Airbnb — the aggregator layer above the GDS.

Online travel agencies sit in the stack between the GDS/NDC supplier layer and the end consumer. They have their own inventory aggregation, pricing engines, and booking systems. For AI agents routing hotel searches through OTA APIs, the commercial tradeoff is real: OTA bookings carry commission costs (typically 15–25% for Booking.com and Expedia) and guests booked via OTA do not automatically earn loyalty points through the chain program. Direct-channel API access is commercially preferable for hotel operators deploying AI agents — but it requires certified-partner agreements that are not self-service on day one.

Marriott, Hilton, IHG, Hyatt — and the loyalty-number wrinkle.

The four major US hotel chains have distinct API access models. None is self-service in the way Amadeus Self-Service is — every direct-channel hotel API requires a certified-partner agreement. The commercial rationale for building direct-channel integrations despite this friction is compelling: direct-channel bookings enable loyalty point accrual, elite-tier benefits (free breakfast, late checkout, room upgrades), and full CRS data fidelity. OTA-routed bookings typically do not.

The loyalty-number wrinkle — Layer 4's most travel-specific requirement

Every major hotel chain assigns points and elite night credits only when the booking carries the member's loyalty number and routes through a qualifying channel (direct channel or certified partner channel). An AI agent acting on a user's behalf must handle a four-part loyalty workflow:

1. Store and retrieve per-chain loyalty numbers — Marriott Bonvoy number, Hilton Honors number, IHG One Rewards number, World of Hyatt number — securely in the traveler profile, with explicit user authorization for the agent to use them.
2. Pass the number in the booking API request — in the correct field for the specific CRS or hotel API. The field name and format vary by system.
3. Verify the booking confirmation shows the loyalty number attached — a booking confirmation without the loyalty number means the stay will not earn points even if the number was submitted.
4. Flag non-qualifying OTA channels — when routing a hotel search through Expedia Rapid or Booking.com Demand API, explicitly inform the user that loyalty points will not accrue and offer a direct-booking alternative at the chain rate if available.

This is a Layer 4 (UCP) identity-delegation requirement with no analog in most other agent-commerce verticals. The agent cannot earn points on the user's behalf without explicit credential access, and those credentials must be carried through the booking API call — not just stored client-side.

Agent-initiated round-trip booking — six steps from search to calendar sync.

This walkthrough uses the Amadeus Self-Service API as the reference implementation. Critical reminder: at the Self-Service tier, Step 4 creates a PNR but does NOT issue a ticket — the PNR is routed to a consolidator queue for ticketing. The 13-digit ticket number is returned by the consolidator after processing. Scenario: agent books round-trip LAX → JFK, June 15–20, economy, one adult, one checked bag, seat 20D outbound, five-night hotel in New York.

Step 1 — Flight Search

GET https://api.amadeus.com/v2/shopping/flight-offers
  ?originLocationCode=LAX
  &destinationLocationCode=JFK
  &departureDate=2025-06-15
  &returnDate=2025-06-20
  &adults=1
  &travelClass=ECONOMY
  &nonStop=false
  &currencyCode=USD
  &max=10
Authorization: Bearer {oauth_token}

Response returns an array of flight-offer objects. Each includes: itineraries (array of legs with segments — carrier, flight number, departure/arrival IATA codes and times), price (base, total including taxes, per-traveler breakdown), fareDetailsBySegment (fare basis code, booking class, cabin, includedCheckedBags.quantity), and travelerPricings.

Step 2 — Confirm Price and Add Bag

Pass selected offer to Flight Offers Price with bags. Always call this step immediately before presenting final booking confirmation — never use a cached search price.

POST https://api.amadeus.com/v1/shopping/flight-offers/pricing
  ?include=detailed-fare-rules&include=bags

Body: {"data": {"type": "flight-offers-pricing", "flightOffers": [{...selected_offer...}]}}

Response confirms current price, returns fare rules as TermAndCondition objects (categories: REFUND, EXCHANGE, CANCELLATION), and returns baggage catalog with pricing per segment. Surface the REFUND and CANCELLATION categories to the user before they confirm the booking.

Step 3 — Add Seat via Seatmap Display

Call Seatmap Display to get cabin layout. Seat 20D shows seatAvailabilityStatus: "AVAILABLE". Add seat to the flight offer object:

"fareDetailsBySegment": [{
  "segmentId": "1",
  "additionalServices": {
    "chargeableSeatNumber": "20D"
  }
}]

Re-price via Flight Offers Price to get final total including seat fee before proceeding to PNR creation.

Step 4 — Create PNR (Book Flight)

POST https://api.amadeus.com/v1/booking/flight-orders

{
  "data": {
    "type": "flight-order",
    "flightOffers": [{...final_priced_offer...}],
    "travelers": [{
      "id": "1",
      "dateOfBirth": "1985-04-12",
      "name": {"firstName": "JANE", "lastName": "SMITH"},
      "gender": "FEMALE",
      "contact": {
        "emailAddress": "jane.smith@email.com",
        "phones": [{"deviceType": "MOBILE", "countryCallingCode": "1", "number": "4155551234"}]
      },
      "documents": [{
        "documentType": "PASSPORT",
        "number": "A12345678",
        "expiryDate": "2030-01-15",
        "issuanceCountry": "US",
        "nationality": "US",
        "holder": true
      }],
      "loyaltyPrograms": [{"programOwner": "UA", "id": "UA123456789"}]
    }]
  }
}

Response returns associatedRecords with GDS record locator (e.g., RXGMKL) and airline PNR code. At Self-Service tier, the PNR is queued to the consolidator; the consolidator issues the e-ticket and returns the 13-digit ticket number. Store both the GDS locator and the airline locator — the traveler needs the airline locator for check-in.

Step 5 — Hotel Booking

GET https://api.amadeus.com/v1/reference-data/locations/hotels/by-city
  ?cityCode=NYC&radius=50&radiusUnit=MILE

GET https://api.amadeus.com/v3/shopping/hotel-offers
  ?hotelIds=HXNYCTST&checkInDate=2025-06-15
  &checkOutDate=2025-06-20&adults=1&roomQuantity=1

POST https://api.amadeus.com/v1/booking/hotel-orders

The hotel-offers response includes policies.cancellation — parse this object and surface the exact cancellation deadline and penalty to the user before confirming. The hotel-orders body includes offerId, guests (with name and loyalty number), and payment. Response returns hotel confirmation number.

Step 6 — Calendar Sync and Confirmation

The agent constructs a schema.org/FlightReservation and schema.org/LodgingReservation JSON-LD payload from the booking data, embeds it in the confirmation email, and pushes calendar events (departure, return, hotel check-in, check-out) to the user's connected calendar service. This is the only step where Schema.org appears — as post-booking normalization for the confirmation and calendar entry, not as the booking request schema.

Hospitality-specific gotchas

Cancellation policy variance: Hotel cancellation policies vary per rate type, not per brand. The same Marriott property may offer a fully refundable rate (cancel 24 hours prior), a semi-flex rate (cancel 7 days prior with partial penalty), and a non-refundable Advanced Purchase rate. Parse the policies.cancellation object from the hotel API response — do not infer cancellability from the rate name.

Early check-in / late check-out: These are often chargeable ancillaries, availability-dependent, and not bookable via standard hotel APIs at most chains. They require either a direct call to the property or a post-arrival request. Surface check-in: {earliest: "15:00", note: "early check-in subject to availability, may incur fee"} from the API and explicitly flag that confirmed early check-in is not available programmatically.

Hotel SSRs vs. airline SSRs: Airline SSRs use IATA-standardized codes (WCHR, BSCT, VGML). Hotel special requests are free-text notes to the property — no standardized SSR schema exists for hotels. Capture requests like "ground floor room" or "crib needed" as free-text guestRequests and confirm with the property that the request is acknowledged but not guaranteed.

Car rentals and cruises: Car rental GDS integration follows the same agency model — rental content sits alongside flights in Amadeus, Sabre, and Travelport. Cruises are largely outside GDS scope; cruise bookings route through cruise-line reservation systems (Carnival's POLAR, Royal Caribbean's C2C) with limited GDS connectivity. Most cruise-capable OTAs access cruise inventory via direct cruise-line APIs rather than GDS feeds.

Eight ways travel agent integrations break in production.

1. Moving Amadeus Self-Service to production without a consolidator agreement

Self-Service users cannot issue tickets directly — this is the non-negotiable production gating fact for the platform. Without a consolidator agreement, Flight Create Orders creates a PNR that is never ticketed. The booking lapses at TTL, the user loses their seat, and no payment was collected. Fix: identify an IATA/ARC-accredited consolidator before any production traffic, confirm their queue-monitoring process for PNRs created by your system, and document the escalation path for PNRs approaching TTL without ticketing confirmation.

2. Caching flight prices and presenting them as current

GDS fare prices fluctuate continuously. A price held in cache for more than a few minutes may be invalid — the seat may no longer exist at that price, or at all. Flight Offers Price exists specifically to re-validate before presenting a final booking confirmation. Fix: always call Flight Offers Price (or NDC OfferPriceRQ) immediately before the user confirms — never from a cached search result.

3. Skipping fare-rule retrieval before booking

An agent that books without surfacing cancellation and change penalties creates liability when the user discovers they cannot receive a refund on a non-refundable ticket they thought was refundable. Fix: call Flight Offers Price with ?include=detailed-fare-rules, parse the TermAndCondition objects, and surface the REFUND and CANCELLATION categories to the user before they confirm. This step is mandatory, not optional, for any agent acting on a user's behalf.

4. Booking hotels via OTA channel while presenting loyalty points as a benefit

OTA-routed hotel bookings (Expedia Rapid, Booking.com Demand API) typically do not qualify for chain loyalty points. Presenting loyalty accrual as a booking benefit when the booking channel does not qualify is misleading. Fix: for users with active Marriott Bonvoy, Hilton Honors, IHG One Rewards, or World of Hyatt accounts, route bookings through direct-channel hotel APIs or explicitly inform the user that OTA bookings are non-qualifying. Provide a direct-book option at the chain rate.

5. Passing a single record locator to the traveler for a multi-airline itinerary

A codeshare itinerary operated by two airlines generates two record locators — one per operating carrier's CRS — plus the GDS locator. The traveler needs the operating carrier's record locator for check-in, not the GDS locator. Providing only the GDS locator means the traveler cannot manage their booking on the airline's website. Fix: extract associatedRecords from the booking response and surface the carrier-specific record locator to the traveler for each operating carrier.

6. Ignoring SSR codes for special needs passengers

Failing to send SSR codes results in unmet accessibility, dietary, or infant needs at the airport. A wheelchair request not submitted via WCHR SSR before check-in cannot be guaranteed. Fix: build SSR defaults into the traveler profile and inject them automatically at PNR creation time. Include WCHR, VGML, BSCT, UMNR as explicit tool parameters in the create_pnr MCP tool schema with a profile-lookup step before booking.

7. Attempting to void a ticket after BSP/ARC remittance

Post-remittance voids are not possible — the settlement has already occurred. Post-remittance cancellations must go through formal BSP/ARC refund procedures, which take days and incur carrier-imposed fees. Fix: implement a real-time ticket status check before any cancel/void operation. Route void requests to the consolidator before the remittance deadline (typically daily or twice-daily settlement). If the remittance window has closed, initiate the refund process and set user expectations accordingly.

8. Treating NDC offer IDs as persistent across sessions

NDC OfferItemID and ShoppingResponseID are session-scoped — they expire after minutes to hours depending on the airline. An agent storing an NDC offer ID for later retrieval will receive an invalid-offer error on OrderCreateRQ. Fix: never persist NDC offer IDs across user sessions. If a user returns to a booking flow after session expiry, always initiate a fresh AirShoppingRQ rather than attempting to reuse a stored offer ID.

Frequently asked questions about agent commerce for travel.

Deploying an AI agent for travel booking, in five steps.

Each step mirrors the HowTo JSON-LD in the head of this page word for word. Execute in order — each step depends on the one before it. The whole sequence is a 30-day build, not a weekend project.

Step 1 — Establish API access and ticketing authority

Register with at least one GDS (Amadeus Self-Service at developers.amadeus.com for fastest start) or an NDC aggregator (Duffel for broader airline coverage including accreditation). Identify a consolidator for ticket issuance if using Amadeus Self-Service — this is mandatory, not optional. Separately, apply for Expedia Rapid API or Booking.com Demand API partnership for hotel inventory. Obtain API credentials, complete sandbox testing, and confirm the ticketing or booking chain before handling any real travelers.

Step 2 — Build normalized traveler profiles with credential delegation

Design a traveler data model that stores, per-user: legal name (as on government ID), passport details, loyalty program numbers per chain (airline FFP numbers and hotel loyalty numbers for Marriott Bonvoy, Hilton Honors, IHG One Rewards, and World of Hyatt), dietary and accessibility SSR codes, seat preferences, and payment tokens. Implement the credential-access controls required by the UCP spec — users must explicitly authorize the agent to use their loyalty numbers and payment methods for booking.

Step 3 — Implement the MCP tool layer

Build and expose the full travel tool set: search_flights, price_flight, get_fare_rules, check_seat_availability, search_hotels, check_hotel_availability, create_pnr, add_ssr, book_hotel, cancel_reservation, and get_reservation_status. Each tool should enforce the sequence constraints of the booking flow — fare rules must be retrieved before booking confirmation; seat selection must be repriced before PNR creation. Reference the MCP spoke at /agentmall_spoke_mcp for tool description schema format.

Step 4 — Handle fare rules, cancellation policies, and loyalty implications before booking

Before any booking confirmation, the agent must surface to the user: (a) whether the fare is refundable, partially refundable, or non-refundable with the exact penalty amount from fare rules; (b) whether the hotel rate is cancellable and by what deadline; (c) whether the booking channel qualifies for loyalty points. This is not optional — it is the core UCP trust requirement for agent-mediated travel transactions where the agent acts on the user's behalf without a human agent to explain trade-offs.

Step 5 — Implement post-booking lifecycle management

Flight bookings do not end at ticket issuance. The agent must monitor: TTL deadlines (cancel before TTL to avoid auto-cancel without refund), schedule changes pushed by airlines (requiring user notification and potentially re-booking), day-of-travel IROPS (irregular operations) including delays and cancellations requiring rebooking, and post-travel expense and reconciliation. Build queue monitoring or webhook handling for airline schedule change notifications from the GDS, and ensure the cancel and refund tool chain can execute within BSP/ARC remittance windows.

Next stops in the AgentMall guide.