The Sabre API is the set of programming interfaces that lets software search, book and service trips on the Sabre global distribution system. Testing it is free through a Sabre Developer Hub account. Going live needs a signed contract, a pseudo city code (PCC), production credentials and a certification review. For most teams that takes several months.

This guide walks through every step in order: what is in the API, what the sandbox can and cannot do, what Sabre asks for before it signs, which credentials you get, and where the time goes. The facts come from Sabre’s own developer pages and a published guide by a Sabre Authorized Developer, checked in September 2026. At the end, you will see when a direct Sabre connection makes sense and when it does not.

What the Sabre API Covers

Sabre is one of the three big GDS networks, with Amadeus and Travelport. If those terms are new, start with what a GDS is. Sabre grew out of American Airlines’ reservation system and is strongest in air travel, especially in North America. On its developer site, Sabre says it holds 75 percent of North American managed business travel.

The API is not one endpoint. It is a catalogue of products, grouped roughly like this:

Area What you can do
Air shopping Search fares and availability across GDS, low-cost carrier and NDC content
Booking Create and manage PNRs (passenger name records) and orders
Ticketing and servicing Issue tickets, exchange, refund, add ancillaries
Hotels, cars, rail Shop and book non-air content
Agentic tools An MCP server that exposes shopping, booking and servicing to AI assistants

That last row is new. An MCP (Model Context Protocol) server is a standard way for an AI assistant to call tools, and Sabre now offers one for its own APIs.

Is the Sabre API Free?

Testing is free. Live use is not. Sabre runs three environments, and they differ in what your credentials unlock:

Environment Credentials What you can do Cost
Try it Out Test credentials from a free Developer Hub account Search and testing calls on supported REST APIs Free
CERT Your Sabre API credentials, including your PCC Full end-to-end workflow testing Needs a Sabre relationship
PROD Production credentials from your account team Live bookings Commercial contract

So a developer can sign up today and start seeing real response shapes straight away. What they cannot do on Try it Out is book a real passenger. Every environment uses the same OAuth pattern: you get a token and pass it as an Authorization: Bearer header on each call. Only the endpoint and the credentials change.

Sabre’s developer pages list no production prices. They are agreed in the contract, which is why the next sections matter more than any price list.

What Sabre Asks for Before It Signs

Before the technical work, you must qualify as a Sabre-connected agency. According to AltexSoft, a Sabre Authorized Developer, you should prepare three things:

  • Proof of a legal business entity.
  • Proof of past performance — optional, for agencies already trading.
  • Industry accreditation for selling air tickets.

The accreditation is the one that stops most startups. To sell flights in the US you need an ARC number (Airlines Reporting Corporation). Outside the US you need an IATA number with access to BSP, IATA’s Billing and Settlement Plan. If you have neither, you can book under a host agency or an airline consolidator that holds them, and submit their details instead.

Some places add their own rules. In the US, California, Florida, Washington and Hawaii have Seller of Travel laws. Check your own market before you apply.

How to Get Sabre API Access, Step by Step

Sabre’s own “move to production” workflow has seven steps:

  1. Contact Sabre. New customers start with the agency sales form. Expect questions about your website, your IATA or ARC number and your annual booking volume.
  2. Agree commercial terms. You discuss the use case and sign the required documents.
  3. Choose the API product. Most APIs come under one Sabre APIs product. Some premium solutions need a separate order and contract.
  4. Receive an SC Code and a PCC. The SC Code is linked to your contract. The PCC defines your workspace.
  5. Place the order on the Sabre Store. Here you choose options such as the number of concurrent API sessions.
  6. Receive production credentials. You get a temporary password that expires in 24 hours, and set a permanent one.
  7. Go live on OAuth v3, after certification.

Step 5 is easy to skip past, but it matters. The number of concurrent sessions you order caps how much traffic you can send at once. Size it for your busiest hour, not your average one.

The Credentials, Explained

Sabre’s vocabulary is the first wall a new developer hits. These are the four you will see:

Credential What it is
PCC (pseudo city code) Your Sabre workspace. It sets permissions, geographic coverage and environment, and also opens Sabre Red 360, the agent desktop
iPCC (internet PCC) A PCC typically issued to OTAs for API-only use
EPR (employee profile record) A profile linked to a PCC that controls what one user or system can do. Production API orders are tied to a “robotic” EPR
Client ID and Client Secret Identify your application to Sabre. Often optional, but Sabre recommends them when several platforms share one PCC

Two of these shape your product, not just your login. Your PCC’s region decides where your content is deepest. AltexSoft reports that if you search outside the region you agreed, search depth drops and results can be incomplete. And each EPR’s permissions decide what your code is allowed to do.

What Drives the Cost of a Sabre Integration

With no public price list, the cost of a Sabre connection comes from four places:

Cost driver Why it grows
The contract Terms, fees and minimums are negotiated per customer
Scope changes Each new API or new region needs a contract amendment and a re-configured account. AltexSoft reports this can take a couple of months
Engineering Shopping requests are large and Sabre-specific; the full flight flow spans several APIs
Maintenance Version updates, deprecations and certification for new flows never stop

The second row is the one teams underestimate. A plan to “add hotels next quarter” is a commercial project as well as a technical one. For a wider breakdown across all three networks, see our guide to GDS API cost.

SOAP or REST?

Sabre offers both. New products, including the agentic APIs, are REST and JSON. But SOAP still dominates the catalogue: AltexSoft’s guide, last updated in November 2025, counts 242 SOAP APIs against 175 REST APIs.

That split has a practical effect. Sabre’s SDKs for SOAP are mature, and PHP, .NET and Java have good native SOAP libraries. JavaScript and TypeScript teams get less support for the older style and often need custom work.

The safe way to choose is to map your booking flow first. List every step — search, revalidate, book, ticket, change, cancel — and find the API for each in the Product Catalog. If one step only exists in SOAP, your integration needs SOAP, whatever you prefer.

How Long It Takes

Three stages, in sequence:

Stage Typical length
Business side: intake form, contract, credentials Several months
Build: your team against CERT Depends on the team and the scope
Certification: Sabre reviews your flows before live data 4–8 weeks

AltexSoft puts the whole journey at “several months to a full year”, from intake form to launch. Tripgic’s GDS page gives the same range for any direct GDS connection: six to twelve months per GDS.

Certification is where plans slip most. Sabre specialists test each request and response in your environment. A flow that “works” in your own tests can still fail their review.

The Flight Booking Flow in Sabre

A complete flight flow calls several APIs in order:

  1. Search. Return a list of offers — up to 200, sorted by price.
  2. Revalidate. Check that the chosen fare is still available at the same price.
  3. Book. Create the PNR. By default it must be paid and ticketed within 24 hours, though this can be negotiated.
  4. Charge. Take payment for the ticket.
  5. Ticket. Issue the e-ticket and poll the PNR to track the ticketing queue.

AltexSoft’s team polls every five minutes and hands the booking to a human agent after five failed checks. That fallback is worth copying: automated ticketing needs a manual path.

Changes and cancellations are a separate set of APIs, and splitting one leg from a multi-leg trip is the hardest case. Many OTAs start by handling those manually in the agent desktop. Our guide to the airline ticketing API covers this stage in more depth.

Before You Contact Sabre: a Checklist

Most delays in a Sabre project start before any code is written, with a question the team could not answer on the first sales call. Prepare these answers first:

Question Why Sabre needs it
Do you hold ARC or IATA accreditation? If not, who is your host agency or consolidator? It decides whether you can ticket at all, and under whose identity
Which markets will you sell in? It sets your PCC’s region, and search is deepest there
Which content do you need? GDS fares, low-cost carriers, NDC, hotels, cars Each API is scoped in the contract. Adding one later is an amendment
What volume do you expect at your busiest hour? It sizes the concurrent sessions you order
Which booking steps will you automate? Search, book, ticket, change, cancel It decides your API list, and whether you need SOAP
Has anyone on your team built on a GDS before? Teams new to GDS work face a long learning curve, which AltexSoft calls inevitable for newcomers

A team that walks in with these answers moves through the business stage faster. A team that does not tends to discover them one amendment at a time, and AltexSoft reports each one can take a couple of months.

Direct Sabre, or Sabre Through an Aggregator?

A direct connection is right for some businesses. If you sell high air volume, already hold IATA or ARC accreditation, and have engineers with GDS experience, the effort pays off in control.

For everyone else, the usual alternative is an aggregator: one API that already holds the GDS connections. Here is how the two paths compare:

Direct Sabre Through an aggregator
Contracts One with Sabre, then one per GDS you add One
Time to first booking Six to twelve months per GDS Days or weeks
Data format Sabre-specific, SOAP and REST One normalized schema
Adding Amadeus or Travelport A new project each time Already included
GDS certification Yours to pass, per flow Not your queue

Tripgic is built for this second path. It connects to Amadeus, Sabre and Travelport through one REST API, under one commercial relationship, and returns normalized JSON with duplicate flights across sources removed. Sandbox credentials are issued free after a short KYC check. Pricing is a one-time activation plus the supplier’s net fare and a flat fee per transaction — never a percentage. Which plans include full GDS access is on the pricing page.

For a side-by-side of the three networks themselves, read Amadeus vs Sabre vs Travelport, and for how the other two networks let you in, our Travelport API guide and Amadeus API guide. And if your team is weighing the whole question, our build vs buy guide sets out the trade-offs.

Final Thoughts

The Sabre API is open to explore and closed to use until you sign. Anyone can get test credentials today. Live bookings need accreditation, a contract, a PCC, a sized order and a passed certification review.

None of that is a reason to avoid Sabre. It is a reason to decide two things before you start: what you will sell, and where. Those two answers fix your contract, your PCC and most of your timeline. If the answer is “several GDS, soon”, compare the direct path with an aggregator before you fill in the first form.