Get a Token
Learn how to get a token to call Sabre APIs.
Prerequisites
You have spoken to a Sabre account manager and/or signed a contract with Sabre. You know which environments you have access to. You know which Sabre APIs you have access to.
Step 1: Get your Sabre credentials
Your Sabre credentials get you access to the Sabre GDS.
Note: Get your Sabre credentials from your Sabre account manager, or get free credentials by creating a Dev Studio account.
How credentials determine your access
- Access to get/use a token
- Access to Sabre API environments
- Access to your agency's subset of Sabre APIs
- Access to your agency's subset of Sabre API documentation on Dev Studio
The credentials you'll need
| Identifier | Description |
|---|---|
| Internet Pseudo City Code (iPCC) or Pseudo City Code (PCC) | A PCC/iPCC is an alphanumeric identifier used to identify a travel agency of a Global Distribution System (GDS), such as Sabre. These control which functions your travel agency can perform in the Sabre system. |
|
Employee Profile Record (EPR) |
An EPR is an individual profile of an employee within your travel agency. Your EPR controls which functions you (an employee of a travel agency) can perform in the Sabre GDS. Each EPR is linked to a PCC/iPCC. |
| ClientId and ClientSecret |
(Optional) Credentials used to identify a specific application used by our customers. This is a unique signature generated by Sabre for internal or external customer applications consuming Sabre APIs. Contact your account manager to acquire these credentials. |
No Sabre credentials?
If you want to take some of our REST APIs for a spin, sign up for a Dev Studio account and try them out on any one of our REST API pages. This lets you take a subset of our REST APIs for a spin in the certification (a.k.a. test) environment.
Note: Please be aware that some of our REST APIs might require you to have a Sabre provisioned account.
If you want to take our SOAP APIs for a spin, contact us. We can put you in touch with a Sabre account manager and the credentials to test a subset of our APIs.
Step 2: Construct your token credentials
Your token credentials are your signature for Sabre APIs.
Get your token credentials
You should receive your token credentials via email after your Sabre API order is created by your Sabre account manager. Here are the token credentials you'll receive:
| Domain |
|
| Password |
|
Determine the token type
1. View our list of APIs in the Product Catalog.
2. Find the respective API using the in-page filters.
3. On the documentation page, look under Authentication in the API Information box.
Notes:
- Sessionless means the API needs a sessionless token.
- Session means the API needs a session token.
- Some APIs accept both token types.
No token credentials?
- Register for a new account on Dev Studio to get free Sabre credentials, in case you are not a current customer.
Note: Prospective customers can use these credentials to get a token, and call a subset of our REST APIs. - Sign-in to Dev Studio to get your credentials, click My Account in the My Applications tab and then use your User ID and User Password to create your single base64-encoded string. Test credentials allow you the necessary access to test within the Sabre environment using the OAuth Token Create REST API.
- Click the Reference tab on the API page to start live-calling our APIs.
You can also refer to the steps in REST API Token Credentials guide, then follow the instructions below.
Step 3: Get a token
Your security token gets you connected to Sabre APIs.
Prerequisites
- You must know the type of token supported by the API, and have received your Sabre credentials and constructed your token credentials.
- You must also know the environment you want to call.
Introduction
Sabre APIs support two authentication mechanisms: session-less tokens and session tokens. These security tokens are mapped to your Sabre credentials, which determine your authorization to call your agency's subset of Sabre APIs.
Note: To call Sabre APIs in the certification environment, you must obtain a token from the certification environment (and vice versa for the production environment).
REST API sessionless authentication
Get a sessionless token to call a given REST API.
Step 1: Format your credentials
REST API customers must first construct a single base64-encoded string.
Depending on the Create Access Token API you decide to use, versions use one of two recommended options to construct your REST API sessionless token credentials in REST API Token Credentials.
Step 2: Call the method/endpoint
| API | Differences |
|---|---|
| Create Access Token v2 |
|
| Create Access Token v3 |
|
Below is an example of a session-less token v2 request body:
POST https://api.platform.sabre.com/v2/auth/token HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36 Origin: chrome-extension://hgmloofddffdnphfgcellkdfbfbjeloo Authorization: Basic VmpFNmRYTmxjbWxrT21keWIzVndPbVJ2YldGcGJnPT06TVRJek5EVT0= Content-Type: application/x-www-form-urlencoded Accept: */* Content-Length: 29 grant_type=client_credentials
Step 3: Get the token from the response
VALID
If the request is valid, the body contains the token, token type, and token expiration:
{access_token: "T1RLAQLGvbv8bgEDtkUluJb1dBDQ1WJTfBB0OC9XwItgref4u2AKisF4AACQbcNl4UPCzFwNMMXq8VKPTNgXra2nTzlC6Ys45kuwac6d7noUiUb1X+v7rRO5XcNiSUxyie/gPYlPsoZHOWjaQ1pUjDQHJuBZAJ0swMAm2oDiER5HRgCac57GommwHaQNqzTlr4mUgbY6PwQNllIeluAOtKi+42yP+4h7oaWrN/ibm5OWae7dNxDrcwZquGDM", token_type: "bearer", expires_in: 604800}
NOT VALID
If the request is not valid, the server returns the following error message:
{error : "invalid_client", error_description: "Credentials are missing or the syntax is not correct"}
UNAUTHORIZED
If the request is unauthorized, the server returns the following error message:
{"error":"invalid_client","error_description":"Wrong clientID or clientSecret"}
Step 3: Use the token in the request to call a given REST API
Send the sessionless token to the environment and API endpoint in the header when you call a given REST API.
| Field | Description |
|---|---|
| access_token |
|
| token_type |
|
| expires_in |
|
| Field | Description |
|---|---|
| URL |
|
| Authorization |
|
An example request to the Travel Theme Lookup API is shown below:
GET https://api.platform.sabre.com/v1/lists/supported/shop/themes HTTP 1.1 Authorization: Bearer T1RLAQLGvbv8bgEDtkUluJb1dBDQ1WJTfBB0OC9XwItgref4u2AKisF4AACQbcNl4UPCzFwNMMXq8VKPTNgXra2nTzlC6Ys46kuwac6d7noUiUb1X+v7rRO5XcNiSUxyie/gPYlPsoZHOWjaQ1pUjDQHJuCZAJ0swMAm2oDiER5HRgCac57GommwHaQNqzTlr4mUgbY6PwQNllIeluAOtKi+42yP+4h7oaWrN/ibm5OWae7dNxDrcwZquGDM
Step 4: Test before you build
Use a client such as Postman to begin sending requests - but first verify you have the appropriate access to your agency's subset of Sabre APIs before you start building.
Notes:
- Refer to REST API Postman Requests for more on Postman.
- A sessionless token obtained via REST APIs can also be used to call SOAP APIs (and vice versa).
SOAP API sessionless authentication
Get a sessionless token to call a given SOAP API.
Step 1: Format your credentials
You must format the request with your token credentials in the security node of the request header.
Version 1.0.0:
<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/12/utility"> <wsse:UsernameToken> <wsse:Username>YOUR EPR</wsse:Username> <wsse:Password>YOUR PASSWORD</wsse:Password> <Organization>YOUR PCC</Organization> <Domain>YOUR DOMAIN</Domain> </wsse:UsernameToken> </wsse:Security>
Version 2.0.0:
If you have a ClientId and ClientSecret, add:
... <ClientId>YOUR CLIENT ID</ClientId> <ClientSecret>YOUR CLIENT SECRET</ClientSecret> ...
If you do not have ClientId and ClientSecret credentials, contact your account manager or use version 1.0.0 instead.
Step 2: Call the Service Action Code
Call the Create Access Token API with your token credentials to get a sessionless token.
Notes:
- The steps below include required parameters only.
- Refer to the Create Access Token API for more information on optional parameters and versions.
| Field | Description |
|---|---|
| eb:Action |
|
| - | See also: |
An example of a sessionless token version 1.0.0 request is shown below:
<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:eb="http://www.ebxml.org/namespaces/messageHeader" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Header> <eb:MessageHeader SOAP-ENV:mustUnderstand="1" eb:version="1.0"> <eb:ConversationId>YOUR CONVERSATION ID</eb:ConversationId> <eb:From> <eb:PartyId type="urn:x12.org:IO5:01">999999</eb:PartyId> </eb:From> <eb:To> <eb:PartyId type="urn:x12.org:IO5:01">123123</eb:PartyId> </eb:To> <eb:CPAId>IPCC</eb:CPAId> <eb:Service eb:type="OTA">TokenCreateRQ</eb:Service> <eb:Action>TokenCreateRQ</eb:Action> <eb:MessageData> <eb:MessageId>1000</eb:MessageId> <eb:Timestamp>2001-02-15T11:15:12Z</eb:Timestamp> <eb:TimeToLive>2001-02-15T11:15:12Z</eb:TimeToLive> </eb:MessageData> </eb:MessageHeader> <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"> <wsse:UsernameToken> <wsse:Username>USERNAME</wsse:Username> <wsse:Password>PASSWORD</wsse:Password> <Organization>IPCC</Organization> <Domain>DEFAULT</Domain> </wsse:UsernameToken> </wsse:Security> </SOAP-ENV:Header> <SOAP-ENV:Body> <sws:TokenCreateRQ xmlns:sws="http://webservices.sabre.com" Version="1.0.0"/> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Step 3: Get the token from the response
If the request is valid, the API will return a sessionless token.
| Field | Description |
|---|---|
| wsse:BinarySecurityToken |
|
| eb:ConversationId |
|
An example of a sessionless token response is shown below:
<?xml version="1.0" encoding="UTF-8"?>
<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Header>
<eb:MessageHeader xmlns:eb="http://www.ebxml.org/namespaces/messageHeader" eb:version="1.0" soap-env:mustUnderstand="1">
<eb:From>
<eb:PartyId eb:type="URI">123123</eb:PartyId>
</eb:From>
<eb:To>
<eb:PartyId eb:type="URI">999999</eb:PartyId>
</eb:To>
<eb:CPAId>IPCC</eb:CPAId>
<eb:ConversationId>YourConversationId</eb:ConversationId>
<eb:Service eb:type="sabreXML">TokenCreateRS</eb:Service>
<eb:Action>TokenCreateRS</eb:Action>
<eb:MessageData>
<eb:MessageId>be5031b4-f539-47e0-8a34-8db0e7b8c7bb@19</eb:MessageId>
<eb:Timestamp>2015-09-30T15:22:20</eb:Timestamp>
<eb:RefToMessageId>1000</eb:RefToMessageId>
</eb:MessageData>
</eb:MessageHeader>
<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
<wsse:BinarySecurityToken valueType="String" EncodingType="wsse:Base64Binary">T1RLAQKvhOegyUujiZpE+uDAjHHmRfRmxRDDuJCPlszyUSmyhKGXWR0JAACgeveXEFWUPWzsmw9+Ihd9BSDYEtpikXHi8yJ9iW7vXgJpDNqnktLD4W8P7UP3zdra5szeuNXQB3yNbkjcK+3Vl1Gr/f8g00qU8ZhtzIBVz/PoD48GuaxNH7/Uq7ZztI1bXu7ve9NEW6tVsp6qxbt9Jatn/B5IXf2t+T7S2l5QJU46kNg3r1H0ndhCp/pDwVT3FIo8sVSnWNZbIvUhrH6gQg**</wsse:BinarySecurityToken>
</wsse:Security>
</soap-env:Header>
<soap-env:Body>
<eb:Manifest xmlns:eb="http://www.ebxml.org/namespaces/messageHeader" eb:id="Manifest" eb:version="1.0">
<eb:Reference eb:id="TokenCreateRS" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="cid:TokenCreateRS">
<eb:Description xml:lang="en-US">Token Create Response Message</eb:Description>
</eb:Reference>
</eb:Manifest>
</soap-env:Body>
</soap-env:Envelope>
Store the session token in <eb:BinarySecurityToken> for step 3.
Step 4: Use the token in the request to call a given SOAP API
Include the sessionless token in the header when you call a given SOAP API.
| Field | Description |
|---|---|
| wsse:BinarySecurityToken |
|
| eb:Action |
|
Part of an example of a subsequent request to the Bargain Finder Max API is shown below:
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<eb:MessageHeader xmlns:eb="http://www.ebxml.org/namespaces/messageHeader" SOAP-ENV:mustUnderstand="0">
<eb:From>
<eb:PartyId eb:type="urn:x12.org:IO5:01">from</eb:PartyId>
</eb:From>
<eb:To>
<eb:PartyId eb:type="urn:x12.org:IO5:01">ws</eb:PartyId>
</eb:To>
<eb:CPAId>YOURPCC</eb:CPAId>
<eb:ConversationId>YourConversationId</eb:ConversationId>
<eb:Service eb:type="sabreXML"></eb:Service>
<eb:Action>BargainFinderMaxRQ</eb:Action>
</eb:MessageData>
</eb:MessageHeader>
<eb:Security xmlns:eb="http://schemas.xmlsoap.org/ws/2002/12/secext" SOAP-ENV:mustUnderstand="0">
<eb:BinarySecurityToken> T1RLAQKvhOegyUujiZpE+uDAjHHmRfRmxRDDuJCPlszyUSmyhKGXWR0JAACgeveXEFWUPWzsmw9+Ihd9BSDYEtpikXHi8yJ9iW7vXgJpDNqnktLD4W8P7UP3zdra5szeuNXQB3yNbkjcK+3Vl1Gr/f8g00qU8ZhtzIBVz/PoD48GuaxNH7/Uq7ZztI1bXu7ve9NEW6tVsp6qxbt9Jatn/B5IXf2t+T7S2l5QJU46kNg3r1H0ndhCp/pDwVT3FIo8sVSnWNZbIvUhrH6gQg**</eb:BinarySecurityToken>
</eb:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<eb:OTA_AirLowFareSearchRQ...
...
...
[NOTE: see Bargain Finder Max API
documentation for a sample request.]
...
...
</eb:OTA_AirLowFareSearchRQ>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Step 4: Test before you build
Use a client such as SoapUI and our plug-and-play project file on GitHub to get a session token and call the Bargain Finder Max API.
Note: Access to Bargain Finder Max is required.
SOAP API session authentication
Get a session token to call a given SOAP API.
Step 1: Format your credentials
You must format the request with your token credentials in the security node of the request header.
Version 1.0.0:
<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/12/utility"> <wsse:UsernameToken> <wsse:Username>YOUR EPR</wsse:Username> <wsse:Password>YOUR PASSWORD</wsse:Password> <Organization>YOUR PCC</Organization> <Domain>YOUR DOMAIN</Domain> </wsse:UsernameToken> </wsse:Security>
Version 2.0.0:
If you have a ClientId and ClientSecret, add:
... <ClientId>YOUR CLIENT ID</ClientId> <ClientSecret>YOUR CLIENT SECRET</ClientSecret> ...
If you do not have a ClientId and ClientSecret, contact your account manager or use version 1.0.0 instead.
Step 2: Call the Service Action Code
Call the Create Session API with your token credentials to get a session token.
Notes:
- The below steps include required parameters only.
- Refer to the other session APIs under the Session Management Category in the Product Catalog.
| Field | Description |
|---|---|
| eb:Action |
|
| See also: |
An example of a session token request is shown below:
<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:eb="http://www.ebxml.org/namespaces/messageHeader" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Header> <eb:MessageHeader SOAP-ENV:mustUnderstand="1" eb:version="1.0"> <eb:ConversationId>YOUR CONVERSATION ID</eb:ConversationId> <eb:From> <eb:PartyId type="urn:x12.org:IO5:01">999999</eb:PartyId> </eb:From> <eb:To> <eb:PartyId type="urn:x12.org:IO5:01">123123</eb:PartyId> </eb:To> <eb:CPAId>IPCC</eb:CPAId> <eb:Service eb:type="OTA">SessionCreateRQ</eb:Service> <eb:Action>SessionCreateRQ</eb:Action> <eb:MessageData> <eb:MessageId>1000</eb:MessageId> <eb:Timestamp>2001-02-15T11:15:12Z</eb:Timestamp> <eb:TimeToLive>2001-02-15T11:15:12Z</eb:TimeToLive> </eb:MessageData> </eb:MessageHeader> <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"> <wsse:UsernameToken> <wsse:Username>USERNAME</wsse:Username> <wsse:Password>PASSWORD</wsse:Password> <Organization>IPCC</Organization> <Domain>DEFAULT</Domain> </wsse:UsernameToken> </wsse:Security> </SOAP-ENV:Header> <SOAP-ENV:Body> <sws:SessionCreateRQ xmlns:sws="http://webservices.sabre.com" Version="1.0.0"/> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Step 3: Get the token from the response
The API will return a session token (and conversation ID, if applicable) if the request is valid.
| Field | Description |
|---|---|
| wsse:BinarySecurityToken |
|
| eb:ConversationId |
|
VALID
An example of a session token response is shown below:
<?xml version="1.0" encoding="UTF-8"?>
<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Header>
<eb:MessageHeader xmlns:eb="http://www.ebxml.org/namespaces/messageHeader" eb:version="1.0" soap-env:mustUnderstand="1">
<eb:From>
<eb:PartyId eb:type="URI">123123</eb:PartyId>
</eb:From>
<eb:To>
<eb:PartyId eb:type="URI">999999</eb:PartyId>
</eb:To>
<eb:CPAId>IPCC</eb:CPAId>
<eb:ConversationId>YourConversationId</eb:ConversationId>
<eb:Service eb:type="sabreXML">SessionCreateRS</eb:Service>
<eb:Action>SessionCreateRS</eb:Action>
<eb:MessageData>
<eb:MessageId>be5031b4-f539-47e0-8a34-8db0e7b8c7bb@19</eb:MessageId>
<eb:Timestamp>2015-09-30T15:22:20</eb:Timestamp>
<eb:RefToMessageId>1000</eb:RefToMessageId>
</eb:MessageData>
</eb:MessageHeader>
<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
<wsse:BinarySecurityToken valueType="String" EncodingType="wsse:Base64Binary">Shared/IDL:IceSess\/SessMgr:1\.0.IDL/Common/!ICESMS\/RESH!ICESMSLB\/RES.LB!-3485631637434281295!472007!0</wsse:BinarySecurityToken>
</wsse:Security>
</soap-env:Header>
<soap-env:Body>
<eb:Manifest xmlns:eb="http://www.ebxml.org/namespaces/messageHeader" eb:id="Manifest" eb:version="1.0">
<eb:Reference eb:id="SessionCreateRS" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="cid:SessionCreateRS">
<eb:Description xml:lang="en-US">Session Create Response Message</eb:Description>
</eb:Reference>
</eb:Manifest>
</soap-env:Body>
</soap-env:Envelope>
Store the session token in <eb:BinarySecurityToken> for step 3.
NOT VALID
If the request is not valid, the server returns the following error message:
<soap-env:Body>
<soap-env:Fault>
<faultcode>soap-env:Client.InvalidSecurityToken</faultcode>
<faultstring>Invalid or Expired binary security token: Shared/IDL:IceSess\/SessMgr:1\.0.IDL/Common/!ICESMS\/RESB!ICESMSLB\/RES.LB!-4766997140656846583!105529!0</faultstring>
<detail>
<StackTrace>com.sabre.universalservices.base.session.SessionException: errors.session.USG_INVALID_SECURITY_TOKEN</StackTrace>
</detail>
</soap-env:Fault>
</soap-env:Body>
Step 4: Use the token in the request to call a given SOAP API
Use the session token in <eb:BinarySecurityToken> from the SessionCreateRS response (above).
| Field | Description |
|---|---|
| wsse:BinarySecurityToken | The session token obtained in step 2. |
An example of a request (with token credentials in the header) to the Hotel Availability API (OTA_HotelAvailRQ) is shown below:
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<eb:MessageHeader xmlns:eb="http://www.ebxml.org/namespaces/messageHeader" SOAP-ENV:mustUnderstand="0">
<eb:From>
<eb:PartyId eb:type="urn:x12.org:IO5:01">from</eb:PartyId>
</eb:From>
<eb:To>
<eb:PartyId eb:type="urn:x12.org:IO5:01">ws</eb:PartyId>
</eb:To>
<eb:CPAId>YOURPCC</eb:CPAId>
<eb:ConversationId>YourConversationId</eb:ConversationId>
<eb:Service eb:type="sabreXML"></eb:Service>
<eb:Action>OTA_HotelAvailLLSRQ</eb:Action>
</eb:MessageHeader> <eb:Security xmlns:eb="http://schemas.xmlsoap.org/ws/2002/12/secext" SOAP-ENV:mustUnderstand="0">
<eb:BinarySecurityToken>Shared/IDL:IceSess\/SessMgr:1\.0.IDL/Common/!ICESMS\/CERTG!ICESMSLB\/CRT.LB!-3488060046525942493!102430!0</eb:BinarySecurityToken>
</eb:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<eb:OTA_HotelAvailRQ xmlns:eb="http://webservices.sabre.com/sabreXML/2003/07" TimeStamp="2011-01-26T12:30:00-06:00" Version="1.10.1">
<eb:POS>
<eb:Source PseudoCityCode="YOURPCC" /></eb:POS>
<eb:AvailRequestSegments>
<eb:AvailRequestSegment>
<eb:StayDateRange Start="11-10" End="11-15" />
<eb:RoomStayCandidates>
<eb:RoomStayCandidate>
<eb:GuestCounts>
<eb:GuestCount Count="1" /></eb:GuestCounts>
</eb:RoomStayCandidate>
</eb:RoomStayCandidates>
<eb:HotelSearchCriteria xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="eb:HotelSearchCriteria_type0">
<eb:Criterion>
<eb:HotelRef HotelCityCode="DFW" /></eb:Criterion>
</eb:HotelSearchCriteria>
</eb:AvailRequestSegment>
</eb:AvailRequestSegments>
</eb:OTA_HotelAvailRQ>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Step 4: Test before you build
Use a client such as SoapUI and our plug-and-play project file on GitHub to get a session token and call the Bargain Finder Max API.
Note: Access to Bargain Finder Max is required.
Step 5: Terminate the session token/session
Call the Close Session API to render the session token invalid and release the allocated session token/session resources back to you. Include the values for eb:ConversationId, eb:CPAId, and wsse:BinarySecurityToken.
Important! If you do not make use of the Close Session API, you risk running out of session tokens/session resources.
An example request is shown below:
<SOAP-ENV:Header>
<eb:MessageHeader xmlns:eb=" http://www.ebxml.org/namespaces/messageHeader " eb:version="1.0 " soap-env:mustUnderstand="1 ">
<eb:From>
<eb:PartyId eb:type="URI ">123123</eb:PartyId>
</eb:From>
<eb:To>
<eb:PartyId eb:type="URI ">999999</eb:PartyId>
</eb:To>
<eb:CPAId>IPCC</eb:CPAId>
<eb:ConversationId>YourConversationId</eb:ConversationId>
<eb:Service eb:type="sabreXML ">SessionCloseRQ</eb:Service>
<eb:Action>SessionCloseRQ</eb:Action>
<eb:MessageData>
<eb:MessageId>ba8a19cc-7fdc-443c-bc97-b86100b4c332@33</eb:MessageId>
<eb:RefToMessageId>1000</eb:RefToMessageId>
<eb:Timestamp>2005-10-31T21:13:02</eb:Timestamp>
</eb:MessageData>
</eb:MessageHeader>
<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext ">
<wsse:BinarySecurityToken valueType="String " EncodingType="wsse:Base64Binary "> Shared/IDL:IceSess\/SessMgr:1\.0.IDL/Common/!ICESMS\/RESB!ICESMSLB\/RES.LB!-4766997140656846583!105529!0
</wsse:BinarySecurityToken>
</wsse:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<eb:SessionCloseRQ xmlns:eb="http://webservices.sabre.com/sabreXML/2003/07 " TimeStamp="2011-01-26T12:30:00-06:00 " Version="1.0.1 ">
<eb:POS>
<eb:Source PseudoCityCode="IPCC " />
</eb:POS>
</eb:SessionCloseRQ>
</SOAP-ENV:Body>
What's next?
Refer to our How to Manage a Token guide.
Related
- Know your environment. Get the endpoints and learn which environments to use in Environments.
- Code to common errors. When things go wrong, you'll need to code to the error response in Errors.
- Optimize your workflows. Learn about our recommended best practices in Optimize Workflows.