We’ve fixed an issue where derived-from-derived rate types that include additional person pricing were not calculating correctly.

Previously, when a rate type was derived from another derived rate and configured to adjust additionals, the system reused the original additional amount for both adjustment levels. This could cause the final price (e.g. for 3 adults) to be under-calculated in Quick Quote and when creating a reservation and posting tariff.

Summary

We have rolled back the REST API Live version for Australia-based customers only to address an issue affecting reservation workflow endpoints.
The Live environment in AUS is now running v10.25.319.113. A release note will be published once the fixed version is available.

If you require access to the latest fixes and improvements in the meantime, please use the Beta environment.

Reference Live release:
https://releasenotes.rmscloud.com/rest-api-v10.26.19.2---live-2kTXfG

What happened

Following the Live deployment, an issue was identified that impacted a small number of customers in Australia.
This was related to backend database changes for a limited set of properties, where the API was not yet fully aligned with the updated environment.

To minimize disruption and restore stability, we have rolled back the Live API version for AUS-based customers only to the previous stable release.

Impact

• Scope: Limited to a small number of customers in Australia
• Affected functionality: Reservation workflow endpoints
• Current Live version for AUS: 10.25.319.113
• No action is required from partners at this time
• API behavior has returned to the previous stable state for impacted customers

What’s next

• A fix will be validated before a future Live release is scheduled.
• A release note will be published when the fixed version is deployed
• Partners who need access to the latest fixes and improvements should continue using Beta in the interim

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

Summary

This Live release brings together the improvements and fixes previously delivered across the Beta cycle, with a focus on availability and rate calculation workflows, guest correspondence support, and reservation reliability.

Included in this Live release:

• Availability & Rate Calculation Enhancements
  Improvements to availability and rate calculation workflows, along with new API support for managing guest correspondence notes.
  👉 Beta details: https://releasenotes.rmscloud.com/rest-api-v10.26.10.1----beta-3ECvn2
• Reservation Workflow Fixes & Stability Improvements
  Fixes to reservation creation and update workflows, ensuring rate-based configuration fields are correctly applied and resolving timeout issues when overriding rates.
  👉 Beta details: https://releasenotes.rmscloud.com/rest-api-v10.26.19.2----beta-1eL7Q4

Notes

• This release is now available in Live
• Release Date: February 11, 2026 (AEDT)
• 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 includes a fix for an issue impacting the reports/npsResults endpoint in the Beta environment, where a 500 error was being returned. Partners are encouraged to validate this fix in Beta and report any issues via standard support channels.

Fixes & Improvements

NPS Results Report Endpoint

• Issue: A 500 error was being returned for the reports/npsResults endpoint in Beta.
• Fix: The endpoint no longer returns a 500 error and now processes requests as expected.

Endpoint:
POST/reports/npsResults
https://app.swaggerhub.com/apis-docs/RMSHospitality/RMS_REST_API/1.4.43.1#/reports/npsResultsReport

Notes

• Release Date: February 11, 2026 (AEDT) 
• This issue was environment-related and has been resolved in Beta.
• There is no impact to Live environments.
• Please report any issues through standard support channels:
  https://rmsapi.zendesk.com/hc/en-gb/requests

Important Notice: API Rate Limit Updates

We’re introducing new global rate limits for a set of Group Allotment and reference data REST API endpoints (including Companies and Travel Agents).

These endpoints return low‑change data and are intended to be used with caching and webhooks, rather than continuous polling. The changes below are designed to improve platform stability and ensure consistent performance for all partners.

Why this change is being made

We’ve observed sustained high‑volume polling on several Group Allotment endpoints that return low‑change data. In most cases, these resources are expected to be:

• Cached after initial retrieval
• Refreshed only when changes occur via webhook notifications

Continuous polling creates unnecessary load and can impact overall platform performance.

What’s changing (Effective Date: February 23, 2026)

The following endpoints will be limited to 60 requests per minute:

• GET /groupAllotments
• GET /groupAllotments/{id}
• GET /groupAllotments/{id}/allotments
• GET /groupAllotments/{id}/companies
• GET /groupAllotments/{id}/travelAgents
• GET /companies
• GET /travelAgents

Webhooks (recommended approach)

Webhooks should be used as the primary mechanism for detecting changes:

Group Allotments

• Events: create, update, delete
• Payload includes groupAllotmentId, which can be used to re‑query the specific resource if needed

Agents

• Events: create, update
• Payload includes agentId for retrieving updated agent details

Using webhooks avoids unnecessary polling and ensures updates are processed only when changes occur.

Webhook schema:
Webhooks

What you need to do

• Cache responses from the affected endpoints
• Use webhooks to detect changes
• Re‑query only the affected resource when a webhook event is received
• Avoid continuous polling
• Ensure any manual refreshes stay within the new rate limits

Enforcement

• Rate limits are applied globally
• Sustained traffic above the limits may be throttled or blocked

Need help?

If you have questions or would like assistance reviewing your implementation, please contact API Support:
Partner & API Support

Property is using Associated Rooms to get best value out of renting out apartments at the property. When the apartment is no longer able to be rented out, there is no way of removing the association. 

Help article

Automatic Check-out will prompt users exiting an account on the departure date with the option to update the Reservation Status.

an issue was identified where this functionality was not working if the check out time was prior to 9am

We’re pleased to confirm that the issue affecting the Credit Card Token Details window has now been resolved.

This was a UI issue that occurred only for specific properties. While the credit card information was still visible when clicking the token, the details window would not open when selecting ‘View Token’ or double-clicking the token.

You should now be able to:

Select ‘View Token’, or

Double-click on the credit card token

and the Credit Card Token Details window will open as expected.

Issue Summary When a same-day room move occurred for a reservation that had already arrived, RMS was not triggering the expected webhook events for updated area.cleanStatus values. Specifically: The previous area did not trigger a vacantDirty webhook The new area did not trigger an occupied webhook This resulted in housekeeping status discrepancies between RMS and integrated partner systems. Impact Integrated housekeeping platforms did not receive updated room status events Led to out-of-sync housekeeping data, incorrect room allocations, delayed cleaning, and operational inconsistencies Affected partners and customers relying on RMS webhook events to maintain accurate room status workflows Resolution Webhook events are now correctly raised when a same-day room move occurs for an arrived reservation. The following events will now be sent as expected: vacantDirty webhook for the previous area occupied webhook for the new area This ensures housekeeping systems remain synchronized with RMS room status changes. Notes Applies to same-day room move scenarios for arrived reservations Partners using area statusModification webhooks should no longer experience missed events Please report any unexpected behaviour via standard support channels

Summary

This Beta release includes fixes to reservation creation and update workflows, ensuring rate-based configuration fields are correctly applied and resolving timeout issues when overriding rates. Partners are encouraged to validate these updates and provide feedback ahead of the Live release.

Fixes & Improvements

Group Reservation Rate Type Field Population

Issue
When creating group reservations via the REST API, fields associated with the selected Rate Type were not being populated, even though the same Rate Type correctly populated these fields in other reservation workflows.

Fix
All applicable fields are now correctly auto-populated from the Rate Type configuration when creating group reservations via the API.

The following fields are now applied as expected:

• Booking Source
• Market Segment
• Sub-Market Segment
• Meal Plan
• Cancellation Policy
• Rate Element
• Travel Agent
• Discount

Endpoint
POST /reservations/group
https://app.swaggerhub.com/apis-docs/RMSHospitality/RMS_REST_API/1.4.43.1#/reservations/addReservationGroup

Reservation Rate Override Timeout

Issue
Including either baseRateOverride or totalRateOverride in a PATCH /reservations request resulted in a 524 timeout error.

Fix
Requests including baseRateOverride and/or totalRateOverride now return 200 responses and update rates according to the intended behavior.

Endpoint
PATCH /reservations
https://app.swaggerhub.com/apis-docs/RMSHospitality/RMS_REST_API/1.4.43.1#/reservations/updateReservations

Notes

• Available in Beta only
• Live release scheduled for February 9, subject to feedback
• Partners are encouraged to test and provide feedback ahead of the Live release
• Please report issues through standard support channels