We've resolved an issue where the price displayed on the results screen did not match the price shown in the cart when a guest searched for more people than a category's maximum occupancy allows.

Previously, the displayed rate was calculated using the full guest count entered in the search, while the cart recalculated the price based on the category's maximum occupancy — resulting in a price drop between the two screens, which could cause confusion or distrust for guests at checkout.

The displayed rate now caps at the category's maximum occupancy, ensuring the price a guest sees on the results screen is always consistent with what appears in their cart.

Cancellation policies are now displayed accurately throughout the entire booking journey, respecting the hierarchy in which they are configured in the PMS.

Previously, the IBE did not consistently honour the cancellation policy hierarchy, meaning lower-level policies (such as those set at the Rate Type level) could display even when a higher-level policy had been configured to override them. This affected the rates page, the confirmation page, and the confirmation email.

The IBE now correctly applies the following hierarchy, with higher-level policies always taking precedence:

1. Control Panel
2. Rate Table
3. Rate Period
4. Rate Type Property Rule
5. Derived Rate Type
6. Rate Type

Guests will now see the correct cancellation policy at every step — from browsing rates through to their confirmation email.

Summary

This release fixes two issues with GET /properties/{id}/discounts where the endpoint was returning duplicate discount records and discount records that are no longer active in the system. The endpoint now returns only valid, configured discounts for the property.

Fixes & Improvements

Property Discounts — Duplicate and Removed Records Returned

GET /properties/{id}/discounts had two issues that caused it to return incorrect records:

• Duplicate records — the same discount could appear multiple times in the response.
• Removed records — discounts that are no longer active in the system were still being included in the response.

The endpoint now returns only valid discounts configured against the property, with each discount appearing once. Note that expired discounts continue to be returned, as these remain valid configured discount records until explicitly removed or deactivated.

• Endpoint affected: GET /properties/{id}/discounts 

Notes

• This release is now available in Beta & Live
• Release Date: 15 July 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 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 Live release delivers two fixes to reservation tariff handling. Properties using Nightly Rate accounting will now see correct per-night tariff records from API-created reservations, and pencil reservations will correctly recalculate tariffs when the rate type is updated more than once.

Included in this Live release:

• Reservations — Nightly Rate accounting — API-created reservations now generate per-night tariff records when the property is configured for Nightly Rate accounting. 
• Reservations — Pencil reservation tariff recalculation — Tariff values now recalculate correctly on every rate type change, not just the first assignment.

👉 Beta details: https://releasenotes.rmscloud.com/rest-api-v10.26.167.3----beta-20B5m0?psig=Mpx7z7vJgO61MKzP9abenS5geFulmT0aAI2Nubz

Notes

• This release is now available in Live
• Release Date: 24 June 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 fixes to reservation tariff behavior. Reservations created via the API now correctly inherit the property-level Nightly Rate accounting configuration, and rate type changes on pencil reservations now trigger a full tariff recalculation in all cases. 

Fixes & Improvements

Reservations — Nightly Rate accounting now applied correctly on creation

When a property was configured to use Nightly Rate from their accounting configuration, reservations created through the API were incorrectly generating a single total tariff for the entire stay rather than individual nightly tariffs. The API now correctly inherits the property-level accounting configuration.

Affected endpoint: POST /reservations

Reservations — Tariff recalculation on pencil reservation rate type change

When updating a pencil reservation's rateTypeId via PATCH /reservations/{id}, the tariff was only recalculated the first time a rate was assigned. If the rate was subsequently changed to a different rate type, the baseRate and totalRate values in actualAccount retained the original rate's amounts instead of reflecting the new rate. The recalculation logic now triggers whenever the rate type changes to a different value, covering both first-time assignment and subsequent rate changes.

Affected endpoint: PATCH /reservations/{id}

Notes

• Release Date: 23 June 2026 (AEST)  — Beta only
• Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

Summary

This Live release delivers error handling and data accuracy improvements across the API, covering webhooks, transactions, discounts, and reports.

Included in this Live release:

• Webhooks — Fixed 500 error on PUT /webhooks/{id} for inactive or non-existent webhook IDs; endpoint now returns 404 Not Found.
• Transactions — Credit card fee values submitted via POST /transactions/receipt are now rounded to 2 decimal places, preventing account balance mismatches and refund processing errors.
• Reservations — POST /reservations/discounts/search now correctly returns discounts with validation rules applied, instead of returning 204 No Content.
• Reports — POST /reports/auditTrail no longer returns a 500 error when glCodeIds is passed as an empty array.

👉 Beta details: https://releasenotes.rmscloud.com/rest-api-v10.26.118.1----beta-3CuvTy

Notes

• This release is now available in Live
• Release Date: 3 June 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 four fixes addressing error handling and data accuracy improvements across the API. Partners are encouraged to test the affected endpoints ahead of the Live release.

Fixes & Improvements

Webhooks — PUT /webhooks/{id} Returns 500 for Inactive Webhooks

Calling PUT /webhooks/{id} with an inactive or non-existent webhook ID was incorrectly returning a 500 Internal Server Error instead of a meaningful error response. This has been fixed. The endpoint now returns 404 Not Found in these cases, allowing integrators to handle the response appropriately.

• Endpoint affected: PUT /webhooks/{id}

Transactions — Credit Card Fee Rounding via POST /transactions/receipt

When a credit card fee was submitted via POST /transactions/receipt with more than 2 decimal places (e.g. 0.9608), the value was stored as-is in RMS. This caused a rounding mismatch on the account balance, which prevented users from processing valid refunds — the system would reject a refund that appeared within the available credit balance because the stored fee value didn't align to standard 2-decimal currency precision.

This has been fixed. Credit card fee values are now rounded to 2 decimal places at the point of storage, ensuring account balances are calculated correctly and refunds can be processed without errors.

This fix affects any integration using POST /transactions/receipt that submits credit card fee values with more than 2 decimal places.

• Endpoint affected: POST /transactions/receipt

Reservations — Discounts with Validation Rules Return 204 in POST /reservations/discounts/search

POST /reservations/discounts/search was returning 204 No Content for discounts that had validation rules applied (e.g. date made ranges, stay date ranges), even when the search criteria matched those rules. Discounts without validation rules were unaffected.

This has been fixed. The endpoint now returns all eligible discounts, including those with validation options configured, provided the request parameters fall within the defined rules.

• Endpoint affected: POST /reservations/discounts/search

Reports — POST /reports/auditTrail Returns 500 Internal Server Error

Calling POST /reports/auditTrail with an empty glCodeIds array was causing a 500 Internal Server Error. This affected all requests regardless of other parameters supplied.

This has been fixed. The endpoint now returns audit trail data without filtering by GL code when glCodeIds is passed as an empty array.

• Endpoint affected: POST /reports/auditTrail

Notes

• Release Date: June 02, 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

Resolved an issue where reservations created through IBE+ were being assigned check-in and check-out times from the property level, even when specific times had been configured at the category level.

IBE+ will now correctly honour category-level times where they have been set, falling back to property-level times only when no category-level configuration exists. This applies to both standard night bookings and day use bookings.

Traces are inter- or intra-departmental notes used to communicate or delegate tasks across various areas of the system, including the To Do Chart, Area, Reservation, Company, Travel Agent, Guest, and Groups.

When creating a Trace for an Allotment which is specific to a certain property, the trace is displaying for all properties on their To Do Chart. This has been resolved.

Help Article