Policies & Terms
Every booking in the Adapt2Move API carries cancellation and change policies that govern what actions a traveler can take and under what conditions. These policies are returned alongside offer and booking data, so your integration always has the information it needs to guide users through modifications or cancellations.
Policies can shift between the search, prebook, and booking stages. Always rely on the most recent API response for accurate policy data — once a booking is confirmed, the policies attached to that confirmation are final.
Retrieving Policies
Policies appear in two key places during the booking lifecycle. The prebook response includes the policies that apply to the offer the user is about to confirm, and the booking details response includes the finalized policies for an active booking.
Both responses share the same policy structure:
{
"cancellationPolicy": {
"availability": "AVAILABLE_VIA_API",
"conditions": [
{
"type": "FREE_CANCELLATION",
"deadline": "2026-11-30T10:00:00Z",
"description": "Free cancellation until 24 hours before pickup"
},
{
"type": "WITH_FEE",
"fee": { "amount": 2500, "currency": "EUR" },
"description": "€25 cancellation fee within 24 hours"
}
],
"refundPolicy": "FULL_REFUND_IF_BEFORE_DEADLINE"
},
"changePolicy": {
"availability": "REQUIRES_MANUAL_CONTACT",
"conditions": []
}
}
Each policy contains an availability level, an array of time-based conditions, and — for cancellations — a refundPolicy describing the refund behavior.
Availability Levels
The availability field on each policy determines how (or whether) the action can be performed.
| Level | Meaning | Implementation |
|---|---|---|
AVAILABLE_VIA_API | Can perform via API | Call corresponding API endpoint |
REQUIRES_MANUAL_CONTACT | Must contact provider | Display provider contact info to user |
NOT_AVAILABLE | Action not allowed | Disable option in UI |
Always inspect the availability field before attempting a cancellation or modification request. Calling an endpoint when the policy is NOT_AVAILABLE or REQUIRES_MANUAL_CONTACT will result in an error.
Cancellation Policies
Cancellation policies define whether a booking can be cancelled, what it will cost, and by when. The conditions array contains one or more time-windowed rules, evaluated in order. The four condition types are:
FREE_CANCELLATION— no charge if cancelled before the specifieddeadlineWITH_FEE— a fixed fee applies (amount and currency provided in thefeeobject)PERCENTAGE_FEE— a percentage of the total booking price is chargedNO_REFUND— the booking is non-refundable regardless of timing
Deadlines are ISO 8601 timestamps in UTC. When multiple conditions are present, they typically represent a progression — for example, free cancellation until 48 hours before pickup, then a fee within 48 hours, then no refund after pickup time. Your UI should display the active condition based on the current time relative to these deadlines.
Change Policies
Change policies cover modifications to an existing booking, including date and time adjustments, pickup or dropoff location changes, and traveler detail updates. The structure mirrors cancellation policies, with its own availability level and conditions array.
In practice, change policies tend to be more restrictive than cancellation policies. Name changes are frequently disallowed, location changes may require a new search entirely, and modifications within 24 hours of pickup are often blocked. When the availability is REQUIRES_MANUAL_CONTACT, surface the provider's contact information so the user can request changes directly.
Terms & Conditions
Bookings include a reference to the provider's terms and conditions, which the user must accept before confirming a booking.
{
"termsAndConditions": {
"url": "https://provider.com/terms",
"mustAcceptBeforeBooking": true
}
}
When mustAcceptBeforeBooking is true, present a checkbox — such as "I accept the Terms and Conditions" — and block the booking request until the user has checked it. The terms URL should open in a new tab or modal so the user can review before accepting. Store the acceptance timestamp with the booking record on your side.
Displaying Policies
Clear policy presentation is essential for a trustworthy booking experience. The following items are required integration points:
- Show policies before booking confirmation
- Include policies in the booking details view
- Display policies before cancellation or modification actions
- Show exact fee amounts and deadlines from the API response
- Require explicit acknowledgment for non-refundable bookings
Use plain language when surfacing policy data. Translate condition types into human-readable text — for example, render a FREE_CANCELLATION condition with a deadline as "Free cancellation until Nov 30, 10:00 AM" rather than exposing the raw type or ISO timestamp. Place deadline and fee information near the relevant action buttons so users see it at the moment of decision.
API Endpoints
Cancel Booking
Check cancellationPolicy.availability before calling. If the policy is anything other than AVAILABLE_VIA_API, this endpoint will reject the request.
Modify Booking
Check changePolicy.availability before calling. Pass only the fields you want to change in the request body.
See OpenAPI Reference for complete request and response schemas.
Error Handling
When a cancellation or modification violates the active policy, the API returns a POLICY_VIOLATION error with details about the deadline that was missed:
{
"success": false,
"error": {
"code": "POLICY_VIOLATION",
"message": "Cancellation not allowed within 24 hours of pickup",
"details": {
"deadline": "2026-11-30T10:00:00Z",
"currentTime": "2026-12-01T08:00:00Z"
}
}
}
Handle this gracefully by comparing the deadline and current time from the response, then showing the user a clear explanation — for example, "The cancellation deadline passed on Nov 30 at 10:00 AM." If the change policy allows manual contact, offer the provider's details as a fallback.