Following a recent security incident, two temporary restrictions are in place on the RMS REST API.

1. SwaggerHub testing temporarily unavailable

The Try it out function in SwaggerHub is currently unavailable due to security restrictions. You can continue testing API requests from your own servers or fixed office IP addresses using tools such as cURL or Postman. The API documentation remains available in SwaggerHub.

2. Temporary rate limit change for /guest* endpoints

Effective 26 October 2026, the rate limit for /guest* endpoints was reduced from 150 to 50 requests per minute per IP address. No other REST API endpoint rate limits were changed. We will update it once the original limit is reinstated.

Where to find updates

• Updates on these restrictions will be posted at https://releasenotes.rmscloud.com/
• Updates on the incident itself will be posted on the RMS Status Page.

We apologize for the inconvenience and appreciate your understanding.

Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

Summary

This release adds appliesFrom and appliesTo to the transaction response. Each transaction now returns the dates its charge applies to.

Enhancement

Transactions - appliesFrom and appliesTo

Each transaction now returns the dates its charge applies to. Use these properties to allocate a charge to the dates it applies to, for example when reporting by night, instead of relying on the posting date (dateOfTransaction or accountingDate). The posting dates are unchanged.

• appliesFrom is the first date the charge applies to and appliesTo is the last. A one-night charge has both properties equal to that night.
• Nightly reservations: each tariff transaction covers one night, so appliesFrom and appliesTo are the same date.
• Charges covering a date range: the stored first and last dates are returned. An airport transfer charged for 6 to 10 Oct returns 2026-10-06 and 2026-10-10. Hourly rates include the time.
• No dates set: both properties return 1900-01-01 00:00:00. Treat this value as “no dates set for this charge”.
• The dates can fall before or after the posting dates. For example, a package set up to post on the next day posts its charge on 8 Oct, and the charge applies to 7 Oct.
• Transactions created by void, reverse, or transfer processes copy the dates from the original transaction.

Both properties are response only and use the format yyyy-MM-dd HH:mm:ss. Existing properties, request models, and paging are unchanged. 

Endpoints returning the new properties:

• POST /transactions/search - Returns appliesFrom and appliesTo on each transaction. Swagger documentation
• GET /transactions/{id} - Returns appliesFrom and appliesTo for the transaction. Swagger documentation

Notes

• This release is available in both Beta and Live 
• Release Date: October 20th, 2026 (AEST) 
• Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

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

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

Summary

This Live release delivers enhancements to reservation requirement responses, a new guest image upload endpoint, full CRUD support for Requirement Category Access, and a fix for a 503 error on reservation search by guest surname.

Included in this Live release:

• Reservation Requirements — chargeRequiredDaily and chargeDailyIncludeToDate fields added to requirement responses, enabling accurate fee calculation in kiosk and self-check-in flows.
• Guest Image Upload — New PUT /guests/{id}/image endpoint allows guest images to be uploaded directly via the API.
• Requirement Category Access — New endpoints to get, add, replace, and remove category access entries on master Requirements.
• Reservation Search Fix — POST /reservations/search no longer returns a 503 when filtering by guest surname.

👉 Beta details: https://releasenotes.rmscloud.com/rest-api-v10.26.191.2----beta-1Ph3uE

Notes

• This release is now available in Live
• Release Date: July 14, 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 adds new fields to reservation requirement responses, a new endpoint for uploading guest images, and a new set of endpoints for managing Requirement Category Access. It also includes a fix for a 503 error returned by POST /reservations/search when filtering by guest surname. 

New Features

Reservation Requirements — chargeRequiredDaily and chargeDailyIncludeToDate Fields

Two new boolean fields have been added to reservation-level requirement responses. chargeRequiredDaily indicates whether a requirement is charged on a per-day basis; chargeDailyIncludeToDate controls whether the departure date is included in that daily charge calculation. These fields allow integrators to accurately calculate requirement fees without relying on additional lookups or UI-side logic.

Endpoints affected:

• GET /reservations/{id}/requirements — Returns requirements for a reservation, now including chargeRequiredDaily and chargeDailyIncludeToDate
• GET /reservations/requirements — Search reservation requirements, now including chargeRequiredDaily and chargeDailyIncludeToDate

Guest Image Upload — New Endpoint

Integrators can now upload an image (such as a passport or ID document scan) directly to a guest profile via the REST API. Previously this was only possible through the RMS UI.

New endpoint:

• PUT /guests/{id}/image — Upload an image to a guest profile

Requirement Category Access — New Endpoints

A new set of endpoints enables integrators to manage Category Access on master Requirements. Category Access controls which property categories a Requirement appears in, using an allow-list model. This gives integrators programmatic control over Requirement visibility across a multi-category property setup, without requiring manual configuration in the RMS UI.

New endpoints:

• GET /requirements/master/{id}/categoryAccess — Retrieve the category access list for a master Requirement
• POST /requirements/master/{id}/categoryAccess — Add categories to the access list for a master Requirement
• PUT /requirements/master/{id}/categoryAccess — Replace the category access list for a master Requirement
• DELETE /requirements/master/{id}/categoryAccess — Remove categories from the access list for a master Requirement

Fixes 

Reservation Search — 503 Error When Filtering by Guest Surname

POST /reservations/search was returning a 503 Service Unavailable error when the request included a guestSurname filter. The endpoint now returns a valid result set, or an empty array when no matches are found.

Notes

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