Summary

This release introduces a platform-wide maximum record limit of 50,000 across all REST API endpoints that accept a limit parameter. Requests exceeding this value will now return HTTP 400 Bad Request. Previously, oversized requests were silently truncated.

Partners using high-volume search queries should review the affected endpoints below and update their integrations before the Live release.

Breaking Change

Global Maximum Query Limit — 50,000 Records

The following endpoints are affected:

• POST /transactions/allocations/search
• POST /transactions/search
• POST /guests/search
• POST /reservations/search

What's changing:

• Requests with a limit value above 50,000 will return HTTP 400 Bad Request with an explicit error message
• Requests at or below 50,000 are unaffected
• Endpoints that already have their own explicit limit lower than 50,000 are unaffected

Action required: If your integration passes a limit value greater than 50,000 on any of the above endpoints, you will need to update your queries to use pagination or reduce the limit before the Live release. Partners identified as impacted have been contacted directly.

Notes

• Available in Beta only. Live release is tentatively scheduled for 2 June 2026, subject to Beta validation.
• Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

Summary

This Beta release introduces three new feature areas — guest classifications, company branch offices, and headless payment tokenisation — along with a platform-wide query limit change. Partners using high-volume search endpoints should review the Breaking Change section below ahead of Live.

New Features

Guest Classifications — New Endpoints

New endpoints have been added to support full management of guest classifications, enabling retrieval, assignment, replacement, and removal of classifications on a guest record.

New endpoints:

• GET /guestClassifications — Retrieve available classification types
• GET /guests/{id}/classifications — Get classifications assigned to a guest
• POST /guests/{id}/classifications — Add a classification to a guest
• PUT /guests/{id}/classifications — Replace the full classification set for a guest
• DELETE /guests/{id}/classifications/{classificationId} — Remove a specific classification from a guest

Company Branch Offices — New Endpoints

New endpoints have been added to support programmatic management of branch office relationships between company records. This removes the need to maintain these links manually in the RMS UI.

When adding branch offices, you can optionally copy all assigned rates from the master company to each branch office at the time of creation by passing "assignParentRates": true. Note: rate copying occurs at creation time only and does not establish an ongoing sync.

New endpoints:

• POST /companies/{parentId}/branchOffices — Link one or more companies as branch offices of a master company
• GET /companies/{parentId}/branchOffices — Retrieve all branch offices for a master company
• DELETE /companies/{parentId}/branchOffices/{companyId} — Remove a branch office link

Credit Card Tokenisation — merchantReference Field

POST /guests/{id}/creditCard now accepts an optional merchantReference field. This integrator-supplied string (max 100 characters) is stored at token creation time and acts as the lookup key when retrieving token details via searchGuestRmsPayToken.

This enables fully headless payment flows — for example, AI voice agents collecting card details over the phone — to complete the rmsPay flow without requiring any UI interaction from the guest.

• Endpoint affected: POST /guests/{id}/creditCard

Note: RMS does not enforce uniqueness on merchantReference. The integrator is responsible for managing reference values.

⚠️ Breaking Change — Global Maximum Query Limit: 50,000 Records

A global maximum record limit of 50,000 is being introduced across all REST API endpoints that accept a limit parameter. Previously, requests with limits up to 1,000,000 were accepted and silently truncated. From this release, any request exceeding 50,000 will return HTTP 400 Bad Request.

Affected endpoints:

• POST /transactions/allocations/search
• POST /transactions/search
• POST /guests/search
• POST /reservations/search

Action required: If your integration currently requests more than 50,000 records in a single call on any of the above endpoints, you will need to reduce your limit value or implement pagination before this change reaches Live. Partners identified as using limits above 50,000 have been contacted directly.

Endpoints with an existing explicit limit lower than 50,000 are unaffected.

Notes

• Release Date: April 16, 2026 — Beta only
• Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

We've resolved an issue where some RazorPay bookings were not being confirmed after a successful payment.

What was happening? In certain cases, guests who navigated away, refreshed the page, or pressed the back button during the RazorPay payment process would have their payment processed but their booking not confirmed. This was because the frontend was not sending the final request to the booking confirmation API when the payment flow was interrupted by a page navigation.

What's been fixed? Guests are now kept on the payment processing page while their RazorPay transaction completes, preventing accidental navigation away before the booking is confirmed. This ensures the confirmation API is reliably called after a successful payment, so bookings are completed as expected.

Who does this affect? Properties using RazorPay as their payment gateway through IBE+.

Summary

This Beta release includes two fixes and one new feature enhancement. Partners are encouraged to validate these changes in Beta and report any issues via standard support channels.

New Features

Guest Classifications — New Endpoints

New endpoints have been added to support full management of guest classifications, enabling retrieval, assignment, replacement, and removal of classifications on a guest record. 

New endpoints:

• GET /guestClassifications — Retrieve available classification types SwaggerHub ↗
• GET /guests/{id}/classifications — Get classifications assigned to a guest SwaggerHub ↗
• POST /guests/{id}/classifications — Add a classification to a guest SwaggerHub ↗
• PUT /guests/{id}/classifications — Replace the full classification set for a guest SwaggerHub ↗
• DELETE /guests/{id}/classifications/{classificationId} — Remove a specific classification from a guest SwaggerHub ↗

Fixes & Improvements

Pencil Reservation — Dynamic Pricing Rate Consistency

• Issue: When a rate type was applied to a pencil reservation via the API, the quoted rate was not being preserved. If dynamic pricing changed before the pencil was converted to Unconfirmed/Confirmed, the reservation would be re-quoted at the new rate — producing a different rate than originally presented to the guest.
• Fix: Applying a rate type to a pencil reservation via the API now correctly preserves the quoted rate and occupancy snapshot. The rate will be retained when the pencil is subsequently converted.
• Endpoints affected: PATCH /reservations/{id}, PUT /reservations/{id}/status

Reservation Hold — 404 Error on Create

• Issue: When creating a new reservation hold via the API, a 404 Not Found error was returned despite the hold record being successfully created.
• Fix: POST /reservations/{id}/holds now returns the correct 200 OK response with the hold record payload upon successful creation.
• Endpoint: POST /reservations/{id}/holds

Notes

• Release Date: April 8, 2026 Beta only
• Dependencies: None
• There is no impact to Live environments.
• Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

Your guests can now pay with Apple Pay directly from the guest page- making checkout faster, more familiar, and more secure.

How it works

Apple Pay appears as a payment option on the guest page alongside existing methods. Guests on an Apple device can pay instantly. Guests on a non-Apple device will still see the option- they can select it and scan the QR code with their iPhone to complete the payment seamlessly.

Works just like your existing card payments

Tokens and receipts behave exactly the same as credit card transactions, so your team won't need to change a thing. That means:

• ✅ Refunds can be processed as normal
• ✅ Pre-auth tokens can be created for same-day arrivals
• ✅ All existing RMSPay workflows apply

A couple of things to know

Apple Pay will not appear as a payment option when a property's deposit rule is set to No Deposit & Tokenize. In that case, the option is automatically hidden - no action needed on your end.

Summary

This Beta release includes one enhancement to company and travel agent note management via the API. Partners are encouraged to validate this change in Beta and report any issues via standard support channels.

New Features

Company & Travel Agent Notes — All Properties Support

The API now supports creating and updating notes scoped to All Properties for both company and travel agent records, by passing propertyId: 0 in POST and PUT requests. This aligns API behaviour with what is already possible in the RMS UI.

Previously, propertyId: 0 was rejected by the API, requiring notes to be managed on a per-property basis only.

Additionally, validation has been added to PUT requests to ensure the propertyId in the request matches the existing note's scope. Attempting to update an All Properties note with a specific property ID (or vice versa) will return a 400 error.

Endpoints affected:

• POST /companies/{id}/notes — SwaggerHub ↗
• PUT /companies/{id}/notes/{noteId} — SwaggerHub ↗
• POST /travelAgents/{id}/notes — SwaggerHub ↗
• PUT /travelAgents/{id}/notes/{noteId} — SwaggerHub ↗

Note: Using propertyId: 0 creates a note that applies across all properties the token has access to. API users should be intentional when using this scope — if your integration does not have access to all properties, use property-specific notes instead.

Notes

• Release Date: March 25, 2026  Beta only
• Dependencies: None
• There is no impact to Live environments.
• Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

Notifications triggered from the Guest Portal will no longer send email alerts to the primary admin user. 

All relevant notifications will instead be available within the Message Centre.

We have resolved an issue in the RMS Booking Engine (IBE+) where Google tag data was not being recorded upon booking confirmation.

Previously, Google tags were failing to fire on the confirmation page after a guest completed payment. This meant that transaction data - including booking conversion events - was not being captured in your connected Google Analytics account, resulting in incomplete or missing reporting data.

This issue has now been fixed. Google tags will fire correctly on the confirmation page, ensuring that all transaction and conversion data is accurately recorded as expected.

We have resolved an issue in the RMS Booking Engine (IBE+) where the Area URL modifier was not functioning correctly when check-in and check-out dates were not included in the URL.

Previously, when a guest landed on the booking engine via a URL containing only an Area parameter (without dates), the Area filter would be dropped once the guest manually selected dates and clicked Search - resulting in all categories being displayed rather than only those mapped to the specified area.

This issue has now been resolved. The Area filter will now persist correctly in both scenarios: when dates are included in the URL, and when a guest manually selects dates after landing on the page. Only categories mapped to the specified Area ID will be displayed, as intended.

If you have any questions or require further assistance, please reach out to our support team.

The icons at the top of the Generated Report have been updated with new sizes and a revised display order to improve overall clarity.