Check out the latest features, improvements, and product updates from RMS
RMS has integrated Maya as a new eCommerce payment gateway, enabling customers in the Philippines to complete online transactions. This release expands RMS’s regional payment capabilities and improves the checkout experience for customers in the Philippine market by offering a familiar and locally preferred payment option
The users now can generate and download a password protected tribunal bundle, including the details of the reservation, transactions and correspondece.
You can now organise your Form Letters by category and quickly filter to find what you need.
Summary
This Live release brings together the improvements, fixes, and new features previously delivered across the Beta cycle, spanning error handling improvements, notes management enhancements, guest classification management, reservation reliability fixes, and new headless payment tokenisation support.
Included in this Live release:
propertyId: 0, aligning API behaviour with the RMS UI. Validation added to PUT requests to enforce scope consistency. 👉 Beta details: https://releasenotes.rmscloud.com/rest-api-v10.26.77.4----beta-XO8UMmerchantReference field for headless payment tokenisation via POST /guests/{id}/creditCard. 👉 Beta details: https://releasenotes.rmscloud.com/rest-api-v10.26.105.2----beta-4BL7vaNotes
POST /transactions/allocations/search, POST /transactions/search, POST /guests/search, and POST /reservations/search. Requests exceeding this limit will return HTTP 400. If your integration requests more than 50,000 records in a single call on any of these endpoints, please reduce your limit or implement pagination before this date. https://releasenotes.rmscloud.com/rest-api-v10.26.105.2----beta-only-breaking-change---maximum-query-limit-4CTw1q
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 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 typesGET /guests/{id}/classifications — Get classifications assigned to a guestPOST /guests/{id}/classifications — Add a classification to a guestPUT /guests/{id}/classifications — Replace the full classification set for a guestDELETE /guests/{id}/classifications/{classificationId} — Remove a specific classification from a guestNew 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 companyGET /companies/{parentId}/branchOffices — Retrieve all branch offices for a master companyDELETE /companies/{parentId}/branchOffices/{companyId} — Remove a branch office linkmerchantReference FieldPOST /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.
POST /guests/{id}/creditCardNote: RMS does not enforce uniqueness on
merchantReference. The integrator is responsible for managing reference values.
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/searchPOST /transactions/searchPOST /guests/searchPOST /reservations/searchAction 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.
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.
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 ↗Pencil Reservation — Dynamic Pricing Rate Consistency
PATCH /reservations/{id}, PUT /reservations/{id}/statusReservation Hold — 404 Error on Create
404 Not Found error was returned despite the hold record being successfully created.POST /reservations/{id}/holds now returns the correct 200 OK response with the hold record payload upon successful creation.POST /reservations/{id}/holdsYour 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:
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.
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.
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: 0creates 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.
What's new?
The Availability Calendar is now a standard feature of the new RMS Booking Engine - visible across all properties, automatically.
Here's what's changed and what you need to know:
Always on, for everyone The calendar now displays by default for all properties using the new Booking Engine. There's no longer a toggle in Online Options to turn it on or off - it's simply there, ready for your guests.
Rates on the calendar — your choice Want guests to see rates directly on the calendar? You can enable this in your Online Options settings. If you'd prefer to keep rates off the calendar view, simply leave the setting off.
Clean and focused The calendar shows availability and rates only. Restrictions are not displayed, keeping the guest-facing experience simple and distraction-free.
What do you need to do?
Why this matters Giving guests a clear view of what's available - and at what price -reduces friction and helps drive direct bookings. Less guesswork for guests means more conversions for you.
Availability Calendar Help Article
Auto Discounts are now available to all IBE+ customers across all environments!
What's changed
Nothing about how Auto Discounts work has changed - this is the same behaviour as legacy IBE.
A few important things to be aware of
Promo codes & memberships take priority - if a guest uses a promo code or has a membership applied, the auto discount will not calculate. Pre-determined promo codes and memberships sit at the top of the hierarchy.
Discount priority order: