Use this guide to migrate your existing Demand API v3.1 car rental integration to v3.2. Review the endpoint, schema, field, and integration-flow changes that can affect your implementation.
Demand API v3.2 standardises car rental schemas and naming conventions and aligns the Cars API collection more closely with patterns used across other Demand API travel services.
The main migration changes include:
- Significant request and response changes to /cars/search.
- Naming and field changes in /cars/depots.
- Updated payment timing identifiers.
- Minor consistency improvements across existing Cars endpoints.
- Additional car rental booking and post-booking capabilities available in Beta.
Direct car rental booking and selected post-booking capabilities are currently available in Beta only. You do not need to implement these capabilities to migrate an existing Search, look and redirect integration from v3.1 to v3.2.
Use the following table to identify which existing endpoints require changes.
| Endpoint | Change | Migration action |
|---|---|---|
| /cars/search | Significant request and response schema changes. | Review and update your integration. See the /cars/search migration guide. |
| /cars/depots | Field naming and consistency updates. | Update renamed fields and remove dependencies on fields no longer returned. |
| /cars/depots/reviews/scores | No significant integration changes. | No migration action required. |
| /cars/suppliers | No significant integration changes. | No migration action required. |
| /cars/constants | Updated payment timing identifiers. | Review mappings or logic that depend on payment_timings.id. |
| /cars/details | No significant integration changes. | No migration action required. |
This table covers endpoints available to an existing v3.1 integration. New Beta endpoints and booking capabilities are described separately below.
v3.2 Changed Breaking change
/cars/search introduces the most significant schema changes between v3.1 and v3.2.
Depending on your integration, you may need to update:
- Request fields and structures.
- Response parsing.
- Pricing and policy structures.
- Route and location information.
- Offer and search-context handling.
- Other fields consumed by your application.
See the /cars/search migration guide for detailed v3.1-to-v3.2 mappings and examples.
/cars/depots remains functionally similar in v3.2, but some field names and structures have been standardised.
Review the following changes:
| v3.1 | v3.2 | Migration action |
|---|---|---|
pick_up | pickup | Update references to use pickup. |
drop_off | dropoff | Update references to use dropoff. |
deskAt | Removed | Remove dependencies on deskAt and use the relevant depot location information instead. |
Update any data models, response parsers, mappings, or downstream logic that depend on the v3.1 field names.
Demand API v3.2 standardises the Cars payment timing identifiers.
| v3.1 | v3.2 | Meaning |
|---|---|---|
part_pay | pay_partial_online_now | Traveller pays part of the amount online and the remaining amount later. |
pay_now | pay_online_now | Traveller pays the full amount online at the time of booking. |
pay_local | pay_at_pickup | Traveller pays at the pickup location. |
If your integration maps, stores, filters, or displays payment_timings.id values, update your logic to use the v3.2 identifiers.
Some Cars endpoints do not require significant integration changes when migrating from v3.1 to v3.2.
Use this endpoint to retrieve review scores and breakdowns for car rental depots.
No significant request or response changes require migration updates.
Use this endpoint to retrieve car rental supplier information.
No significant request or response changes require migration updates.
Use this endpoint to retrieve static vehicle information such as capacity, make, model, features, and specifications.
No significant request or response changes require migration updates.
Even where no migration action is required, validate the endpoints used by your integration against the v3.2 API reference before completing your migration.
/cars/constants has been expanded in v3.2 with additional constant groups and updated values.
Key changes include:
- New constant groups for car categories, customer services, depot types, extras, special offers, protection levels, and review scores.
- Updated payment timing identifiers.
- Additional fuel policy, fuel type, and general constant values.
If your integration stores or maps constants locally, refresh your mappings and ensure new values are handled without assuming a fixed closed set.
After migrating your existing v3.1 integration to stable v3.2, you can optionally extend it with car rental booking and selected post-booking capabilities available in Beta.
The capabilities in this section are Beta and are not required to migrate an existing v3.1 Search, look and redirect integration to stable v3.2.
Beta supports the Search, look and book flow.
A typical direct-booking flow uses:
- /cars/search to retrieve car rental offers.
- /cars/availability to validate the selected offer and retrieve its latest pricing, policies, optional products, and insurance.
- /orders/preview to validate the selected order configuration and calculate its final pricing and payment schedule.
- /orders/create to create the order.
| Endpoint | Purpose | Related guide |
|---|---|---|
| /cars/availability | Validate the selected offer and retrieve its latest pricing, policies, optional products, and insurance. | Check car availability guide |
| /cars/terms-and-conditions | Retrieve the terms and conditions that apply to the selected car offer before booking. | Pre-booking terms and conditions guide |
Cars can be booked through the Orders API collection in Beta.
Use:
- /orders/preview to validate the selected order configuration and retrieve final pricing, policies, and payment information.
- /orders/create to create the car rental order.
The booking flow uses the offer and search_token obtained from the preceding Cars flow.
See the Car rentals tutorial for an end-to-end implementation walkthrough.
Selected post-booking functionality is also available in Beta.
| Endpoint | Purpose |
|---|---|
| /orders/details/cars/live | Retrieve the latest details for a car rental reservation. |
| /orders/cancel | Cancel a supported car rental order. |
| /orders/details/cars/terms-and-conditions | Retrieve post-booking terms and conditions. |
| /orders/details/cars/faq | Retrieve booking-related FAQs. |
A dedicated sandbox environment is not currently available for car rental integrations.
When validating your migration, follow the approved testing process for your integration and coordinate with your Account Manager where required.
Make sure you validate:
- Updated /cars/search request and response parsing.
- Renamed /cars/depots fields.
- Payment timing mappings.
- Static-data handling.
- Redirect behaviour.
- Error handling.
- Downstream systems that consume Cars data.
- Beta booking and post-booking flows, if you implement them.
Use this checklist before completing your v3.1-to-v3.2 migration.
| Checklist | Action |
|---|---|
| ☑ | Review and implement the changes described in the /cars/search migration guide. |
| ☑ | Replace pick_up and drop_off with pickup and dropoff where applicable in /cars/depots. |
| ☑ | Remove dependencies on deskAt. |
| ☑ | Review and update mappings that depend on payment_timings.id. |
| ☑ | Validate the Cars endpoints used by your integration against the v3.2 schemas. |
| ☑ | Test your migrated integration end to end. |
| ☑ | Implement Beta booking and post-booking capabilities if required. |
- If you use /cars/search, continue with the /cars/search migration guide for detailed schema mappings.
- Review the Car rentals documentation for implementation guidance.
- Use the Demand API v3.2 Cars API reference to validate your migrated integration.
- If you are implementing direct booking, review the Beta API reference and the Car rentals tutorial.