Summary

This Live release covers the v10.26.266.6 Beta cycle, delivering a new endpoint for reservation repeat charge schedules, custom CSS branding for RMSPay hosted payment pages, and new fields across sundries, transactions, reservations, and booking sources. It also includes an audit trail logging fix for API-created sundries. There are no breaking changes in this release.

Included in this Live release:

• RMSPay custom CSS branding — Partners can now pass a cssCustomUrl field to brand the RMSPay hosted payment page. 👉 Beta details: https://releasenotes.rmscloud.com/rest-api-v10.26.266.6----beta-4zFBsY
• Repeat charges — New endpoint returns reservation repeat charge schedules directly from the API, plus a new sundry field indicating single-transaction posting. 👉 Beta details: https://releasenotes.rmscloud.com/rest-api-v10.26.266.6----beta-4zFBsY
• Transaction virtual card identification — Receipt transactions now indicate whether the card used is a virtual card. 👉 Beta details: https://releasenotes.rmscloud.com/rest-api-v10.26.266.6----beta-4zFBsY
• Reservation rate posted indicator — The full reservation object now shows whether the accommodation rate has been posted. 👉 Beta details: https://releasenotes.rmscloud.com/rest-api-v10.26.266.6----beta-4zFBsY
• Booking source grouping link — Booking sources now return a grouping identifier. 👉 Beta details: https://releasenotes.rmscloud.com/rest-api-v10.26.266.6----beta-4zFBsY
• Sundry audit trail logging fix — Sundries created via the API now record an audit trail entry, consistent with UI-created sundries. 👉 Beta details: https://releasenotes.rmscloud.com/rest-api-v10.26.266.6----beta-4zFBsY

Notes

• This release is now available in Live
• Release Date: September 29, 2026 (AEST) 
• Partners can begin using these changes in production immediately
• Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

Summary

This Beta release introduces a new endpoint for retrieving reservation repeat charge schedules, a way to brand RMSPay hosted payment pages with custom CSS, and several new fields across sundries, transactions, reservations, and booking sources. It also includes a fix for audit trail logging on API-created sundries. There are no breaking changes in this release.

New Features

RMSPay — Custom CSS Branding

You can now apply your own branding to the RMSPay hosted payment page by passing an optional cssCustomUrl field with a link to your own CSS file. This lets you style elements such as button and border colors to match your brand. Requests that omit the field continue to work exactly as before, with no change in behavior. RMS does not host, validate, or modify the CSS file — you're responsible for hosting it at a URL that's publicly accessible without authentication.

Endpoints affected:

• POST /guests/{id}/rmsPayPayment — accepts the new cssCustomUrl field
• POST /guests/{id}/rmsPayToken — accepts the new cssCustomUrl field
• POST /guests/{id}/rmsPayToken/preAuth/{resId} — accepts the new cssCustomUrl field

Repeat Charges — New Endpoint & Sundry Field

You can now retrieve repeat charge schedules directly from the API instead of relying on a database mirror. The new endpoint returns each schedule's amount, frequency, linked sundry and account, start/cutoff dates, and related settings for up to 1,000 reservation IDs per call. Reservations with no repeat charge schedule simply won't appear in the results. Alongside this, sundries now expose whether repeat charges using that sundry post as a single combined transaction rather than one per occurrence.

New endpoints:

• POST /reservations/repeatCharges/search — Retrieve repeat charge schedules for a list of reservation IDs

Endpoints affected:

• GET /sundries — now returns postSingleTransactionForRepeatCharges
• GET /sundries/{id} — now returns postSingleTransactionForRepeatCharges

Transactions — Virtual Card Identification

Receipt transactions now indicate whether the credit card token used for the receipt is flagged as a virtual card, regardless of whether the token came from an existing saved card or a new charge auto-tokenized by the payment gateway.

Endpoints affected:

• POST /transactions/search — now returns isVirtualCard
• GET /transactions/{id} — now returns isVirtualCard

Reservations — Rate Posted Indicator

The full reservation object now includes a boolean showing whether the accommodation rate has been posted for that reservation, so integrators can track rate postings ahead of guest arrival.

Endpoints affected:

• POST /reservations/search — now returns rateCreated (when modelType: full)
• GET /reservations/{id} — now returns rateCreated (when modelType: full)

Booking Sources — Grouping Link

Booking sources now return a grouping identifier, so you can tell which grouping a booking source belongs to without a separate lookup.

Endpoints affected:

• GET /bookingSources — now returns groupingId

Fixes & Improvements

Sundries — Audit Trail Logging

Creating a sundry via the REST API did not previously write an audit trail entry, unlike creating the same sundry through the RMS9+ UI, leaving no record of who created API-originated sundries. Creating a sundry through this endpoint now records an audit trail entry consistent with UI-created sundries.

Endpoint affected:

• POST /sundries — now writes an audit trail entry on creation

Notes

• This release is now available in Beta
• Release Date: September 29, 2026 (AEST) 
• Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

Summary

This Live release promotes the v10.26.202.1 Beta, which includes two bug fixes addressing reservation cancellation handling and owner record completeness for areas within interconnecting rooms.

Included in this Live release:

• Reservation Cancellation Fix — Resolved a 400 error when cancelling reservations where a cancellation policy rule had no sundry configured. 
• Interconnecting Room Owner Records Fix — Corrected incomplete owner history returned for individual areas within an interconnecting room. 
• 👉 Beta details: https://releasenotes.rmscloud.com/rest-api-v10.26.202.1----beta-R7c76

Notes

• This release is now available in Live
• Release Date: August 18, 2026 (AEST)
• Partners can begin using these changes in production immediately
• Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

Summary

This Beta release delivers two bug fixes: one resolving a reservation cancellation error when no sundry is configured on a cancellation policy rule, and one correcting incomplete owner records returned for areas within an interconnecting room.

Fixes & Improvements

Reservation Cancellation — 400 Error When No Sundry Configured

Fixed an issue where PUT /reservations/{id}/status returned a 400 error — "Cancellation Fee: no Sundry is configured on the Cancellation Rule or in Account Options" — when a cancellation policy rule was set up but no sundry had been configured. Reservations can now be cancelled successfully in this scenario. A cancellation charge will only be posted if the policy rule is met and a valid sundry is configured.

• Endpoint affected: PUT /reservations/{id}/status

Areas — Incomplete Owner Records for Interconnecting Rooms

Fixed an issue where GET /areas/{id}/owner returned incomplete owner records for areas that form part of an interconnecting room. Only the interconnecting (parent) area was returning the full owner history; the underlying individual areas returned only a single owner record. The endpoint now returns all applicable owner records for each area, including historical entries.

• Endpoint affected: GET /areas/{id}/owner

Notes

• Release Date: August 18, 2025 (AEST)— Beta only
• Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

You can now browse all your available accommodation, sites, and docks straight from search, without picking a type first. Category and map pages let guests filter by type as they go, and RV guests are only asked for boat or vehicle dimensions at the point of booking, not before. Results are grouped clearly by type, with availability status shown up front. This is designed to cut drop-off earlier in the search and lift booking conversion.

Room cards in IBE+ now display up to three key attributes (e.g. Ocean Facing, Air Conditioning, Washing Machine) configured at the category level, so guests can compare options without opening More Details, restoring parity with the previous booking engine.

If your property hasn't yet moved to a supported payment gateway on the new booking engine, that's no longer a reason to hold off migrating.

Guests can now complete checkout even without a gateway configured. Their card details are captured securely — not charged online — so you can process the payment manually later in RMS 9+, using your existing terminal or gateway.

This means you can migrate to the new booking engine now and start charging guests manually, rather than waiting for your gateway to be supported.

What to expect:

• No card payment or deposit is taken online in this mode, even if deposits are configured
• Card details are captured securely and passed through to RMS 9+
• Charge guests manually via your onsite terminal or gateway when you're ready

We've refreshed the category card in your booking engine to help guests scan options and book with more confidence. What's changed: Clearer pricing - pricing is now left-aligned and consistent across every rate scenario, with a rate description pop-up that matches the rate breakdown guests already know. Simpler content - updated icons, plain-language labels (like "2 People" instead of "Sleeps 2"), and a night count shown above each title so guests instantly see what they're looking at. A clearer call to action - the button now reads "Book now," with a "More Rates" option alongside it when a card offers more than one rate. Together, these changes make it faster for guests to understand what they're paying for and easier to take the next step toward booking.

Cancellation policies are now displayed accurately throughout the entire booking journey, respecting the hierarchy in which they are configured in the PMS.

Previously, the IBE did not consistently honour the cancellation policy hierarchy, meaning lower-level policies (such as those set at the Rate Type level) could display even when a higher-level policy had been configured to override them. This affected the rates page, the confirmation page, and the confirmation email.

The IBE now correctly applies the following hierarchy, with higher-level policies always taking precedence:

1. Control Panel
2. Rate Table
3. Rate Period
4. Rate Type Property Rule
5. Derived Rate Type
6. Rate Type

Guests will now see the correct cancellation policy at every step — from browsing rates through to their confirmation email.

Rates that cannot be booked due to restrictions are now displayed on the booking engine rather than hidden, giving guests full visibility of all available rate options for a room or category.

Previously, restricted rates were removed from the results entirely, leaving guests to assume a rate didn't exist rather than understanding why it was unavailable. This could lead to unnecessary drop-off or guests booking elsewhere.

Restricted rates now appear greyed out with the "Book Now" button disabled and a clear inline label explaining the restriction. The following restriction types are covered:

• Closed to Arrival — "Can't arrive on [days]"
• Closed to Departure — "Can't depart on [date/days]"
• Minimum Length of Stay — "[X] Night Minimum"
• Maximum Length of Stay — "[X] Night Max" (shown as an informational label even when the rate is still bookable, and as a restriction when the stay exceeds the limit)

Guests can use these messages to understand what date adjustments are needed to access a rate, reducing confusion and improving booking confidence.