Migrate your integration
Use the following diagrams to help you understand and construct the main migration requirements for your particular integration.
Overview
Each diagram provides a high-level picture of the basic integration types for our Demand API. For each type, the diagram shows:
- the V2 endpoints that are used,
- the equivalent endpoints that you will need to use in V3.
Each diagram shows the primary endpoint mappings between V2 and V3 - for example, /hotelAvailability
maps to /accommodations/search
.
The design of V2 and V3 endpoints is significantly different. Consequently:
- You should not assume a one-to-one mapping of either input parameters or output fields between the V2 endpoint and the equivalent V3 endpoint.
- You may need to use mapped fields in V3 differently to the equivalent V2 parameters or fields.
- You may also need to call other V3 endpoints.
For more information, see Migrate individual V2 endpoints.
Search and redirect-to-book
Search, look and redirect-to-book
Search, look and book
Get static content
Caching static content can reduce endpoint traffic and improve response times.
Most V2 endpoints that return static data map one-to-one to their equivalent V3 endpoints. However, note that:
- The different V2
*Types
endpoints all map to a single V3 endpoint,/accommodations/constants
. - There are three new V3 endpoints.
Look up static codes and ids
If you do not cache some or all of the data from the static endpoints shown above, you will need to call those endpoints whenever that data is needed by other endpoints, either:
- to obtain codes or ids needed in request parameters
- to process codes or ids returned in response fields
For example, the following diagram shows the additional calls that you may need to make to use /accommodations/search
, if you do not already have the necessary information in your cache.