Preview order modifications v3.3

Use the /orders/modify/preview endpoint to check whether an accommodation date change or a room adult-allocation change can be applied before you submit it. For date changes, the response also includes the current and proposed total order prices.

Use the /orders/modify/preview endpoint to check whether a requested change can be applied to an order.

Use the preview endpoint to:

✅ Validate whether a modification to a date or number of adults allocated to a room is allowed.
✅ Identify constraints before submitting a modification.
✅ Show users the expected cost impact (for accommodation date changes)

The endpoint does not preview payment card changes, guest name changes or smoking preference changes. Submit those changes directly to /orders/modify.

1. Call /orders/modify/preview with the order ID and the requested change.
2. Check the data.modifiable field in the response.
3. If data.modifiable is true, submit the same change to /orders/modify.
4. If data.modifiable is false, use data.reason to explain why the requested change cannot be applied. Do not submit that change to orders/modify.

The request body requires order and modification.

The modification object requires accommodation, which identifies the reservation and the type and details of the change.

• For a date change, change must include checkin and checkout as calendar dates in YYYY-MM-DD format. The check-out date must be later than the check-in date.
• For a room change, change must include room_reservation and allocation.number_of_adults. The adult count must be at least 1 and must not exceed the room's maximum capacity.

Set modification.accommodation.type to dates and provide the new check-in and check-out dates in modification.accommodation.change.

{
  "order": "6520081014",
  "modification": {
    "accommodation": {
      "reservation": "6187285715",
      "type": "dates",
      "change": {
        "checkin": "2027-04-19",
        "checkout": "2027-04-21"
      }
    }
  }
}

A date change may affect the total order price.

• If the preview is modifiable, compare data.price.current.amount with data.price.new.amount.
• The currency field applies to both amounts.

Set modification.accommodation.type to room to preview a change to the number of adults allocated to a room reservation.

{
  "order": "6520081014",
  "modification": {
    "accommodation": {
      "reservation": "6187285715",
      "type": "room",
      "change": {
        "room_reservation": "9876543210",
        "allocation": {
          "number_of_adults": 2
        }
      }
    }
  }
}

The request uses two identifiers:

• reservation identifies the accommodation reservation within the order.
• room_reservation identifies the room reservation whose adult allocation you want to change.

All responses include:

• request_id – Unique identifier for the request.
• data.modifiable – Indicates whether the requested change can be applied.

When data.modifiable is true, submit the same change to /orders/modify. For a date change, the response includes price. For a room allocation change, price is not returned.

Example of date modification response:

{
  "request_id": "01kjan7r7yvff5yg95gxy1cjhy",
  "data": {
    "modifiable": true,
    "price": {
      "currency": "EUR",
      "current": {
        "amount": 200.00
      },
      "new": {
        "amount": 250.00
      }
    }
  }
}

The price object is returned only for a modifiable date change.

• It contains the current and proposed total order prices.
• The currency field applies to both amounts.

Use these values to show the proposed price and any difference before submitting the modification.

When data.modifiable is false, the response includes a reason code. Do not submit the change to /orders/modify.

{
  "request_id": "01kjan7r7yvff5yg95gxy1cjhy",
  "data": {
    "modifiable": false,
    "reason": "not_available"
  }
}

Use the reason code to explain why the requested change cannot be applied.

HTTP 200 means the preview request was processed. A business constraint is represented by data.modifiable set to false and a reason code.

An HTTP error means the request could not be processed. For example:

• HTTP 400 can indicate missing or malformed values, an invalid request structure or an unsupported modification type.
• HTTP 404 indicates that the order or reservation does not exist or is not accessible to the affiliate making the request.
• HTTP 500 indicates an unexpected server error; retry later and contact support if the problem continues.

• The endpoint previews only accommodation date changes and changes to the number of adults allocated to a room reservation.
• It does not preview payment card changes, guest name changes or smoking preference changes.
• Price information is returned only for a modifiable date change.
• A preview does not reserve availability or guarantee that the subsequent modification request will succeed.