Expanded global inventory overview

Compete on a global scale with expanded inventories around the world

The Expedia expanded global inventory (EGI) helps you compete with upwards of 34,000 properties globally, with more inventory being added on a regular basis. This includes newly sourced properties and additional inventory at currently sourced properties.

Technical details

EGI is not part of the standard inventory in Rapid API, but it can be explicitly enabled upon request. It features dynamic behaviors and integration patterns that differ from the standard inventory, requiring special attention across content ingestion, shopping, and booking workflows.

Content files

The Rapid Content File and Catalog File APIs for EGI currently support English-language content only. If your system requires localized (non-English) content files, you can generate them locally using the Property Content and Geography APIs. These APIs offer real-time streaming and flexible data handling for all content languages, making it easy to extract the necessary information from the JSON-formatted API responses. You can store the raw JSON response locally for later processing or transform it for database import or other use cases.

Example of requesting a properties list for a region using the Geography API:

/regions?country_code=US&language= it-IT&include=property_ids_expanded&include=property_ids

Example of requesting catalog content using the Property Content API:

/properties/content?language=it-IT&supply_source=expedia&property_id={property_id}&include=catalog

You can choose to prioritize the launch of Content integration for EGI while also allocating additional time to review the Shopping and Booking workflows, or you can launch all three components together when you feel prepared for EGI. For configuration details, please contact your integration consultant.

Room data alignment

New property rooms may surface in the Shopping API before your system is fully synchronized with the Property Content API. To maintain a consistent user experience, consider either temporarily excluding these rooms from customer display, triggering a real-time Content API call for the new room, or increasing the frequency of your local content updates to minimize data lag.

Rate identifier

EGI rates are structured differently from the standard inventory and adhere to a more dynamic data model. Because there is no static value for these rates, the Shopping API returns them with a dynamic rate_id value that doesn’t correspond to the values in the Property Content API. This dynamic string value consists of digits, letters, and various other symbols, which may differ in each Shopping API response. Because of this, the rate_id value is unstable and should not be used as a persistent identifier or primary key. If your system needs to distinguish rates across processes, consider matching them with a combination of policy attributes and offer characteristics. Refer to this secured document for more details.

Example of the rate_id value in a Shopping API response:

[
  {
    "property_id": "ABC152",
    "status": "available",
    "rooms": [
      {
        "id": "XYZ652",
        "room_name": " Deluxe Double ",
        "rates": [
          {
            "id": "5K|Pa7xbx4z||GCogh8-B96OEY3-f9326e292|UFO",
            … …

Bed configuration variability

In exceptional circumstances, certain rooms may not have designated bed configurations, indicated in both Content and Shopping APIs through a bed_groups ID of 0 and the description “Bed Not Specified.” This implies that the property will determine the bed arrangement upon check-in. While this occurrence is rare, your system should keep the customer informed and, if they have strong preferences, assist them in communicating special requests to our customer operations team.

Example of the unspecified bed configuration in a Shopping API response:

{
  "bed_groups": {
    "0": {
      "id": "0",
      "description": "Bed Not Specified",
      "links": {
        "price_check": {
          … …

Hold and Resume

Some EGI rates are incompatible with the Booking API Hold and Resume workflow and will return errors if a hold attempt is made. To prevent poor customer experiences, you can request the holdable rate flag in the Shopping API response and follow it to apply the correct workflow.

Example of requesting holdable rate flag:

Request:
/properties/availability?... …&include=rooms.rates.holdable

Response:
… …
"rooms": [
  {
    "id": "XYZ652",
    "room_name": "Deluxe Double Room",
    "rates": [
      {
        "id": "5K|Pa7xbx4z||GCogh8-B96OEY3-f9326e292|UFO",
        “holdable”: true,
        … …

Post-booking features

Upon confirmation of a reservation through the Booking API, the booking will be delivered in the Manage Booking APIs. The token links for accessing post-booking features, including Soft Change, Hard Change, and Property Message Center, will also be available in the Manage Booking APIs. Occasionally, the token links may take up to five minutes to be ready. It is important to note that these features are not available for all bookings and should be gracefully managed within your system.

Key differences in EGI