The new Owner Portal Pro is now available to all Trust and Owner Accounting customers.

This release introduces a redesigned Owner Portal, with a modern, mobile-friendly design. It's designed to make it even easier for owners to check their revenue, bookings and statements straight from their phone.

What's new? 

• Brand new UX, with a modern, mobile-first experience across desktop, tablet and mobile.
• Redesigned dashboard, improving visibility into owner revenue, reservations, statements and invoices.
• Removed the need to regenerate statements on request, with owner statements now stored and accessible for up to 3 years. 

What's different to the legacy Owner Portal? 

• The message centre is not included in this release. 
• Settings are now managed automatically, removing the need for manual configuration. 

Access

• Included at no additional cost for all Owner and Trust Accounting customers. No setup required.
• Existing owners keep their current login - only the portal URL changes.
• New owners are set up the same way as before: create their profile in RMS, verify their email, and set an Online Password.

Migration

• Migration to the new portal is mandatory.
• The old portal will be retired on 15 November. There is no rollback after this date.
• The old portal will redirect to the new portal URL 

🔗 View a tour of the Owner Portal Pro here.

🔗 View the Help Centre content here.  

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

We now have the ability to create a map with multi-location waypoints, to enable guests browsing a split-site property (multiple park areas under one listing) to see on-map indicators pointing to the other areas, making it clear these are separate locations they can jump between

We've made two improvements to the booking engine that give guests a smoother, more intuitive search experience.

Simplified search results
Guests no longer need to select a category type before seeing results. All available options are now returned on the initial search, allowing guests to browse everything first and filter down using the new pill selectors at the top of the results page — choosing between accommodation or site based on what suits them.

For site bookings that require mandatory details, guests can complete these via the pill selector or will be prompted when they proceed to book — keeping the journey moving rather than creating a barrier upfront.

Colour-coded interactive map
The interactive map now uses distinct colours to differentiate category classification types, making it easy for guests to identify accommodation and site options at a glance.

Together, these changes reduce friction early in the booking journey and help move guests more confidently through to completion.

Dock and berth categories are now visible and bookable through the booking engine again, shown alongside accommodation and sites. Where a property offers multiple category types online, guests get a dock/berth filter option consistent with how other category types display.

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.

IBE+ now correctly reads and applies the same booking URL parameters supported by the current IBE, including guest/pet counts, lead days and minimum length of stay, so existing deep links continue to work as expected.

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

Available from: 22 July 2026

What's New

A new Invoice To field is now available on the Reservation Account screen, allowing you to specify the person or entity receiving services separately from the person or entity paying or receiving the invoice.

This is particularly useful for properties that need to issue invoices to a service recipient for GST/VAT claims, while billing a different party.

How It Works

• Bill To — the person or entity paying or receiving the invoice (unchanged from current behaviour)
• Invoice To — the person or entity receiving the services from the property

The Invoice To field:

• Defaults to the same entity as Bill To (no action required if both are the same)
• Can be changed independently to a different Guest, Company, or Travel Agent
• Appears directly beneath the Bill To drop downs on the Reservation Account screen
• Once set, it is retained even if Bill To is subsequently changed
• Drives the recipient details shown on generated invoices (Tax Invoice, Statement, Grouped Tax Invoice, Receipt, Refund, and Print Transaction)

Example Scenarios

What You Need to Know

• No configuration is required — the field is available automatically on the Reservation Account screen
• Existing reservations will default Invoice To to the current Bill To value
• If you do not change Invoice To, your invoicing behaviour remains exactly as it is today
• Generated invoices will reflect the Invoice To entity as the recipient

Who Benefits

Properties operating in regions with GST/VAT requirements where the payer and the legal service recipient may differ — ensuring compliant invoices can be issued to the correct party for tax claims.

Click here to read more in our help articles