Skip to main content
The OTA_HotelResModifyRQ (Hotel Reservation Modify Request) is used to request changes to an existing booking. It supports lightweight updates (minor changes) as well as recalculation-triggering updates (major changes).
This feature is only supported for hotel bookings.
Already know OTA messages? Jump straight into Testing.

OTA_HotelResModify API call

Skip & Hit the Playground.

Purpose

This message is used to:
  • Apply minor changes without recalculating prices.
  • Initiate major changes that recalculate the booking and may change price and cancellation terms.
  • Carry partner and child references that tie the modification to the original booking.
  • Occupancy changes are not allowed via OTA Modify.

Supported Changes

Minor Changes

  • Name change of a non lead pax (Change name, surname or prefix).
  • Change minor details of any pax (email, telphone number, address, fax).
  • Comments / Booking notes can be added. Existing ones can not be deleted nor modified.

Major Changes

  • Room can be changed if the conditions allow it.
  • Board change.
  • Dates change.
All the Major Changes are subject to availability, conditions, and will trigger a recalculation based on the current status of the contract.

Non-Supported Changes

Changes that are not allowed via HotelResModify. Cancel and rebook:
  • Occupancy changes: add or remove passengers.
  • Birthdate changes: change the birthdate of a pax, possibly changing its age group.
  • Lead Pax name.
  • Accomodation change.
Viable with other methods:

Structure – Root Element

Key Attributes:
  • ResStatus: Quote (preview) or Commit (apply changes).
  • Version: OTA message version (e.g., “2008.1”).
  • PrimaryLangID: ISO 639 language code (optional).
  • xmlns: “http://www.opentravel.org/OTA/2003/05”.

Structure – Core Elements

POS (Point of Sale)

Identifies the requesting party and includes credentials.

HotelResModify

Container for one modification transaction and its content. Very similar to the OTA_HotelResModifyRQ.

RoomStay

Defines the room(s) being modified and links them to guests and services.

Service

Non-room services linked to a room or guests (e.g., meal plan code at booking level).

ResGuest

Passenger details linked by ResGuestRPH.

ResGlobalInfo

Booking-level info such as comments and references.

Process & Rules

  • Always start with an OTA_ReadRQ to fetch the current state before modifying.
  • Validate that immutable identifiers match the original booking: distributor reference, lead pax first/last name, ClientID, and HotelCode.
  • Use ResStatus="Quote" first to preview recalculation and upgrade offers; send ResStatus="Commit" to apply.
  • If the connected supplier does not support modifications, expect an error (e.g., modification not possible) and perform cancel + rebook under the same distributor reference with a new child reference.
  • Minor changes (e.g., comments, non-lead pax name, contact details) do not trigger recalculation.
  • Major changes (e.g., room/board change, dates, optional extras) do trigger recalculation; pricing and cancel penalties may change.

Complete Example

Best Practices

  1. Send Quote first; only Commit after user confirmation.
  2. Keep references stable: do not change distributor/child references when not required.
  3. Maintain consistent guest ordering and RPH linking between RoomStay, Services, and ResGuests.
  4. Limit comments to operationally relevant notes; use Name="Applicant Notice" when adding comments.

Playground

OTA_HotelResModify API call

Skip & Hit the Playground.
Use the examples to hit the TEST environment;