ReferenceAvailability and Rates API

Testing and troubleshooting

This section addresses the most common errors and technical difficulties that may be encountered when trying to connect to, or develop for Availability and Rates API.

The API defines several different categories of errors. Expedia Group recommends a robust retry strategy when resolving errors.

This overview provides an outline of the entire testing process. Each step may take some time and require several iterations of your code.

Further details about self-testing will be provided by your Integration Specialist. For a complete list of error codes and their descriptions, see Error messaging.

Connectivity errors

These errors are reported when communication disruption occurs between Expedia Group and your software.

Possible scenarios include the following.

Connection cannot be established

If the problem is:

  • Connection timeout (before establishing connection)
  • Cannot resolve host name
  • Cannot establish connection

Before looking for assistance, you should:

  1. Verify the URL used to connect to the API and make sure the address starts with https://
  2. Verify the domain name, and make sure that the address you are using is the right one for the environment you are targeting. Do not try to send QA information to production, or vice-versa.
  3. If your system is behind a firewall, make sure that port 443 is opened for connection to Expedia's production environment.
  4. Retry. If additional assistance is required, contact us.
Connection refused

You receive this error (code 3210) when the API’s servers cannot accept any more connections than the ones currently established to other partners.

When this happens, you should simply enter in retry mode.

SSL certificate validation problems

To avoid issues with certificate signing authorities, anyone developing in Java should use version 1.4.2_13 or newer.

If you prefer to use an older version of Java or an in-house SSL library, you will need to import the Entrust CA certificate.

Connection established, system errors returned

These errors (error codes 4000 through 4099) are automatically monitored by the Expedia Group API team, so there is no need to report them when they occur.

Connection Established, No Response

If your system establishes a connection to the API’s servers, but is not getting a response, you should

  • Make sure your system is not closing the connection too early. Some retrieval queries take longer than others. Expedia Group will keep connections active for up to 60 seconds. Therefore, your connections should stay open for at least 60 seconds as well.

  • Make sure the content length specified in the HTTPS header corresponds to the actual length of the HTTPS request. If the length specified in the header is longer than the message itself, the API waits for bytes that never arrive, and eventually times out.

Authentication errors

Errors related to authentication issues show error codes 1000-1003. If you receive an authentication error, stop sending retrieval requests until the issue is resolved and contact your administrator to verify your system configuration and contact Expedia Group.

Parsing and protocol errors

Parsing or protocol errors (codes 2002-3210) occur when there are issues with the XML formatting. If these errors occur, you should stop sending retrieval requests until the issue is resolved and contact your administrator to identify the problem.

To avoid these errors, first parse the XML retrieval request to ensure it validates against the API’s schema.

Response business errors

Once transactions have been submitted to Expedia Group’s system, you will receive an acknowledgement, either successful or negative.

Successful acknowledgements can contain warnings indicating part of the incoming request was not successfully processed and will include details about what failed. When warnings are returned, anything that is not specifically listed as a warning has been successfully processed.

Requests can contain multiple warnings. If too many warnings are generated, not all of them will be reported back to you in response. In this situation, the warning messages will clearly indicate that you should fix the problems with the request first before resubmitting to Expedia Group.

You should run a daily report to ensure your system is running smoothly. If the report finds business errors (codes 3015-3405), it should send an alert to your system. The message that fails due to a business error should be halted immediately (no retries) to allow other messages to go through.

Error 3107 - Update exceeds allowable size: Restricting the maximum number of updates per message

Expedia Group restricts the maximum number of updates allowed in a single message to 5000 updates. Requests containing more than 5000 updates will be rejected by the system and no updates will be applied. The error message returned will be: "3107: Update exceeds allowable size - Maximum allowable size is 5000 updates."

If this happens, you need to revise your implementation of the API interface to prevent it from sending messages containing more than 5000 updates. Different strategies can be used to reduce the number of updates per message, such as

  • Break down the updates by date range
  • Limit the number of products included per message

Expedia Group recommends designing a system that balances between the number of messages generated and number of updates included per message.

Note: Though the number of updates per message is limited to 5000, most messages will not approach that limit.

If you have questions, please contact your Expedia Group Connectivity Account Manager.

Warnings

Once an Availability and Rates request transaction has been submitted to Expedia Group, it can either receive a successful or negative acknowledgment. A successful acknowledgement may contain warnings (codes between 7000 and 8000), which are meant to indicate that part of the incoming request was not successfully processed, with details on what failed.

Warnings are problems with the request that were ignored in order to process the other valid updates in the request. They are equivalent to business errors, but do not make the whole request fail. When warnings are returned, anything that is not explicitly listed as a warning has been successfully processed.

A request can potentially contain dozens of warnings. If a request generated too many warnings, not all of them will be reported back to you in the response. When this happens, the warning messages will clearly indicate that you should fix the problems with the request first before resubmitting it to Expedia Group later.

You should take the exact same actions with warnings as you take with business errors. It is important to capture warnings and take corrective actions.