Best Practices

The following best practices are tips to help you build high quality applications using Sabre APIs—your door to the Sabre travel marketplace.

With our Sabre APIs portfolio of over 100 SOAP APIs and a growing collection of REST APIs, you can incorporate services across the entire travel journey—from dreaming, to planning, to purchasing and servicing trips.

Take a few minutes to browse our growing list of best practices and sample workflows—maybe even contact us with a few ideas of your own to help your fellow developers. These were obtained from subject matter experts who work with developers during the development and implementation of various Sabre APIs (primarily SOAP APIs) and do not represent all services.

Stay tuned for more tips or contact your Sabre representative to be added to our customer distribution list.


Session and Sessionless Token Management

Session and sessionless transactions

Sessionless

In "sessionless" calls no transient information is kept on the Sabre servers. Therefore, sessionless tokens are generally used for the operations that can be completed in a single step like air shopping or orchestrated (single step) booking. Sessionless tokens can be obtained from the Create Access Token API (for SOAP APIs) or the Authentication API (for REST APIs).

Session

Multi-step processes that use transient information stored on the Sabre servers require a session. To open a session, a session token must be obtained from the Create Session API. This thereby automatically and simultaneously establishes and allocates a session on the Sabre side from the subscriber's session pool.

Top 5 reasons to go sessionless

You can now authenticate to the Sabre APIs infrastructure without the need for sessions using sessionless tokens. To determine whether an API supports sessionless tokens, check the new "API Information" boxes. We’re rolling them out to documentation pages on Dev Studio–starting with APIs that support sessionless tokens.

See what developers are saying are the top 5 reasons to go sessionless:

#1: A TAM pool is not required when using sessionless tokens

A TAM pool is not required for APIs that support sessionless tokens, such as Bargain Finder Max. Sessionless token authentication is available for most REST APIs. We are working diligently to enable sessionless token authentication across all Sabre APIs. In the meantime, we’ll be adding “API Information” boxes to documentation pages across Dev Studio, starting with APIs that support sessionless tokens.

#2: A Connection Manager (CM) is not required when using sessionless tokens

A Connection Manager (CM) is not required when using sessionless tokens. Sessionless tokens are good for a limited period of time and do not need to be refreshed. See also: our best practices and recommendations on handling sessionless token expirations.

On the other hand, session tokens time out after 15 minutes of inactivity and require you to design logic within your CM that will keep sessions alive. For more information, see our step-by-step recommendations for designing a session token workflow within your CM.

#3: Sessionless tokens do not need to be refreshed

Sessionless tokens are good for a limited period of time and do not need to be refreshed. See also: our best practices and recommendations on handling sessionless token expirations.

On the other hand, session tokens are set to time out after 15 minutes of inactivity; therefore, you must design logic within your CM to refresh tokens in order to extend the life of the token. For more information, see our step-by-step recommendations for designing a session token workflow within your CM.

#4: Sessionless tokens are not affected by weekly NORM maintenance

Sessionless tokens are not affected by weekly NORM maintenance. NORM OAA runs Sabre-wide each Sunday morning at 00:15 U.S. Central Time and clears all active session tokens. Therefore, it is required that you to design a workflow within your CM to obtain all new tokens after these weekly maintenance activities.

#5: Sessionless tokens are recommended for high volume transactions

Sessionless tokens are recommended for high volume transactions—one token can be used for multiple (concurrent) calls, until the token expires. (This is not possible using a session token, as you need one session token for each concurrent call.) Hence, this removes the burden of managing sessions, particularly for high-volume shopping requests with APIs that support sessionless tokens, such as Bargain Finder Max. Check out our new Session and Sessionless Token workflow for a typical shopping and booking process which combines session and sessionless tokens.

Session v. sessionless tokens at-a-glance

Get a sessionless (access) token

SOAP APIs

  1. Get a sessionless token using the SOAP API sessionless authentication instructions.
  2. Send the access token with each subsequent SOAP API call.
  3. Reuse the same access token for multiple requests, until it expires.
  4. A sessionless token is good for a limited period of time. See also: our best practices and recommendations on handling sessionless token expirations.

REST APIs

  1. Get a sessionless token using the step-by-step REST API sessionless authentication instructions.
  2. Send the access token with each subsequent REST API call.
  3. Reuse the same access token for multiple requests, until it expires.
  4. A sessionless token is good for a limited period of time. See also: our best practices and recommendations on handling sessionless token expirations.

Sessionless (access) tokens returned via REST and SOAP API authentication are the same type of token and can be used interchangeably between REST and SOAP. Check out our new Session and Sessionless Token workflow for a typical shopping and booking process which combines session and sessionless tokens.

Get a session token

  1. Get a session token using the SOAP API session authentication instructions.
  2. Behind the scenes, the Sabre APIs infrastructure authenticates the security credentials in the request and opens the door to Sabre APIs–allocating a Sabre session from your session (TAM) pool and authorizing you to call Sabre APIs. Once a session becomes active, it is no longer available in your pool until the session times out.
  3. Send your session token with each subsequent SOAP API call.

Handling sessionless token expirations

A sessionless token has a time-to-live (TTL) of 604800 seconds. We recommend you design logic to handle token expirations using the recommendations below.

REST APIs

  • A sessionless token is good for a limited period of time described by expires_in, in seconds. We recommend you design logic that keeps track of the time-to-live.
  • Write code to the error response 401 Unauthorized from the API endpoint to get a new token when an expired token is detected.
  • Design logic that detects whether the concurrent-transactions per second (TPS) limits are exceeded for an API. If TPS limits are exceeded, the system will throttle the requests and respond with a 429 too many requests error.

SOAP APIs

  • Write code to the error response USG_INVALID_SECURITY_TOKEN to get a new token when an expired token is detected.
  • Design logic that detects whether the concurrent-transactions per second (TPS) limits are exceeded for an API. If TPS limits are exceeded, the system will throttle the requests and respond with a USG_SERVICE_IS_BUSY error.

Handling sessions and session token expirations

We recommend you design an in-house solution (a.k.a. Connection Manager) to handle sessions using the recommendations below.

  1. Design logic to keep sessions alive by refreshing your token using the Refresh Sessions API. Tokens must be refreshed or they will time out after 15 minutes of inactivity (in most cases). As long as you use the session token (and conversation ID) from a specific session and there is activity, your session remains active, and your content in the Sabre work area retained.
  2. Write code to the error response USG_INVALID_SECURITY_TOKEN to issue a new token when an expired token is detected.
  3. Design logic around weekly session maintenance activities to issue new token(s) after token Sabre clean-up activities. Session tokens are subject to weekly maintenance clean-up activities by NORM OAA. NORM OAA runs Sabre-wide each Sunday morning at 00:15 U.S. Central Time and clears all active Sabre APIs sessions.

Note: much like the concept of a library–where you borrow a book, read it, and give it back–if you’ve designed your Connection Manager with the above logic, then there is no need to design logic to close sessions. The only reason to close a session is if the session becomes unstable. See also: the SOAP API status codes and errors page for more information on the applicable errors.

Create an in-house Connection Manager

Design an in-house solution for consuming SOAP APIs to manage and optimize connection pools, referred to as a "Connection Manager."

Your Connection Manager should be designed with logic to keep sessions and connections alive. (A connection is requested to call SOAP APIs. A session is allocated from your TAM pool.)

Retrieve a connection from the pool only when immediately necessary. This allows you to keep a buffer of unused connections to accommodate for unanticipated spikes in traffic (such as that from fare sales or weather-related rescheduling).

Obtain a session token, perform one or more calls and release back to your TAM pool. Rather than open a new connection each time a service is called, the client application should obtain a session token from the Connection Manager, perform one or more calls, and then release the token back to the pool.

Maintain a separate pool for stateless transactions. Reduce the overhead of creating and closing new connections by maintaining a separate pool for stateless transactions. This will allow your application to quickly obtain multiple tokens simultaneously. See also: maintain a separate pool for shopping and booking processes for further details.

Detailed information on advanced connections using a connection pool or a connection manager, can be found in the Connection Management guide on the SOAP basics: Getting Started page.

Design around weekly session maintenance

Design around weekly SOAP APIs session maintenance. Design a session management workflow within your Connection Manager around weekly Sabre maintenance activities.

To avoid invalid session token errors as result of NORM OAA maintenance, you must close and reopen all pooled sessions between 10:00 AM and 12:00 Midnight U.S. CST on Saturday.

A Sabre system maintenance application known as NORM OAA runs Sabre-wide every Sunday morning at 00:15 U.S. CST.

NORM OAA takes about five minutes to run worldwide and clears every AAA in Sabre. It closes and clears all OTA_PingRQ (refresh) sessions in the pool. All logged-in Sabre users, including active Sabre APIs sessions, are required to log-out and log-in again once NORM OAA begins to run.

Detailed weekly connection maintenance information can be found on the Getting Started page in the Sabre Weekly System Maintenance – NORM OAA document.


Optimize

Optimize transactions

Use multiple threads simultaneously to speed processing. Design a workflow that will allow you to use multiple threads simultaneously (whenever possible) to speed processing for stateless transactions.

Sabre APIs are synchronous, which means that a single connection cannot be used for multiple, simultaneous requests. A response to the current request must be received before sending a new request.

Obtain as many tokens as necessary and launch a request using each token. To send multiple requests at the same time, obtain as many (unique) tokens as necessary from the pool and launch a request using each token.

For example, although air availability requests from a multi-airport city (MAC) (such as Los Angeles) can be sent sequentially; however, the most efficient method would be to send multiple requests simultaneously and combine the results.

Couple session pools and persistent HTTP connections

Maintain a pool of open SOAP APIs connections and use as needed.

Design a workflow within your Connection Manager that will allow you to couple session pools with persistent HTTP connections, which can minimize the number of HTTP handshakes required to complete a transaction.

  • Persistent connections are long lived TCP/IP connections that can handle multiple HTTP requests during their life span. The idea is to maintain a pool of opened connections and use them as needed.
  • Every time you send a Sabre APIs request, an HTTP handshake takes place between your client and the Sabre APIs servers. This handshake generally takes a fraction of a second; however, when the client system is outside of North America, the aggregate time consumed can be significant. Sabre APIs clients may see up to a one second reduction in response time per request invocation.
  • Generally, persistent HTTP connections are enabled by default in standard client platforms, which means you may need to do nothing more than use the supported HTTP endpoints. See the SOAP APIs: environments page for the supported HTTP endpoints.

Detailed persistent connections information can be found on the Performance page in the Sabre APIs Persistent Connections Guide document.

Maintain a separate pool for shopping and booking processes

Release a SOAP API session token back to your Connection Manager after a search request is complete. Generally, shopping workflows are stateless, short in duration and often completed in a single call.

We recommend you design a workflow that will allow you to release a token back to your Connection Manager after a search request is complete. For example:

  • The client application sends one or more shopping or availability requests, which can be launched in parallel, then returns the data for the traveler to review.
  • While the traveler is making a selection, there is no need to keep a connection unused. The token can be returned to the pool for other client applications to use.

Maintain a separate pool for SOAP API booking processes. Generally, booking workflows require two or more calls to complete.

We recommend you maintain a separate pool for booking processes, given the potential for revenue generation. For example:

  • When the traveler has selected an itinerary to purchase, the booking details in memory are used to form the booking request.
  • At this time, the client application should retrieve another session from the pool and sequentially launch the request to book the itinerary segments and complete the Passenger Name Record (PNR). Note: a PNR must be completed prior to a booking.

Use HTTP data compression

Direct traffic to a compression-enabled endpoint (whenever possible). Design a workflow that will allow you to use data compression (whenever possible) by directing your SOAP API traffic to one of the supported compression-enabled endpoints.

  • HTTP data compression reduces the size and overall message latency to transmit the response payload. It is particularly important for high-volume implementations.
  • Generally, HTTP compression is enabled by default in standard client platforms, which means you may need to do nothing more than use the supported HTTP endpoints. If a compressed response was returned, the Content-Encoding field in the HTTP header will contain 'gzip'.

See the Environments page for the supported HTTP endpoints.

Optimize performance

Use inline compression whenever possible. Design a workflow that will allow you to request inline compression (whenever possible), and run a base64 decoder and gzip to restore the response payload to an XML document.

The REST and SOAP Bargain Finder Max APIs allows customers the ability to request inline compression for response payloads, which contains an optional parameter to return a base64-encoded 'gzip' file.

Generally, base64 and gzip compression is supported by standard development platforms. Controlled testing prior to production implementation is strongly advised to determine net reduction in response time.

SOAP APIs

  • To request this option for the SOAP API version of Bargain Finder Max, set the CompressResponse value to 'true'.

REST APIs

  • To request this option for the REST API version of Bargain Finder Max, set the Accept-Encoding value to 'gzip'.

Detailed data compression information can be found on the Performance page in the Compression Developer’s Guide & Sample Project document.


Errors

Gracefully handle and design around errors. Design an error handling workflow that will allow you to programmatically recover a business transaction in progress without affecting customer experience.

Common errors

USG_INVALID_SECURITY_TOKEN

The session has been closed or has expired. Retrieve a new session token.

USG_RESOURCE_UNAVAILABLE

The TAM pool has been exhausted. Close any unused, existing sessions.

USG_AUTHENTICATION_FAILED

Invalid or expired credentials. Check your credentials.

USG_AUTHORIZATION_FAILED

Invalid attribute or service does not exist. PCC is not permitted to access requested service, contact your Sabre representative.

USG_INVALID_EBXML

Request doesn’t conform to the EbXML standard. ebXML element or attribute is missing or incorrectly formed in SOAP envelope.

Detailed information and common errors and corrective actions, can be found on the status codes and errors page.


Tools

Performance Monitoring

Use a performance monitoring tool to anticipate resource requirements. Design an early warning system into your application with automated workflows around performance monitoring and transaction and application logging.

Zabbix

  • Application logs are an essential component to security and troubleshooting operations. They can also be used to identify trends and anticipate resource requirements.
  • Tools such as Zabbix allow you to simplify the task of instrumenting and real-time monitoring of applications, servers, virtual machines, and network devices. Zabbix is a free, open source and cross-platform monitoring solution.

In addition, there are many other open source options and 3rd party vendors that will help you design, implement, and run monitoring and logging solutions to help your business run smoothly.

Performance Testing

Use a tool which tests and monitors performance and response times. Design a workflow that will allow you to easily identify and resolve performance bottlenecks.

soapUI

  • Tools such as SoapUI allow you to create functional, regression, compliance, and load tests, such as the ability to isolate and measure individual Sabre APIs response time. Basic SoapUI is a free, open source and cross-platform functional testing solution. In addition, it is available as a plugin for development environments, including Eclipse, Maven, and NetBeans. There is also a paid version (SoapUI NG Pro) with additional features, tools, and user support.

Detailed SoapUI implementation instructions and workflows can be found on the SOAP basics: Getting Started page in the soapUI Test Client document. This document contains a SoapUI project file in which you can add your credentials and start consuming Sabre APIs.


Subscribe to travel event notifications

Subscribe to specific travel event notifications (such as airline schedule change notices) to reduce costs.

  • Automating repetitive tasks such as processing schedule changes usually requires that you regularly check the queue (polling). This means that a large number of requests come back negative.
  • Event Notification Services allows you to subscribe to structured XML messages which notifies you of changes to specific travel information from Sabre. Notifications are pushed to you as they occur in real-time. This reduces your costs by eliminating unnecessary scan charges. You receive only the notifications to which you subscribe.

Detailed information on Event Notification Services can be found on the Event Notification Services page.


Versioning

An important best practice to follow when planning your development is to make sure you are using the most recent version of an API. It is equally important that you periodically plan migration to an updated version of an API or to a replacement API. This guarantees that you have access to enhanced features and functionality that may have been introduced since your initial development. Sabre APIs currently support up to 5 versions of an API. Generally (and whenever possible) these five supported API versions are backwards-compatible.

Detailed versioning policy documents are available using the links below:


Support

Expedite support from the help desk

The Sabre APIs Global Customer Support Center monitors the group mailbox 24/7 and responds to emails within 24 hours or less.

To expedite your request to the help desk, please include the following:

  • The environment where the issue is occurring
  • Sabre Pseudo City Code (PCC) or domain where the issue is occurring
  • Clear, intuitive names for the input and output payloads
  • The input and output payloads attached as separate files
  • Note: If your correspondence is regarding a previously reported issue, please include the service incident (“SI”) number in the subject line of your message.

To ensure that our environment is free of viruses, our policy mandates that all messages received by Sabre from external sources follow specific file naming conventions:

  • File names must end in ".sabre.zip" or the zipped attachment will be removed by the e-mail server (for example, “docs.zip” would need to be renamed to “docs.sabre.zip”).

Detailed documentation and release notes on individual SOAP and REST APIs, is available at: https://developer.sabre.com/docs/read/Home.