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 delivers stability fixes from the September 3 Beta cycle: resolving a timeout on the Debtors Ledger report and correcting a configuration retrieval error affecting PABX integrations.

Included in this Live release:

• Debtors Ledger Report — Fixed a timeout that could prevent the report from completing. 👉 Beta details: https://releasenotes.rmscloud.com/rest-api-v10.26.227.1----beta-28DD1u
• MFI PABX Configuration — Fixed an error that could interrupt configuration retrieval for PABX integrations. 👉 Beta details: https://releasenotes.rmscloud.com/rest-api-v10.26.227.1----beta-28DD1u

Notes

• This release is now available in Live
• Release Date: September 3, 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 stability fixes: resolving a timeout on the Debtors Ledger report, and correcting an endpoint error affecting PABX configuration retrieval for MFI integrations. No new endpoints, fields, or breaking changes are included.

Fixes & Improvements

Debtors Ledger Report — Timeout Resolved

Some calls to the Debtors Ledger report were failing to complete and returning a timeout error rather than the report data. This is now resolved; the endpoint returns the full report as expected.

• Endpoint affected: POST /reports/debtorsLedger

MFI PABX Configuration — Configuration Retrieval Fixed

An internal error could prevent PABX configuration data (transaction method, and accounting system date) from being retrieved for properties using the MFI PABX integration, which could interrupt call logging, transaction creation, and related billing operations. This is now resolved.

Notes

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

We fixed an issue where a promo code that excludes a package could show a lower total in search results, then add that cost back in once the booking was added to the cart. Guests now see a consistent, accurate total the whole way from search to checkout.

We have released an update to the RMS Stripe app (version 0.0.8) that resolves an issue where some properties using the RMS Stripe integration were receiving a "permission denied" error when creating a token or processing payments. The error was caused by incorrect API permissions in the RMS Stripe app, which prevented certain payment operations from completing. This has now been corrected. Action required: To complete the update, you will need to log in to your Stripe Dashboard. Once logged in, Stripe will present you with a re-consent prompt asking you to approve the updated app permissions. Please review and accept these permissions to restore full functionality. This is a standard Stripe security step — it ensures you have visibility and control over any changes to the permissions granted to third-party apps connected to your account. Customers will then have to recreate a new restricted key that will have the new permissions applied. Once you have approved the updated permissions, no further action is required. If you do not see the re-consent prompt or continue to experience issues with your Stripe connection, please contact our support team.Customers will then have to navigate to RMS>Setup/PropertyOptions/PropertyInformation>Property Set Up>Payment Gateway and select Copy Stripe Keys.

Resolved an issue where a CC token description entered immediately after token creation was not being saved. Users were required to exit and reopen the CC Token screen before the description field would persist values correctly.

When a vault token is created the token will be stored with the 'date to remove' set at the departure date of the reservation. If the reservations departure date is changed to a future date the 'date to remove' will be updated. If the reservations departure date is changed to a later date the 'date to remove' will not be changed. If a departure date fails to pass through on amendment the system will update the 'date to remove' to be current + 2 years as a fail safe. Vault tokens are then removed from use +14 days from the 'date to remove'.

Fixed an issue where Purchase and Conversion tracking dropped off when a guest paid with a 3DS-verified card. Tracking parameters now persist through the card issuer's authentication redirect, so conversions are recorded correctly.

Guests booking a Site (RV, motorhome, caravan) now see their selected vehicle Type and Length on the booking confirmation page, in the confirmation email, and in the reservation record - so the details they booked with are the details on file.