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

The IBE search results page now has three distinct sections instead of two.
Previously, a category was either available or unavailable. Now, a third section - "Available, but doesn't match your search" - appears between them. This highlights categories that have rooms or sites free for your dates, but can't be booked with the current search criteria.
Guests will see a clear explanation on each card, such as:

A minimum length of stay requirement they haven't met
A guest count that exceeds the category's capacity

This removes the guesswork for your guests and reduces abandoned bookings caused by unclear availability messaging. The change applies across both the rates view and map view.

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 Live release enforces a maximum record limit of 50,000 on key search endpoints. The change improves platform stability and ensures consistent behavior across high-volume query patterns. Requests exceeding the limit now return HTTP 400 Bad Request rather than being silently truncated.

Included in this Live release:

• Breaking Change: Maximum Query Limit — A cap of 50,000 records is now enforced on transaction, guest, and reservation search endpoints; requests exceeding this value return HTTP 400 Bad Request.
  👉 Breaking Change Details: https://releasenotes.rmscloud.com/rest-api-v10.26.105.2----beta-only-breaking-change---maximum-query-limit-4CTw1q
• Beta release: 👉 https://releasenotes.rmscloud.com/rest-api-v10.26.105.2----beta-4BL7va

Notes

• This release is now available in Live
• Release Date: 2 June 2026 (AEST)
• Partner notification sent 17 April 2026: https://mail.rmscloud.com/hey-partner-your-rms-live-release-is-here-0-0-0-0-0?hs_preview=TVgGuAQq-211134018457
• 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

IBE+ has been upgraded to support 3D Secure (3DS) for Stripe payments, along with an improvement to how payment details are captured at checkout.

Card entry fields are now hosted directly by Stripe, making them clearer, better labelled, and more visually distinct - reducing confusion at the payment step and improving booking completion.

Where required by a guest's bank, a quick verification step will now be triggered during checkout to authenticate the payment. This happens automatically and is designed to be as frictionless as possible for the guest, while significantly improving fraud protection and reducing chargeback risk for properties.

Properties can now control whether email and SMS marketing opt-in options are displayed to guests during the IBE+ checkout flow.

When enabled in Field Maintenance, guests will see channel-specific checkboxes on the guest details step — allowing them to independently opt in or out of email marketing, SMS marketing, or both. Only the channels that have been enabled in 9+ will be displayed, so guests are never shown options that aren't relevant to the property.

If a guest opts in, their preferences are written back to the guest record in 9+. If a guest opts out, that is recorded accordingly. If a property chooses not to expose these options at all, no value is set and the property's default marketing opt-out setting will apply via the sweeper as usual.

Marketing consent is always optional and checkboxes are never pre-selected, keeping the experience transparent and compliant.

IBE+ now includes cookie consent support, helping properties stay compliant with privacy regulations such as GDPR and the UK ePrivacy rules.

A cookie consent banner will be displayed to guests when required, based on the location of the property — not the guest's location. So if your property is in the UK or EU, guests will be prompted to manage their cookie preferences regardless of where they are browsing from.

If you already use your own Google Tag Manager (GTM) setup and cookie banner on your website, IBE+ will display your banner and suppress the default RMS one — so guests see a single, consistent experience across your site and booking engine. If you don't have your own, the RMS default banner will appear where required.

Consent choices and attribution (such as UTM parameters) are also preserved as guests move from your website into the booking engine, so you won't lose analytics data or re-prompt guests unnecessarily.

IBE+ now supports day use categories, allowing guests to search for and book daily-rate options — such as car parks — directly through the booking engine.

When a guest searches with the same arrival and departure date, available day use categories will be returned and displayed alongside their pricing. Bookings are created as standard reservations in 9+, with inventory protected to prevent overbooking — even under high volumes of concurrent booking attempts.

At this stage, day use categories display instead of accommodation categories, not alongside them. Properties with categories configured as "booked by day" in 9+ will have these surfaced automatically when a same-day search is made.