Sabre API Customer Application IDs
API analytics is one of the most important factors in improving any API platform. Metrics are inherently valuable; tracking data on API usage, availability, uptime, and other insights is pivotal in keeping a healthy, consistent platform.
At Sabre, we are constantly thinking of ways to improve. One area of improvement is to provide better insight across our Partner Solutions, which are essential to power many parts of the Sabre business model, from travel management companies, to corporate travel departments, and travel agencies around the world.
What is a Customer Application ID?
The Customer Application ID (
CustomerAppId) is a parameter in the header used to make Sabre API requests that identifies a specific application used by our customers. This is a unique signature generated by Sabre for internal or external customer applications consuming Sabre APIs.
Some of our Partner Solutions APIs (such as Content Services for Lodging) require this information to be included in the SOAP API header.
What is a Sabre Authorized Developer Partner?
Authorized Developer Partners help power the travel industry by integrating our APIs into their applications. If you or your company are interested in partnering with Sabre, contact us here.
How are Customer Application IDs being used?
Customer Application IDs allow Sabre to track and analyze the usage of Sabre API services by specific application. This is particularly important and beneficial for:
- Authorized Developer Partners, who use multiple Travel Agency PCCs across the same application
- Travel Agencies who use the same PCC to call Sabre APIs between multiple applications from different or the same Authorized Developer Partners
Adopting the Customer Application ID into your application enables Sabre to gather better insights for faster troubleshooting and support through:
- Traffic to Sabre by application
- Traffic to Sabre by customer and application
- Types of Sabre APIs being called
- Data insights by application, such as conversion, agency efficiency, etc.
- Best practices/guidelines on identified workflow inefficiencies
How do I adopt a Customer Application ID?
A Customer Application ID (
CustomerAppId) is purely optional at the time, but we recommend using it in the header for each API request. Contact your Sabre Account Manager to begin using your individual Customer Application ID(s).
In the example SOAP header below,
<CustomerAppID> has been added:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <MessageHeader xmlns="http://www.ebxml.org/namespaces/messageHeader"> <From> <PartyId>Agency</PartyId> </From> <To> <PartyId>SWS</PartyId> </To> <ConversationId>2020.04.DevStudio</ConversationId> <Action>SabreCommandLLSRQ</Action> <CustomerAppId xmlns:ns10="http://webservices.sabre.com/"> [[Your CustomerAppId]] </CustomerAppId> </MessageHeader> <Security xmlns="http://schemas.xmlsoap.org/ws/2002/12/secext"> <BinarySecurityToken>Shared/IDL:IceSess\/SessMgr:1\.0.IDL/Common/!ICESMS\/RESF!ICESMSLB\/RES.LB!-2883248592917577082!231181!0!2</BinarySecurityToken> </Security> </SOAP-ENV:Header> <SOAP-ENV:Body> … </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Note: If you encounter the
"ERR.NGHP-DISTRIBUTION.SERVICE_NOT_FOUND" error, check the header message and ensure it does not contain
<Service>[ServiceName]</eb:Service> in the request; only
<Action> is required in the header.
Include the following in the HTTP header (key value pair). Note the dash (
ID, followed by your Customer Application ID:
POST /v2.1.0/hotel/pricecheck HTTP/1.1 Content-Type: application/json Accept: application/json Application-ID: [[Your CustomerAppId]] Authorization: Bearer … ….
What can you expect from Sabre in the future?
Further simplification to make it effortless for you to adopt new APIs into your application(s), requiring only the passing of a unique Customer Application ID once at the time of authentication, propagating to all subsequent API calls. Don’t worry; all integration being done today will not be lost, and all of our Authorized Developers will receive simple step-by-step instructions on how to adopt this feature.
Enhanced business insights for partner applications and customers consuming Sabre APIs.
Improved self-service tools leveraging Customer Application IDs.
How can I get access to Customer Application ID reports?
In the future, we will be providing self-service tools for developers. In the meantime, please work with your Sabre Account Manager.
When the new Customer Application ID implementation mentioned in your roadmap is rolled out, how much time will I have to migrate?
Sabre will work with developers to define an optimal timeline, along with providing tools and documentation on how to make this transition as smooth as possible.
What is the target schedule to rollout the new Customer Application ID implementation?
Sabre is currently working to define the timeline for delivery of the new Customer Application ID implementation. Once defined, Sabre will ensure to communicate to developers.
When the Customer Application ID implementation is rolled out, will this impact any of the current work we have done?
Current integrations will not be impacted until the transition to the new implementation is completed.
I am an Authorized Developer, and have multiple solutions that I offer to our Travel Agency customers. Should I be using the same Customer Application ID?
Yes, Sabre Authorized Developers should use a Customer Application ID per application developed. This will enable Sabre and developers to gather better insights and workflow optimization recommendations per application.
My applications consume both SOAP and REST Sabre APIs, should I be using the same Customer Application ID across both?
Yes, developers should use the same Customer Application ID per application, independent of the underlying API and technology being used.
I currently have not received a Customer Application ID for my application, who should I contact?
Please contact your Sabre Account Manager.
Should Authorized Developers include their Customer Application ID when reporting problems to API Support?
Developers should include as much information as possible when reporting issues to API Support. Customer Application IDs can also be used as an additional datapoint for troubleshooting these issues.