For each service, there are two WSDL files:
- The abstract file (e.g.,
AirAbstract.wsdl), imported by the non-abstract file (e.g., Air.wsdl), describes the messages and port types.
- The non-abstract version describes the binding and the service.
Each schema file contains
requests for a specific service, some shared objects, and the
AirReqRsp.xsdcontains all the requests necessary to search for flights, and create and ticket a reservation.
UniversalRecordReqRsp.xsdcontains requests to work with Universal Records (URs) that have been created or ticketed.
Whenever possible, schema and processing have been normalized in
Using the schema files, most programming languages can create proxy classes that allow easy creation of requests and parsing of responses. These proxy classes typically also handle the SOAP protocol for you, as long as you provide credentials and the correct endpoint.
While the transactions might appear “heavier” than a similar transaction using JSON, the use of GZIP compression ensures the actual data transmitted is small. Responses are compressed automatically by the Universal API server when you set the header Accept-Encoding to gzip.
The Programming Model
The documentation for
System.wsdl start with
System and end with
PortTypewhen they are generated from this WSDL.
Every request that is sent must also contain your credentials in the HTTP Header. These are the credentials Travelport provided when you signed up to use
It is good practice to turn on “full validation” when developing your application, no matter the programming language you are using. This means that your system will not attempt to transmit XML sequences that are invalid, and thus likely to be rejected.
Generating Client-Side Code
Almost any programming language can be used to work with
Note: Different generators have slightly different behaviors.
It is recommended that you generate the client-side code for the services you plan to use. Air, Hotel, and Vehicle services are the most commonly used and are often used in conjunction with each other.
Versioning and Backwards Compatibility
Each service (Universal Record, Air, Vehicle, Hotel, Common, etc.) is managed separately for each release. Versions are identified by major/minor/patch in the namespace of the service definition (WSDL).
- Major versions are incremented due to architectural changes.
- Minor changes are incremented due to service enhancements.
- Patch changes occurs after a service is delivered.
A file of the differences between one version and the next can be downloaded on the Downloading WSDLs and Schemas page.
If elements or attributes in a new version are supported in prior versions, the Developer Advisory and the online help will note the backwards compatibility.
Design and Use
The following factors were considered when designing
When designing the schema, we chose to promote reusability
of elements rather then creating multiple versions. So, in different contexts,
many elements will have different required attributes and/or child elements.
As a result, the definition must be loose enough (not required) to handle
all scenarios. For example,
Due to the shared element concept used in search responses,
many elements have a companion Ref element. For example,
We also made the assumption, and try to encourage, that
client applications would retain and pass back the original
Given the above decisions and assumptions, it is apparent
that it is not always desirable or feasible to retain complex
This design approach is put into practice when it is feasible to accommodate the minimum requirements of a transaction. In actual use, this approach is sometimes modified when the complexity of the data requires more details.
For example, an