Base Request and Response

All requests and responses are based on the BaseReq and BaseRsp structures. (The only exception is the PingReq.) The base request and response are in the Common service, which supports most Universal API transactions.

The base request requires one element: BillingPointOfSale. The base response includes the TransactionId. The TransactionId is used to identify unique transactions for problem solving and error reporting. When reporting errors, always identify the TransactionId that was returned.

Request

The Base Request has a number of optional attributes and one required element.

  1. Enter the required BillingPointOfSale to identify the billable source of the request. At provisioning:
    • Non-Travelport subscribers are assigned a CIDB Number (Customer Information Data Base) to identify transactions that flow through Universal API to its providers.
    • Some Travelport subscribers are assigned a unique OriginApplication during the Certification process for Pre-Production and Production. The Origin Application identifies the client application in the request.
    • All other subscribers can use "UAPI" for the OriginApplication value.

  2. Enter your TargetBranch.

    The Target Branch is used to identify the Pseudo City or SID and related provisioning data where the transaction will be executed.

    Both Target branch and Override PCC can be used in a single request.

    Note: The TargetBranch is 'optional' in the schema, but required for the base request.

  3. Enter optional data.

    Attribute/Element Description

    TraceId

    Used by the client system to identify a request. A Trace ID is highly recommended in all requests. This field is mainly used for client tracking or user tracking. If sent in the request, it is returned in the response.

    Uses:

    • Client Tracking

      If reporting a problem to Universal API, the TraceId can be used to uniquely identify a particular request.

    • User Tracking

      If a single request on the client application initiates several requests on the Universal API system, this ID can be used to group these multiple Universal API requests together to track the order and timing of the requests.

    A unique TraceID can be used to track all transactions within a workflow.

    • When beginning a new workflow, which is typically with LowFareSearch (Shop), generate a new unique TraceID and pass it appropriately with all follow-on requests until the workflow is complete. For example, AirCreate, AirTicket, etc.
    • It should always be the same TraceID within a complete workflow.

    The TraceID assists Universal API support in their investigation if a customer reports a query, as it enables the support team to look into a complete workflow.

    • Generally Universal API transactions are not linked.
    • By using the TraceID, Universal API customers and Travelport teams are able to log, identify, and extract transactions for investigation purposes, which greatly improves speed of response to any support tickets.
    • Not having the TraceID implemented causes unnecessary delay, and potentially no resolution, for a reported problem.

    Trace ID characteristics:

    • There is no limit to the length. The field is defined as unbounded.
    • The Trace ID can be just alpha characters or numeric characters or a mixture of both.

    TokenId

    Identifier used to maintain stateful (sessioned) transactions, which is returned in the LoginRsp.

    Note: Because all transactions between Universal API and external clients are stateless, the TokenID is currently for internal API use only.

    AuthorizedBy

    Indicates the user who initiated the transaction.

    Depending on the business process, the authorizer can be manually or programmatically populated. Required by some providers. If the client application does not specify an authorizer, and it is required by the provider, Universal API uses a default identifier to complete the transaction. 

    OverridePCC

    OverridePCC is used to emulate to another pseudo city, i.e., function as that agency, travel provider, or agency subdivision.

    OverridePCC emulation is available on Galileo, Apollo, and Worldspan.

    Note: OverridePCC emulation is not supported for ACH.

    Both Target branch and Override PCC can be used in a single request.

    LanguageCode

    Language Code (@LanguageCode) is currently supported only for Airline Content Hub (ACH) for Air requests and RCS for Rail requests. It allows the user to specify a language for a response if the language is supported by the provider or supplier system.

    AgentIDOverride

    Air Canada (AC) only. AgentID is part of the credentials required to access Air Canada content. It is assumed that agencies may not want to have all their agents share one set of credentials. Therefore, if a unique AgentID is required to be sent to Air Canada (possibly so that agencies can report on this information directly with AC), this ID can be sent in the Air Base requests.

Response

The Base Response is returned with the following information.

Attribute/Element Description

TraceId

Returns the TraceID submitted by the client in the request without alteration.

TransactionId

Identifier automatically generated by Universal API to uniquely identify a single request and response pair. In the event of an error or other need to look up a particular request, this identifies it for quick look-up.

ResponseTime

Identifies the amount of time spent in the Universal API system for processing the transaction. However, this time does not include the transmission time from the client system to Universal API, or the time needed to convert the request from XML or the response to XML.

CommandHistory

HTTP link to download the command history. Can be enabled by Travelport if debugging is needed.  

ResponseMessage

A container for any processing errors that occurred. ResponseMessage can be used to identify partial failures that occurred during the processing of a complex request. Generally these failures are known as Soft Errors. They usually indicate failures in sub-requests, such as SSRs or LoyaltyCards. They can also indicate that a preferred piece of data is missing, but did not cause the transaction to fail.

 

Review a Sample Request and Response

Understand Emulation