How to Integrate the Sabre API into a Travel Portal

If you've already read my guide to integrating the Amadeus API into a B2B travel portal, a lot of this will feel familiar. Search is indicative, price must be confirmed live, and the booking is a separate step. The concepts carry over. What doesn't carry over is everything around them: how you get access, how you authenticate, which flavour of API you call, and how much of Sabre's behaviour is decided by agency settings you never see in a code sample.

If you're still choosing a GDS, start with Sabre vs Amadeus vs Travelport. The short version: Sabre is the natural pick when your market is the US and Canada, or when the airlines you care about distribute most strongly through it. This post assumes you've made that call and now have to build it.

Before any code: credentials, the PCC and the contract

Sabre has no equivalent of Amadeus Self-Service, where you sign up and call a production API the same week. Access works in two tiers:

• Dev Studio test credentials. Sign up on Sabre Dev Studio and you get temporary credentials for the certification environment. They're for learning: they only reach the publicly available REST APIs, and they aren't permanent. Good for a proof of concept; not something to build a business on.
• Live credentials. These come from a Sabre account manager, as part of an agency subscription or partner agreement. They're tied to your agency's configuration and unlock the full catalogue your contract covers, in both certification and production.

Three pieces make up a Sabre credential, and you'll see them everywhere:

• EPR (Employee Profile Record): the user ID.
• PCC (Pseudo City Code): the agency location the request runs under. It decides which fares, content, settings and ticketing arrangements apply. Sabre's docs also call it the group.
• Password, plus a domain, which is AA for travel agencies.

One more thing that surprises developers: some API behaviour depends on the agency's Sabre configuration, held in records like the TJR (Travel Journal Record). For example, Sabre's Create Booking API requires a specific TJR setting to store passenger types in the PNR. When a call fails in a way the documentation doesn't explain, the fix is sometimes a configuration change on the Sabre side, not a code change. Keep the client's Sabre support contact handy.

SOAP or REST? Plan for both

Sabre has been moving its catalogue to REST with JSON for years, and newer services such as the Booking Management API are REST-first. That's the right default for anything new. But a lot of established Sabre functionality and many real-world workflows still run on SOAP web services with stateful sessions, and you'll meet them as soon as you go beyond the basic shop-and-book path.

So the practical answer is: build a REST client and a SOAP client, side by side, behind the same internal interface. Sabre's own guidance is that the same credentials work for both; only the domain and the way you construct the token differ. Decide per operation which one you call, and keep that decision inside your Sabre adapter so the rest of your system never knows.

Authentication: a REST token and a SOAP session pool

REST: one token per PCC, refreshed before it expires

The REST token request has an unusual credential format. You build a user string of V1:EPR:PCC:AA, Base64-encode it, Base64-encode the password, join the two with a colon and Base64-encode the result again. That final string goes in a Basic authorization header to the token endpoint:

// C#: build the Basic credential Sabre expects
static string SabreCredentials(string epr, string pcc, string password, string domain = "AA")
{
    static string B64(string s) => Convert.ToBase64String(Encoding.UTF8.GetBytes(s));
    var user   = B64($"V1:{epr}:{pcc}:{domain}");   // always "V1"
    var secret = B64(password);
    return B64($"{user}:{secret}");
}

POST https://api.cert.platform.sabre.com/v2/auth/token
Authorization: Basic {SabreCredentials(...)}
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

You get back a bearer token that you send on every REST call. Unlike Amadeus's half-hour tokens, Sabre's sessionless tokens are long-lived, typically days rather than minutes. The pattern Sabre recommends is one token per PCC, shared by all requests on that PCC, and recreated before it expires rather than after a call fails. Store it with its expiry, refresh it on a schedule, and never request a new token per search.

SOAP: a managed pool of sessions

SOAP calls run inside a session. You open one with SessionCreateRQ, receive a security token, and send it with each request. A session holds a work area, so multi-step workflows on the same booking must stay on the same session. Sessions are a limited resource, so production systems keep a pool:

• Open a small pool at start-up and hand sessions out to requests, returning them when done.
• Keep idle sessions alive with SessionValidateRQ before they time out. It refreshes the session's timestamp without touching its content.
• Always close sessions you no longer need with SessionCloseRQ. Sabre is explicit that applications which skip it risk running out of resources.
• Expect Sabre's scheduled maintenance windows to invalidate sessions, and recreate the pool afterwards rather than letting the first customer request discover it.

Getting the pool wrong produces the worst kind of bug: everything works in testing with one user, then requests start failing under load in production because sessions ran out or quietly expired.

The core flow: search, revalidate, book, ticket

The shape is the same one every GDS imposes, and the reason is the same: a search result is a snapshot, not a promise. On Sabre the main services are:

1. Bargain Finder Max (BFM): the low-fare search. Send origin, destination, dates, passengers and preferences; get back priced itinerary options. This populates your results page. BFM is powerful and has a lot of request options, so start with a minimal request and add qualifiers only as you need them.
2. Revalidate Itinerary: take the exact itinerary the customer picked and check its price and availability live, without holding airline inventory. Sabre is clear that there's no guarantee the fare matches the earlier search, which is exactly why this step exists. If the price moved, show the new price before you take money.
3. Create Booking: create the PNR with the confirmed itinerary and traveller details. For new builds, use the Booking Management API's Create Booking (/trip/orders/createBooking), Sabre's evolution of the older Create Passenger Name Record API. It's designed to be stateless, accepts the sessionless REST token, and handles both traditional (ATPCO) and NDC content.
4. Ticketing: a booking isn't a ticket. Issuing tickets is a separate step with its own time limits set by the airline, and it's where money actually moves between your agency and the carrier. Decide early whether you ticket immediately after payment or in a controlled queue, and build for the ticketing deadline either way.

NDC content changes the booking request

Sabre now returns NDC offers (airline content distributed through the IATA New Distribution Capability standard) alongside traditional ATPCO-filed fares. For a portal, that's good news: more fares and richer airline products. But the two kinds of content don't book the same way.

• An NDC booking carries the airline's offer ID and the selected offer items from the pricing step, rather than a rebuilt itinerary. Your data model has to keep those identifiers from search through to booking.
• Servicing differs: changes, cancellations and ancillaries don't always behave the same for NDC as for traditional bookings, and some capabilities lag behind. Sabre's own documentation lists current limitations, so check them for your airlines before you promise a feature.
• Your results page should treat both as one list, but your internal offer type needs a content-source field so the booking and servicing code knows which path to take.

If you design the offer model with that field from the start, adding NDC is an extension. If you don't, it's a painful retrofit across search, booking and your admin panel.

PCCs in a B2B portal

A consumer site might run everything through one PCC. A B2B portal usually can't. Different markets, currencies, branches or contracted fares often live under different PCCs, and Sabre lets an agency work across related PCCs it has access to. Create Booking even lets you specify a different target PCC for the booking.

The design rule is simple: the PCC is configuration attached to a tenant, market or route, never a constant. Resolve it per request from your own rules (which agency, which point of sale, which fare source), cache a token per PCC, and record on every booking which PCC it was made in. Six months later, when finance asks why a booking priced differently, that field is the answer.

The rest of the B2B layer is the same as on any GDS: a markup engine that turns net fares into sell fares on the server, agent wallets modelled as an immutable ledger, multi-tenant roles, and per-agency rate limits. I've covered those in detail in the Amadeus B2B guide, and none of it changes for Sabre. That's the point of the next section.

Keep Sabre behind an adapter

Sabre's responses are large, deeply nested and full of Sabre-specific codes. Don't let them leak. Define your own internal types (an offer, a price breakdown, a booking result, a ticketing result) and write a Sabre adapter that translates in both directions. Your search page, booking flow, wallet logic and admin panel should only ever see your types.

This pays off three ways. You can move a single operation from SOAP to REST, or to a newer API version, without touching business code. You can test your booking flow without calling Sabre at all. And when you add a second GDS or a direct airline feed, it's one more adapter rather than a rewrite. I walk through that multi-supplier design in how to integrate multiple GDS providers into one booking engine.

Versioning: Sabre retires APIs on a schedule

Sabre versions its APIs and publishes a retirement schedule. Older versions of core services, BFM and Revalidate Itinerary included, get blocked in production on announced dates. A portal that integrated an API version three years ago and never revisited it will eventually stop booking.

• Pin the version of every Sabre API you call in configuration, so an upgrade is a deliberate change you can test in certification first.
• Check the retirement schedule as a recurring task, not when something breaks.
• Budget for upgrades. A version bump usually means re-testing request and response mapping, which is another reason the adapter matters: the change stays in one place.

Pitfalls I'd flag before you start

• Don't build on Dev Studio test credentials. They're temporary and limited to public REST APIs. Get the client's real certification credentials as early as possible.
• Never skip Revalidate Itinerary. Search fares are a snapshot. Confirm live before you charge.
• Manage SOAP sessions as a pool. Keep them alive, close them when done, and rebuild after maintenance windows.
• Treat the PCC as data. Resolve it per tenant or route, and store it on every booking.
• Separate booking from ticketing. Track the ticketing deadline and alert a human before it passes.
• Carry NDC offer IDs end to end. Design the offer model for both content types from day one.
• Log every request and response. With credentials masked, and searchable by PNR. Support will need it daily.
• Watch the retirement schedule. An API version you never upgrade is a production outage with a date on it.

None of this is exotic. It's the same discipline any GDS demands, with Sabre's particular mix of sessions, PCCs and configuration on top. Get the access, authentication and money flow right first, keep Sabre behind your own interface, and it becomes a dependable source of content for a portal you can grow.

Sabre API FAQs

// WRITTEN BY

Sunny Badgujar

Full-stack developer · .NET, React, SQL Server & Shopify · Jaipur, India

I build and run a live travel reservation platform connected to four GDS / supplier integrations, and I've built admin platforms for enterprise teams. I write about the problems I actually solve for clients.

About me LinkedIn Book a free 30-min call