May 2026 ReadMe

Overview

This document contains a list of upcoming major changes to Oracle Hospitality APIs.

What will Change Details of the Change Target Product and Version Impact Call to Action

This update introduces a new control that determines whether profile identification is stored globally or at the property level. When configured for property-level storage, the property code must be included when updating or viewing profile identification to determine access.

/crm/v1/profiles - postProfile

OPERA Cloud now supports property-specific guest identification data. Profile-level identification remains the global source of truth, but when the property-level control is enabled, identification captured for a property is visible and editable only for that property. API create, read, update, and delete operations follow the same property controls, masking, audit logging, permissions, and retention purge rules.

OPERA Cloud 26.3

If the OPERA control is set to PROPERTY, partners must provide the property code when adding, updating, or viewing identification associated with the profile. If the property code is not provided, the system returns a warning.

Call to action - prepare now

Review integrations that read or update guest identification data. Make sure API calls use the correct property context and do not assume all identification data on a profile is shared across properties. If your integration needs property-specific identification, test the create, view, update, and delete flows with the property-level control enabled, and confirm downstream caching, reporting, or export logic handles both global and property-specific identification correctly.

Partners should confirm with their customers whether they plan to enable this control so they can prepare their integrations accordingly.

Call to action - once live

After go-live, API integrators should verify whether customers have enabled property-level profile identification. When enabled, identification data is managed in the context of a specific property, and API calls must include the property code to create, view, update, or delete that property's identification data. Integrators should test all identification workflows using the property-level control and confirm that downstream systems can support both global and property-specific identification behavior.

Enhance APIs to provide masked or unmasked data based on OPERA user tasks.. When the OAuth client does not have sensitive data access, the birthdate and membership number are masked. When the OAuth client has sensitive data access, the birthdate and membership number are not masked.

/crm/v1/profiles - postProfile

Profile APIs now follow the same masking rules as the OPERA Cloud UI. Sensitive profile data, such as membership numbers, birthdate, and identification details, will be returned as masked or unmasked based on the OPERA user tasks assigned to the OHIP user making the API call.

OPERA Cloud 26.3

The API response masks sensitive member fields based on the OHIP user's access permissions. If the OAuth client does not have sensitive data access, the birthdate and membership number are masked. If the OAuth client has sensitive data access, these fields are returned unmasked.

Call to action - prepare now

Review integrations that retrieve profile, membership, or identification data. Make sure the customer has enabled module level access control (available from OPERA 26.2 and OHIP 26.2). Make sure the OAuth client has the Sensitive Data Access permission if the integration requires unmasked data, and update consuming systems to handle masked values correctly. Do not assume sensitive fields will always be returned unmasked.

Call to action - once live

Following go-live, API integrators should confirm that their integrations can support both masked and unmasked responses for birthdate and membership number. If these fields are masked, the OAuth client does not have sensitive data access. Integrators requiring unmasked values should work with the appropriate access administration process to ensure the OAuth client has the necessary permissions.

Add validation to ensure the Sell Limits feature is available only when the SELL LIMITS control is enabled.

changeSellLimitByDate - /hotels/

{hotelId}/sellLimitschangeSellLimitByDateRange - /hotels/{hotelId}

/sellLimitsByDateRangepostSellLimitsProcess (Async API) - /externalSystems/{extSystemCode}

/hotels/{hotelId}

/sellLimits

OPERA Cloud 26.3
All integrations using the following API operations:
  • changeSellLimitByDate
  • changeSellLimitByDateRange
  • postSellLimitsProcess

If the SELL LIMITS control is OFF, these requests return a validation error. If the control is ON, requests are processed successfully.

Call to action - prepare now

Always ensure the SELL LIMITS control is enabled before sending requests to changeSellLimitByDate, changeSellLimitByDateRange, and postSellLimitsProcess APIs. Partners should check with integrated customers to determine whether they plan to enable this OPERA control.

Call to action - once live

Before sending requests to changeSellLimitByDate, changeSellLimitByDateRange, and postSellLimitsProcess APIs, partners should verify whether the SELL LIMITS control is enabled in the target environment. Review error handling to ensure the validation message is displayed appropriately in client applications and captured by monitoring systems.

Validation will be added to postRatePlan and putRatePlan when ratePlanBasedOnRates.basedOnRatePlanType is sent, but ratePlanBasedOnRates.baseRate is not. The impacted rate code types are Base Rate, Dynamic Base Rate, and Advanced Dynamic Base Rate.

No change in specification, but validation will enforce that if ratePlanBasedOnRates.basedOnRatePlanType is present, then ratePlanBasedOnRates.baseRate is required for postRatePlan and putRatePlan.

  • Base Rate details are required when basedOnRatePlanType is BaseRate.
  • Dynamic Base Rate details are required when basedOnRatePlanType is DynamicBaseRate.
  • Advanced Dynamic Base Rate is required when basedOnRatePlanType is AdvancedDynamicBaseRate.

OPERA Cloud 26.3

All integrations using postRatePlan and putRatePlan. If basedOnRatePlanType is provided without baseRate details, requests for Base Rate, Dynamic Base Rate, and Advanced Dynamic Base Rate will return a validation error.

Prepare Now:

Always include ratePlanBasedOnRates.baseRate details in requests to postRatePlan and putRatePlan APIs when ratePlanBasedOnRates.basedOnRatePlanType is provided.

Once the Change is Live:

Always include ratePlanBasedOnRates.baseRate details in requests to postRatePlan and putRatePlan APIs when basedOnRatePlanType is provided. Review error handling to ensure validation messages are surfaced appropriately in client applications and monitoring systems.

Add validation so that Delete Restriction is allowed only when the End Date is greater than or equal to the Start Date.

deleteRestriction - /hotels/{hotelId}

/restrictions/

{restrictionType}

OPERA Cloud 26.3

All integrations using deleteRestriction. If the Restriction End Date is lower than the Start Date, requests return a validation error. If the End Date is greater than or equal to the Start Date, requests process successfully.

Prepare Now:

Always ensure the Restriction End Date is greater than or equal to the Start Date for requests to deleteRestriction APIs.

Once the Change is Live:

Review error handling to ensure the new validation message is surfaced appropriately in client applications and monitoring systems.