Summary

This release introduces a platform-wide maximum record limit of 50,000 across all REST API endpoints that accept a limit parameter. Requests exceeding this value will now return HTTP 400 Bad Request. Previously, oversized requests were silently truncated.

Partners using high-volume search queries should review the affected endpoints below and update their integrations before the Live release.

Breaking Change

Global Maximum Query Limit — 50,000 Records

The following endpoints are affected:

• POST /transactions/allocations/search
• POST /transactions/search
• POST /guests/search
• POST /reservations/search

What's changing:

• Requests with a limit value above 50,000 will return HTTP 400 Bad Request with an explicit error message
• Requests at or below 50,000 are unaffected
• Endpoints that already have their own explicit limit lower than 50,000 are unaffected

Action required: If your integration passes a limit value greater than 50,000 on any of the above endpoints, you will need to update your queries to use pagination or reduce the limit before the Live release. Partners identified as impacted have been contacted directly.

Notes

• Available in Beta only. Live release is tentatively scheduled for 2 June 2026, subject to Beta validation.
• Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

Summary

This Beta release introduces three new feature areas — guest classifications, company branch offices, and headless payment tokenisation — along with a platform-wide query limit change. Partners using high-volume search endpoints should review the Breaking Change section below ahead of Live.

New Features

Guest Classifications — New Endpoints

New endpoints have been added to support full management of guest classifications, enabling retrieval, assignment, replacement, and removal of classifications on a guest record.

New endpoints:

• GET /guestClassifications — Retrieve available classification types
• GET /guests/{id}/classifications — Get classifications assigned to a guest
• POST /guests/{id}/classifications — Add a classification to a guest
• PUT /guests/{id}/classifications — Replace the full classification set for a guest
• DELETE /guests/{id}/classifications/{classificationId} — Remove a specific classification from a guest

Company Branch Offices — New Endpoints

New endpoints have been added to support programmatic management of branch office relationships between company records. This removes the need to maintain these links manually in the RMS UI.

When adding branch offices, you can optionally copy all assigned rates from the master company to each branch office at the time of creation by passing "assignParentRates": true. Note: rate copying occurs at creation time only and does not establish an ongoing sync.

New endpoints:

• POST /companies/{parentId}/branchOffices — Link one or more companies as branch offices of a master company
• GET /companies/{parentId}/branchOffices — Retrieve all branch offices for a master company
• DELETE /companies/{parentId}/branchOffices/{companyId} — Remove a branch office link

Credit Card Tokenisation — merchantReference Field

POST /guests/{id}/creditCard now accepts an optional merchantReference field. This integrator-supplied string (max 100 characters) is stored at token creation time and acts as the lookup key when retrieving token details via searchGuestRmsPayToken.

This enables fully headless payment flows — for example, AI voice agents collecting card details over the phone — to complete the rmsPay flow without requiring any UI interaction from the guest.

• Endpoint affected: POST /guests/{id}/creditCard

Note: RMS does not enforce uniqueness on merchantReference. The integrator is responsible for managing reference values.

⚠️ Breaking Change — Global Maximum Query Limit: 50,000 Records

A global maximum record limit of 50,000 is being introduced across all REST API endpoints that accept a limit parameter. Previously, requests with limits up to 1,000,000 were accepted and silently truncated. From this release, any request exceeding 50,000 will return HTTP 400 Bad Request.

Affected endpoints:

• POST /transactions/allocations/search
• POST /transactions/search
• POST /guests/search
• POST /reservations/search

Action required: If your integration currently requests more than 50,000 records in a single call on any of the above endpoints, you will need to reduce your limit value or implement pagination before this change reaches Live. Partners identified as using limits above 50,000 have been contacted directly.

Endpoints with an existing explicit limit lower than 50,000 are unaffected.

Notes

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

Summary

This Beta release includes two fixes and one new feature enhancement. Partners are encouraged to validate these changes in Beta and report any issues via standard support channels.

New Features

Guest Classifications — New Endpoints

New endpoints have been added to support full management of guest classifications, enabling retrieval, assignment, replacement, and removal of classifications on a guest record. 

New endpoints:

• GET /guestClassifications — Retrieve available classification types SwaggerHub ↗
• GET /guests/{id}/classifications — Get classifications assigned to a guest SwaggerHub ↗
• POST /guests/{id}/classifications — Add a classification to a guest SwaggerHub ↗
• PUT /guests/{id}/classifications — Replace the full classification set for a guest SwaggerHub ↗
• DELETE /guests/{id}/classifications/{classificationId} — Remove a specific classification from a guest SwaggerHub ↗

Fixes & Improvements

Pencil Reservation — Dynamic Pricing Rate Consistency

• Issue: When a rate type was applied to a pencil reservation via the API, the quoted rate was not being preserved. If dynamic pricing changed before the pencil was converted to Unconfirmed/Confirmed, the reservation would be re-quoted at the new rate — producing a different rate than originally presented to the guest.
• Fix: Applying a rate type to a pencil reservation via the API now correctly preserves the quoted rate and occupancy snapshot. The rate will be retained when the pencil is subsequently converted.
• Endpoints affected: PATCH /reservations/{id}, PUT /reservations/{id}/status

Reservation Hold — 404 Error on Create

• Issue: When creating a new reservation hold via the API, a 404 Not Found error was returned despite the hold record being successfully created.
• Fix: POST /reservations/{id}/holds now returns the correct 200 OK response with the hold record payload upon successful creation.
• Endpoint: POST /reservations/{id}/holds

Notes

• Release Date: April 8, 2026 Beta only
• Dependencies: None
• There is no impact to Live environments.
• Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

Summary

This Beta release includes one enhancement to company and travel agent note management via the API. Partners are encouraged to validate this change in Beta and report any issues via standard support channels.

New Features

Company & Travel Agent Notes — All Properties Support

The API now supports creating and updating notes scoped to All Properties for both company and travel agent records, by passing propertyId: 0 in POST and PUT requests. This aligns API behaviour with what is already possible in the RMS UI.

Previously, propertyId: 0 was rejected by the API, requiring notes to be managed on a per-property basis only.

Additionally, validation has been added to PUT requests to ensure the propertyId in the request matches the existing note's scope. Attempting to update an All Properties note with a specific property ID (or vice versa) will return a 400 error.

Endpoints affected:

• POST /companies/{id}/notes — SwaggerHub ↗
• PUT /companies/{id}/notes/{noteId} — SwaggerHub ↗
• POST /travelAgents/{id}/notes — SwaggerHub ↗
• PUT /travelAgents/{id}/notes/{noteId} — SwaggerHub ↗

Note: Using propertyId: 0 creates a note that applies across all properties the token has access to. API users should be intentional when using this scope — if your integration does not have access to all properties, use property-specific notes instead.

Notes

• Release Date: March 25, 2026  Beta only
• Dependencies: None
• There is no impact to Live environments.
• Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

Summary

This Beta release includes two fixes. Partners are encouraged to validate these changes in Beta and report any issues via standard support channels.

Fixes & Improvements

NPS Results Report — 500 Error Resolved

• Issue: A 500 error was being returned for the reports/npsResults endpoint in Beta and Test environments.
• Fix: The endpoint no longer returns a 500 error and now processes requests as expected.
• Endpoint: POST /reports/npsResults — SwaggerHub ↗
• Note: This issue was environment-specific and had no impact on Live environments.

Transaction Receipt — Incorrect HTTP Status for Transient Errors

• Issue: When a transient database error occurred during payment processing, the API was returning a 400 Bad Request response. This incorrectly signalled a client-side validation error, causing payment workflows to fail rather than retry the request.
• Fix: Transient errors of this nature now return a 503 Service Unavailable response, correctly signalling to clients that the request should be retried.
• Endpoint: POST /transactions/receipt — SwaggerHub ↗
• Note: Partners should ensure their integration retries on 503 responses where applicable.

Notes

• Release Date: March 11, 2026 Beta only
• Dependencies: None
• There is no impact to Live environments.
• Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

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

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