Reservations
When sending reservations to IDeaS, we consider the reservations to be full overlays, where the last one received “wins” based on the “lastModifiedDateTime” provided within the message. Changes received are appended to the reservation ID and are used to improve forecasting and decisions within IDeaS RMS.
Each submission of a reservation has a “current” status of the reservation. IDeaS supports the following deducting reservation statuses and expects the status to follow the lifecycle of the reservation:
Non-Deducting Reservation Status
Some systems allow for a reservation to be created as “Reserved” and then changed to a non-deducting status. In this scenario, send a cancellation to IDeaS to remove the deducting reservation from IDeaS RMS data as a “sold”.
Personal Identifying Information (PII)
IDeaS does not request any Personal Identifying Information and expects that the sending system removes all PII data from reservation messages before sending.
Basic Reservations
Reservation yaml outlines the base requirements of all reservation messages submitted to IDeaS.
Day-Use Reservations
Following the Basic Reservation yaml, submit Day Use reservations to IDeaS with the same arrival and departure date.
Reservations on Pseudo Room Types / House Accounts
Reservations booked or moved to pseudo room types should be sent to IDeaS.
Booked vs Occupied Room Type Reporting
An important input into IDeaS RMS analytics is to track the original booked room type versus the occupied room type through the life of the reservation. The visibility in such a relationship is key to effective forecasting at the room type level and provides our Clients with enhanced RMS functionality referred to as Same-Time-Last-Year.
Following the synchronization of all reservations, IDeaS RMS will detect room type changes through the processing of incremental reservation updates. Supporting booked room type for both historical and future data is key to the enhanced forecasting and functionality.
Share Reservations
API requires share reservations to be identified on each of the reservation sharers to aggregate the reservations into a single room sold. You can provide a unique “shareId” that connects the share reservations together. Another option is to report the reservationIds for the other reservations connected to the share reservation. The nightly rate value can be split across the shared reservations, or the total nightly rate can be reported on the primary reservation.
Example of Reporting “shareId” where rate value is split:
| reservationId | shareId | Arrival | Depart | RoomType | Nightly Rate |
|---|---|---|---|---|---|
| 1234 | Share1 | 2025-12-20 | 2025-12-24 | BDDN | $50.00 |
| 1235 | Share1 | 2025-12-20 | 2025-12-24 | BDDN | $50.00 |
| 1236 | Share1 | 2025-12-20 | 2025-12-24 | BDDN | $50.00 |
| 1237 | Share1 | 2025-12-20 | 2025-12-24 | BDDN | $50.00 |
Example of reporting “sharers” where the rate value is on the “primary” reservation:
| reservationId | sharers | Arrival | Depart | RoomType | Nightly Rate |
|---|---|---|---|---|---|
| 1234 (primary) | 1235,1236,1237 | 2025-12-20 | 2025-12-24 | BDDN | $200.00 |
| 1235 | 1234,1236,1237 | 2025-12-20 | 2025-12-24 | BDDN | $0.00 |
| 1236 | 1234,1235,1237 | 2025-12-20 | 2025-12-24 | BDDN | $0.00 |
| 1237 | 1234,1235,1236 | 2025-12-20 | 2025-12-24 | BDDN | $0.00 |
Multi-Unit Reservations
To ensure proper handling of multi-unit reservations, each reservation must be split into individual entries with unique IDs before or during check-in. Partner systems must integrate this functionality to avoid discrepancies in occupancy and inventory data across applications. Two options to report multi-unit reservations are outlined below. One option must be selected and inform IDeaS Integration Specialist.
Option 1: Sending System Divides into Individual Reservations Before Sending
The system separates multi-unit reservations into individual reservations in the backend, each with a unique reservation ID, using the initial reservation ID as a reference before sending them to IDeaS RMS. The numberOfRooms serves as the identifier for the number of rooms reserved under the initial reservation.
Example: Original multi-unit reservation created in PMS/CRS
| ReservationID | No Rms | Arrival | Departure | RoomTypeCode | RateCode | MarketSegment | BookingDate |
|---|---|---|---|---|---|---|---|
| 12345 | 5 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
The multi-unit reservation is divided before sending to IDeaS and keeps the reservationID of each reservation in PMS/CRS as separate reservations throughout its duration in the PMS. The reservation ID is used to maintain updates in IDeaS RMS and therefore cannot be changed.
| ReservationID | No Rms | Arrival | Departure | RoomTypeCode | RateCode | MarketSegment | BookingDate |
|---|---|---|---|---|---|---|---|
| 12345_1 | 1 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
| 12345_2 | 1 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
| 12345_3 | 1 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
| 12345_4 | 1 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
| 12345_5 | 1 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
Option 2: IDeaS RMS Divides into Individual Reservations
Sending system sends original multi-unit reservation with numberOfRooms representing the total rooms held. IDeaS RMS handles the split of the individual reservations, maintaining the individual reservations until updates received from the sending system.
Example: Multi-unit reservation created in Sending System and sent to IDeaS.
| ReservationID | No Rms | Arrival | Departure | RoomTypeCode | RateCode | MarketSegment | BookingDate |
|---|---|---|---|---|---|---|---|
| 12345 | 5 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
IDeaS employs the same split logic as outlined in Option 1, where multi-unit reservations are divided. The Sending System will also provide a unique ID for the multiReservationId in the reservation payload to IDeaS. The multiReservationId enables tracking and updates when multi-unit reservations in the Sending System are divided to update IDeaS RMS, where the new reservation IDs will replace the divided reservation IDs generated by IDeaS.
| ReservationID | multiReservationId | No Rms | Arrival | Departure | RoomTypeCode | RateCode | MarketSegment | BookingDate |
|---|---|---|---|---|---|---|---|---|
| 12345_1 | 12345 | 1 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
| 12345_2 | 12345 | 1 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
| 12345_3 | 12345 | 1 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
| 12345_4 | 12345 | 1 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
| 12345_5 | 12345 | 1 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
Example: PMS/CRS splits reservations and sends updates to IDeaS with PMS/CRS reservationIDs.
| ReservationID | multiReservationId | No Rms | Arrival | Departure | RoomTypeCode | RateCode | MarketSegment | BookingDate |
|---|---|---|---|---|---|---|---|---|
| 12345 | 12345 | 1 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
| 56505 | 12345 | 1 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
| 56506 | 12345 | 1 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
| 56507 | 12345 | 1 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
| 56508 | 12345 | 1 | 2025-10-27 | 2025-10-31 | ADDN | BAR | RETAIL | 2025-04-11 |
Expected Handling of Sending System for Dividing Reservations
The next action of dividing the multi-unit reservation in the Sending System is a modification to the original reservation. The change would be recorded in the value of the numberOfRooms, followed by the receipt of a new reservation record for the divided reservation created. A cancel message is only to be provided if there is a legitimate cancellation of the reservation record.
Original Reservation Reporting More than 1 Room Hold on Reservation:
-numberOfRooms changes from original room count to reduced room count.
-multiReservationId represents original reservation ID or another ID that doesn’t change and will connect all multi-unit reservations through the duration in the Sending System.
Divided Reservation(s) Handling:
- Each divided reservation gets sent with its own unique reservation ID.
numberOfRooms= 1 for each divided reservation.- Original booking date is applied to split reservation(s).
multiReservationIdrepresents original reservation ID or another ID that doesn’t change and will connect all multi-unit reservations through the duration in the Sending System.
Cancellation Before Multi-Unit Reservation is Divided
If only one of the original reservations are cancelled, this becomes a reduction in the numberOfRooms and a modified reservation should be submitted to IDeaS to keep data in sync.
Cancellation After Multi-Unit Reservation is Divided
If one of the reservations is cancelled after dividing a multi-unit reservation, submit a modified reservation to IDeaS for the cancelled reservation. Only the cancelled reservation message is required to be submitted to keep data aligned between IDeaS RMS and the Sending System. There is no specific condition governing which of the divided reservations should be cancelled, provided that the remaining reservations retain the multiReservationID.