This topic introduces you to the Availability and Rates integration, which enables you to send availability, rates, and restrictions updates to Expedia Group. Availability and Rates (AR) uses synchronous connection - both the request (RQ) and response (RS) are sent within the same transaction cycle.
If you are looking for information about capabilities offered by additional APIs, such as Product API, refer to the overview page.
These define the standard and format for automatic room type and rate plan updates. The list of minor changes are included in the revision history. Versioning of the XML schema is indicated in the namespace of the messages.
Integration project timeline
- All XML files must be well-formed, adhere to the schema (XSD), and be encoded in UTF-8.
- TLS 1.2 is required.
- Be secured using basic authentication.
Steps to enable online availability and rates updates
- The partner submits a form to advise Expedia Group that you would like to adopt the Availability and Rates API (please note that you will also need to adopt a booking API together with Availability and Rates API, such as Booking Retrieval and Booking Confirmation APIs or the Booking Notification API.)
- An Expedia Group Technical Relationship Manager contacts the partner to set priorities and determine partner needs.
- The Integration team and Expedia Group Connectivity Manager schedules a kick-off call, where partners meet their Integration Specialist and review desired settings and address API questions, issues, and expectations.
- The partner develops Availability and Rates API for updating and managing online rates and availability.
- The partner encodes Availability and Rates API responses in UTF-8.
- The partner ensures the Availability and Rates service sends updates to online inventory and rates on Expedia Group points of sale for a test property.
- The partner ensures development of a booking API (either Booking Notification or Booking Retrieval/Booking Confirmation pair of APIs) has been completed as well
- The partner provides one beta property in the production environment to the Integration team that can be used for testing.
- The partner works with the Integration team to test and validate use cases.
When you are ready to test, contact the Expedia Group Integration Specialist assigned to your account for access to the guides and testing tools.
Testing for this API consists of self-tests conducted using test properties in a live production environment. When you have tested as much as possible with the test property, contact your Integration Specialist to begin a soft launch.
At this point, you will be able to complete live testing on a real property. You will monitor the live property for seven days and will report any errors or warnings you receive to your Integration Specialist. You and your Integration Specialist will ensure all reservations have been received and confirmed.
When you confirm that all availability and rate updates have been made successfully and have acknowledged and resolved any errors associated with availability and rate updates, the Integration Specialist will email you to let you know the soft launch has been successfully completed. More details are provided in the Development requirements.
- You must continue to adhere to our License Agreement
- You should monitor your Availability and Rates connection for any warning or errors
- Report any warning or errors received in any AR response and how they have been resolved
This section provides an overview of the Availability and Rates API schema, which defines the structure of the XML files that you must provide to update rates and availability on Expedia Group points of sale.
- Property IDs (each property’s unique Expedia Group identifier)
- Groupings of updates for one or more room type(s) and rate plan(s) or a list of date ranges.
- Specific days of the week. See Using day of the week attributes for more details and cautions when using this feature.
- Room type IDs
- Rate plan IDs
- Room type inventory being made available for sale on Expedia Group
- Success messaging: indicates that no errors occurred, but warnings can also be returned with success messages.
- Warning messaging: means the update request was only partially applied.For more information, see the section about warning codes.
- Error messaging: appears when nothing included in the Availability and Rates request could be processed. See the Error handling and Testing and Troubleshooting sections for more details.