Testing and Certification

Follow the testing and certification process for the pmsXchange API to validate your integration and prepare for go-live with SiteMinder.

Once you have completed development, use this guide independently as a testing checklist and a self-certification tool to help you verify that all required capabilities for integration have been thoroughly tested.

Once ready, the Partner Integrations team will review your readiness. Upon approval, we will prepare your account and confirm when you can proceed with the formal certification process.

Instructions

To use this guide, ensure that you have access to our test Platform and that it's configured and mapped to your PMS. Additionally, you must have access to our test endpoint to send requests.

This guide provides a series of scenarios to test all available pmsXchange API capabilities. Regarding inventory, only Availability is mandatory, but the Rooms and Rates, Reservations Upload, Reservations Import, Payment Transaction Record, as well as Reservation (Initial Delivery) are also mandatory; the other capabilities are strongly recommended. If you do not support any of these optional capabilities, skip them and proceed to the next test scenario.

Once you have completed all test scenarios, you will be asked to fill out a form providing all the necessary information to finalise the certification.

Test Scenarios

To assist with automating your testing, please fork SiteMinder's PMS Postman Collection, where you will see various request scenarios, as well as the detailed breakdown of the Reservation Certification Scenarios.

Step 1 - Fork SiteMinder's PMS Postman Collection and pmsx-api environment.

Step 2 - Update the environment with your test details in the required fields.

For more details on using Postman, see the article Test your API using the Collection Runner.

Initial Setup

For testing and certification purposes, we have created two basic room types and two basic rate plans that are already mapped to your PMS system. Please create the same room and rate combinations in your system to begin testing and proceed with the self-certification process.

Please do not modify the mapping codes for these room rates, as they will be used for reservation certification scenarios. You may create additional room types and rate plans with your own mapping codes as needed.

1. Retrieve Rooms and Rates (SM -> PMS)

A PMS system sends a request to retrieve the list of configured mapping codes for room types and rate plans from the SiteMinder Platform using the Rooms and Rates API. These returned codes are then stored and used for mapping within the PMS.

Note: You should have already built and tested this API using the generic test account provided in your welcome pack. In this step, you will call the Rooms and Rates endpoint against your own SiteMinder test platform configuration and validate both the response and the mappings.

• Use the PMS code and test hotel code configured for your integration on the SiteMinder test Platform.

• Call the Rooms and Rates endpoint for your test hotel.

• Replace:

  • {pmsCode} with your PMS code.

  • {hotelCode} with the SiteMinder test hotel code

• Validate the response

• Map codes in your PMS

To successfully complete this scenario, your PMS must have retrieved all room rates mapping codes configured and mapped on SiteMinder Platform.

2. Small Flush Update

From the PMS, send a small full flush of all mapped room types' availability and restrictions & rates. You can do a flush of 30, 60 or 90 days.

This test ensures your PMS is bundling dates and optimising messages according to our Message Structure requirements: Availability and Restrictions & Rates .

• Check that you received a Success response from SiteMinder

• Check SiteMinder Platform -> Distribution -> Inventory Grid if the updates have been applied.

SiteMinder Platform Inventory

SiteMinder Platform Restrctions

3. Targeted Data Update (Delta)

This scenario tests updates where only specific data points, like a single rate change or availability adjustment made in the PMS, are sent for a short period, verifying the PMS ability to push delta data updates efficiently and accurately.

To complete this scenario, first select any future month within the next year. Then, for each specified day in the table (e.g., Day 1, Day 2, Day 5), apply the changes using the corresponding dates within that chosen month. For example, if you select March, use March 1 for Day 1, March 2 for Day 2, and March 5 for Day 5.

- Availability

Set availability for the following room type and date.

Room Type	Date	Availability
Room A	Day 1	6
Room B	Day 5 to Day 10	10

- Restrictions

Set restrictions for the following room rates and dates.

Room Type	Rate Plan	Date	Restriction
Room A	Rate 2	Day 3 to Day 7	Enable Stop Sell
Room A	Rate 2	Day 5	Disable Stop Sell
Room A	Rate 2	Day 4	Enable CTA
Room A	Rate 2	Day 7	Enable CTD
Room A	Rate 2	Day 1 to Day 28	Min. Stay to 2
Room A	Rate 2	Day 1 to Day 28	Max. Stay to 7

- Rates

Set rates for the following room rates and dates.

PDP

Room Type	Rate Plan	Date	Value
Room A	Rate 2	Day 15 to Day 17	200
Room A	Rate 2	Day 18	300
Room A	Rate 2	Day 20 to Day 21	350

OBP

Room Type	Rate Plan	Date	Value
Room A	Guest 1	Day 1 to Day 15	150
	Guest 2		200
	Guest 3		250
	Guest 4		300
	Guest 5		350

---

4. Reservations

You have two options to create test reservations, modifications, and cancellations to validate the Reservations API flow:

• Direct Booking Engine URL – You can create test bookings through the Direct Booking engine. Refer to the instructions and details provided in your development pack email.

• SiteMinder's PMS Postman Collection

This testing and certification guide focuses on reservation creation using the Postman collection scenarios, which simulate reservations being sent from a booking channel to SiteMinder and then delivered to your PMS using “RTC” as the booking agent code. In the PMSX Postman Collection, we have created six reservation scenarios to help you test how your PMS handles reservations, modifications, and cancellations delivered by SiteMinder.

Refer to the Reservations for further details on the reservation data you will receive.

Before you begin, you must fork SiteMinder's PMS Postman Collection and set up the environment with your given test details.

For security reasons, always use test credit card details and never real ones when testing reservations. Refer to Test Credit Cards.

Purpose

• Verify that your PMS can successfully receive reservations, modifications, and cancellations from SiteMinder via pmsXchange (PUSH or PULL, depending on your configured method).

• Ensure that, for each message, the PMS can either confirm receipt or report processing failure.

• Ensure that your PMS sends OTA_HotelAvailNotifRQ updates to SiteMinder with the correct delta availability after reservations, modifications, and cancellations are processed

  • Only delta updates are acceptable.

  • Check-out dates and any non-occupied dates must not be included in the availability update.

– Create Test Reservations

Scenario 1 – Reservation 1 (Single Reservation) This scenario creates Reservation 1 as a simple baseline booking. A single reservation is created for one room type and one rate plan for a 3-night stay.

Verify that:

• The reservation is successfully created in the PMS system.

• The PMS confirms the receipt.

• The PMS sends a delta reduced availability update (OTA_HotelAvailNotifRQ) for the room type and dates in the reservation.

---

Scenario 2 – Reservation 2 (Modify Date and Room Type) Reservation 2 starts as a single reservation for one room type and one rate plan for 3 nights (Day 23, 24, 25), and will then be modified and cancelled in the sub-scenarios.

Verify that:

• The initial reservation is successfully created in the PMS system.

• The PMS confirms the receipt.

• The PMS sends a delta reduced availability update (OTA_HotelAvailNotifRQ) for the room type and those dates in the reservation.

Scenario 2.1 – Modify Dates This step modifies Reservation 2 by changing only the stay dates. The original reservation has a check-in on Day 23 for a 3-night stay. In this scenario, the check-in is moved to Day 24, while the length of stay (3 nights), room type, and rate plan all remain unchanged.

Verify that:

• The updated reservation in your PMS reflects the new check-in date (Day 24) and the correct 3-night stay.

• The PMS confirms the receipt.

• The PMS sends a delta update (OTA_HotelAvailNotifRQ) that:

  • Releases availability for the original check-in date (Day 23).

  • Reduces availability for the newly occupied night (Day 25).

Scenario 2.2 – Modify Room Type This step modifies Reservation 2 by changing only the room type. Using the reservation after Scenario 2.1 (check-in Day 24, 3-night stay), the booking is updated to a different room type, while the check-in date, length of stay, and rate plan remain unchanged.

Verify that:

• The reservation in your PMS now shows the new room type, with the same check-in/check-out dates, length of stay, and rate plan.

• The PMS confirms the receipt.

• The PMS sends a delta update (OTA_HotelAvailNotifRQ) that:

  • Increases availability for the original room type for the occupied dates.

  • Decreases availability for the new room type for the same dates.

Scenario 2.3 – Cancel Reservation 2 This step cancels Reservation 2 completely. The same reservation used in Scenarios 2.1 and 2.2 is now fully cancelled, releasing all previously booked room nights back to availability.

Verify that:

• The reservation status in your PMS is cancelled.

• The PMS confirms the receipt.

• The PMS sends a delta update (OTA_HotelAvailNotifRQ) that increases availability for all cancelled room nights (correct room type and dates).

---

Scenario 3 – Reservation 3 (Multiple Rooms – Different Room Types) This scenario creates Reservation 3 with two different room types under the same reservation ID. Both rooms share the same stay dates and are part of a single multi-room booking that will then be modified and cancelled in the sub-scenarios.

Verify that:

• The initial reservation is successfully created in the PMS system with two rooms (two different room types).

• The PMS confirms the receipt.

• The PMS sends a delta reduced availability update (OTA_HotelAvailNotifRQ) for both room types and their dates in the reservation.

Scenario 3.1 – Remove 1 Room This step modifies Reservation 3 by removing one of the room types, so that only one room remains active under the same reservation ID.

Verify that:

• The updated reservation in your PMS still has the same reservation ID, but now only one active room (one room type) remains.

• The PMS confirms the receipt.

• The PMS sends a delta update (OTA_HotelAvailNotifRQ) that:

  • Increases availability for the removed room type for the affected dates.

Scenario 3.2 – Add 2 Rooms This step modifies Reservation 3 from Scenario 3.1 by adding 2 additional rooms to the active reservation (for a total of 3 rooms under the same reservation ID).

Verify that:

• The updated reservation in your PMS still has the same reservation ID, now with 3 active rooms (the original remaining room + 2 newly added rooms).

• The PMS confirms the receipt.

• The PMS sends a delta reduced availability update (OTA_HotelAvailNotifRQ) for the additional added rooms and their dates.

Scenario 3.3 – Cancel Reservation 3 This step cancels Reservation 3 completely. The multi-room reservation used in Scenarios 3, 3.1, and 3.2 is now fully cancelled, releasing all booked room nights back to availability.

Verify that:

• The reservation status in your PMS is cancelled for the entire multi-room booking.

• The PMS confirms the receipt.

• The PMS sends a delta update (OTA_HotelAvailNotifRQ) that increases availability for all rooms and dates associated with Reservation 3.

---

Scenario 4 – Reservation 4 (Multi Rooms – Different Rate Plans) This scenario creates Reservation 4 with multiple rooms on different rate plans under a single reservation ID.

Verify that:

• The reservation is successfully created in the PMS system, with each room linked to its own rate plan.

• The PMS confirms the receipt.

• The PMS sends a delta reduced availability update (OTA_HotelAvailNotifRQ) for the booked dates.

---

Scenario 5 – Reservation 5 (Multi Rooms – Back-to-back Stays on Different Rate Plans) This scenario creates Reservation 5 with two rooms, where the stays are back-to-back and use different rate plans.

Verify that:

• The reservation is successfully created in the PMS system.

• The PMS confirms the receipt.

• The PMS sends a delta reduced availability update (OTA_HotelAvailNotifRQ) for the occupied nights and room type.

---

Scenario 6 – Reservation 6 (Multi Rooms – Split Date Range) This scenario creates Reservation 6 with two separate stays under a single reservation ID, where the stays are not consecutive.

Verify that:

• The reservation is successfully created in the PMS system.

• The PMS confirms the receipt.

• The PMS sends a delta reduced availability update (OTA_HotelAvailNotifRQ) only for the occupied nights of each stay, reflecting the split date ranges.

– Validate Availability Updates (Optional but Recommended)

As a final self-certification step for the Reservations section, you can use the PMS Postman Collections (Room Level Avail. Res. Certification or Rate Level Avail. Res. Certification) to validate that availability updates sent from your PMS back to SiteMinder are correct after each reservation, modification, and cancellation event.

Using the Postman collection to:

• Get initial availability

  • Call Get initial availability for the relevant room type and dates to see the current availability stored in SiteMinder’s system received from the PMS.

• Create the reservation scenario

  • Run the corresponding reservation scenario (new booking, modification, or cancellation) from the PMS Postman Collection so the booking is created, modified, or cancelled in SiteMinder and delivered to your PMS.

• Get updated availability

  • Call Get updated availability for the same room type and dates to see the new availability stored in SiteMinder’s system after your PMS update.

• Compare results

  • Check that availability has increased or decreased only for the occupied nights.

Note: For the Reservation Certification scenarios, you can run the collections. The delay between scenarios is controlled by the delayRun variable in the pmsx-api environment.

---

5. Reservation Upload

1. Reservation Creation and Testing:

   • Generate a set of test reservations, including scenarios where reservations are:

     • @ResStatus is Reserved , Waitlisted , Cancelled , No-show , In-house or Checked-Out

     • POS / Source is Walk-in Reservations, Direct Booking Channel Reservations, CRS/GDS/Wholesaler Reservations or SiteMinder Modification/Cancellation.

2. Content Validation:

   • The system should be tested with both Reservation XML Samples contained in the Reservation Upload to ensure compatibility with varying data sizes.

3. Response Validation:

   • SiteMinder will respond with a success (OTA_HotelResNotifRS) or an eloquent error message for each reservation.

   • Errors will clearly describe the issue (e.g., missing data) but will not affect the HTTP status code, which will remain 200.

   • Standard HTTP error codes will be used (e.g., 500, 503) only for server-level issues.

4. Issue Reporting and Fixes:

   • If an issue is identified (e.g., reservations not delivered, unclear responses), please notify the SiteMinder Partner Integrations team to investigate for you.

   • Once the issue is resolved, testing can resume.

   • You can "fail" certification multiple times; the process aims to address all issues before final approval.

6. Reservation Import

The Reservations Import endpoint allows PMSs to request a full refresh of all future reservations and modifications for a hotel associated with that PMS. This request triggers a background job that queues these reservations and delivers them to the PMS through the standard Reservations PULL flow.

1. Please reach out to the SiteMinder Partner Integrations team when you are ready to test this API.

2. The Partner Integrations team will trigger several bookings for you, then inform you when they are ready for collection.

3. Finally, you will then be requested to query the Reservations Import endpoint, allowing you to pull the available future reservations.

7. Payment Transaction Record

The Payment Transaction Record API allows the PMS to retrieve reservation payment transaction data. These transactions represent payments made against a reservation using SiteMinder Pay, which provides secure payment processing for booking channels and direct bookings through the SiteMinder Platform.

Please follow the steps below to perform testing.

1. Create a reservation using the SiteMinder Direct Booking Engine or other approved testing tools.

2. Locate the created reservation by searching for the reservation ID in the Reservations tab on the SiteMinder Platform.

3. Process a payment (charge) or refund against the reservation using SiteMinder Pay.

   • See guide: Video: Process payments and refunds

4. Send SM_HotelResPaymentReadRQ to retrieve any undelivered payment transactions for the specified hotel.

5. Upon receiving SM_HotelResPaymentReadRS from SiteMinder, store and process the payment transaction data.

6. Send SM_HotelResPaymentResultRQ to confirm successful storage and processing of the payment transactions or error.

7. If success, you should then receive SM_HotelResPaymentResultRS from SiteMinder as confirmation.

Final Steps

If you are using this guide as a testing checklist and are now ready to begin certification, please contact the Partner Integrations team to confirm your readiness. If you are already in the certification process, complete the form provided via email, ensuring that all required information is accurately included for final review.