October 2025 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
The data included in the Business Event payload of the Streaming API will be now be dictated by what triggers are configured in the OHIP Developer Portal. Previously, ALL data elements were included in the "detail" array of the Business Event payload.	New features available in OHIP 25.4 will mean that business events consumed via the streaming API must have triggers defined for them. Triggers can be defined in the OHIP Developer Portal. A trigger is a business data element such as LastName. If an UPDATE PROFILE event is subscribed and the trigger LastName is configured, then a Business Event notification will be sent only when the LastName field changes. This is the same functionality as the polling API which is configured in OPERA Cloud. With OHIP 25.4, when a Business Event is sent by the Streaming API, only the Data Elements explicitly configured as triggers for that event in the OHIP Developer Portal will be included in the "detail" array of the Business Event payload. Data elements that have not been selected will no longer be transmitted, even if they are updated within OPERA Cloud. This change is being introduced to improve performance, efficiency, and system stability by reducing unnecessary data transmission.	OHIP version 25.4	Existing subscriptions will only be affected if the event configuration is changed in the OHIP Developer Portal; until then, they will receive all data elements. New events being configured and existing events being edited in the OHIP Developer Portal must select triggers, and will receive only the data elements in the payload that match the triggers. Integrations that rely on receiving all data elements in the Streaming Business Event payloads may experience incomplete data when editing existing configuration or subscribing to a new environment in the OHIP Developer Portal.If not adjusted integrations will be affected: Payloads will contain only the configured data elements. External systems may not receive all the expected data elements in the payload.	Adapt Integration Logic: Ensure your integration can handle payloads with variable data elements depending on the configuration. Add Orchestration: Orchestrate such that when you receive a Business Event notification you look at the primaryKey and send an API call to obtain the latest version of that resource using the primaryKey. This has the added benefit that the API call will return the full resource and child elements, whereas the Business Event notification includes only the header of the resource. Once the change is live If not orchestrating and you require a small number of data elements, use the OHIP Developer Portal to ensure these are selected for all subscribed events and all subscribed environments.
This change applies only to Base Rate code types that have a Standard Rate linked to them. Currently, the operations postRatePlan, putRatePlan, postRatePlanSchedules, and putRatePlanSchedules are used for creating and updating rate plan headers and pricing schedules. When the parent Standard Rate code has a large number of pricing schedules (1000+), or is linked to a high number of Base Rate codes (75+), you must now use the additional ASYNC process APIs: startRatePlanSchedulesSyncProcess headRatePlanSchedulesSyncProcessStatus headRatePlanSchedulesSyncProcessStatus These new ASYNC process APIs work alongside the existing operations to ensure proper processing and synchronization of pricing schedules in these large or complex scenarios.	When creating and updating Base Rate Codes for Parent Standard Rate with 1000+ Pricing Schedules: Use postRatePlan and putRatePlan for the header Use the asynchronous APIs below to update pricing schedules: startRatePlanSchedulesSyncProcess headRatePlanSchedulesSyncProcessStatus getRatePlanSchedulesSyncProcessSummary When updating Pricing Schedules for Standard Rate linked to 75+ Base Rate Codes: Use postRatePlanSchedules and putRatePlanSchedules to create and update pricing schedules for the Standard Rate (Parent Rate code) Then use the asynchronous APIs below to update and synchronize pricing schedules to the linked Base Rate codes: startRatePlanSchedulesSyncProcess headRatePlanSchedulesSyncProcessStatus getRatePlanSchedulesSyncProcessSummary These changes ensure pricing schedules are accurately processed and synced at scale.	OPERA Cloud 25.5	If not adopted, pricing schedules will not be processed to the dependent base rates for large volumes.	Prepare Now Review your current integration for Base Rate code types that have an associated Standard Rate. Continue using the existing API operations (postRatePlan, putRatePlan, postRatePlanSchedules, putRatePlanSchedules) Once the change is live If you are creating or updating a Base Rate that is linked to a Standard Rate code with 1000 or more pricing schedules, you should still use the existing APIs for updating the rate plan header, but you now need to call asynchronous (ASYNC) operations: startRatePlanSchedulesSyncProcess, headRatePlanSchedulesSyncProcessStatus, and getRatePlanSchedulesSyncProcessSummaryAPIs to handle the pricing schedules. If you are creating or updating pricing schedules for a Standard Rate code that is linked to more than 75 Base Rate codes, you should first update the Standard Rate using the existing POST/PUT postRatePlanSchedulesRatePlanSchedules APIs, and then use the new ASYNC APIs to make sure all the linked Base Rate codes get the updated pricing schedules. Test all changes in a UAT environment or sandbox environment to address any issues proactively. Confirm that the updated logic for processing and synchronizing pricing schedules is now active in your production environment. Monitor integrations to ensure the new and existing APIs work as expected and that pricing updates are applied correctly to all relevant rate codes.
The “membershipLevel” field is now mandatory in the postMembership operation.	To align the API with the OPERA Cloud user interface, the postMembership operation now requires the membershipLevel attribute to be able to create a membership.	OPERA Cloud 25.3	API calls to postMembership will fail if the request body does not include the membershipLevel field.	If calling the postMembership operation, ensure code always sends the membershipLevel attribute.

What will Change

Details of the Change

Target Product and Version

Impact

Call to Action

The data included in the Business Event payload of the Streaming API will be now be dictated by what triggers are configured in the OHIP Developer Portal. Previously, ALL data elements were included in the "detail" array of the Business Event payload.

New features available in OHIP 25.4 will mean that business events consumed via the streaming API must have triggers defined for them. Triggers can be defined in the OHIP Developer Portal. A trigger is a business data element such as LastName. If an UPDATE PROFILE event is subscribed and the trigger LastName is configured, then a Business Event notification will be sent only when the LastName field changes. This is the same functionality as the polling API which is configured in OPERA Cloud.

With OHIP 25.4, when a Business Event is sent by the Streaming API, only the Data Elements explicitly configured as triggers for that event in the OHIP Developer Portal will be included in the "detail" array of the Business Event payload. Data elements that have not been selected will no longer be transmitted, even if they are updated within OPERA Cloud.

This change is being introduced to improve performance, efficiency, and system stability by reducing unnecessary data transmission.

OHIP version 25.4

Existing subscriptions will only be affected if the event configuration is changed in the OHIP Developer Portal; until then, they will receive all data elements.

New events being configured and existing events being edited in the OHIP Developer Portal must select triggers, and will receive only the data elements in the payload that match the triggers.

Integrations that rely on receiving all data elements in the Streaming Business Event payloads may experience incomplete data when editing existing configuration or subscribing to a new environment in the OHIP Developer Portal.If not adjusted integrations will be affected:

Payloads will contain only the configured data elements.
External systems may not receive all the expected data elements in the payload.

Adapt Integration Logic: Ensure your integration can handle payloads with variable data elements depending on the configuration.

Add Orchestration: Orchestrate such that when you receive a Business Event notification you look at the primaryKey and send an API call to obtain the latest version of that resource using the primaryKey. This has the added benefit that the API call will return the full resource and child elements, whereas the Business Event notification includes only the header of the resource.

Once the change is live

If not orchestrating and you require a small number of data elements, use the OHIP Developer Portal to ensure these are selected for all subscribed events and all subscribed environments.

This change applies only to Base Rate code types that have a Standard Rate linked to them.

Currently, the operations postRatePlan, putRatePlan, postRatePlanSchedules, and putRatePlanSchedules are used for creating and updating rate plan headers and pricing schedules.

When the parent Standard Rate code has a large number of pricing schedules (1000+), or is linked to a high number of Base Rate codes (75+), you must now use the additional ASYNC process APIs:

startRatePlanSchedulesSyncProcess
headRatePlanSchedulesSyncProcessStatus
headRatePlanSchedulesSyncProcessStatus

These new ASYNC process APIs work alongside the existing operations to ensure proper processing and synchronization of pricing schedules in these large or complex scenarios.

When creating and updating Base Rate Codes for Parent Standard Rate with 1000+ Pricing Schedules:
- Use postRatePlan and putRatePlan for the header
- Use the asynchronous APIs below to update pricing schedules:
  1. startRatePlanSchedulesSyncProcess
  2. headRatePlanSchedulesSyncProcessStatus
  3. getRatePlanSchedulesSyncProcessSummary
When updating Pricing Schedules for Standard Rate linked to 75+ Base Rate Codes:
- Use postRatePlanSchedules and putRatePlanSchedules to create and update pricing schedules for the Standard Rate (Parent Rate code)
- Then use the asynchronous APIs below to update and synchronize pricing schedules to the linked Base Rate codes:
1. startRatePlanSchedulesSyncProcess
2. headRatePlanSchedulesSyncProcessStatus
3. getRatePlanSchedulesSyncProcessSummary

These changes ensure pricing schedules are accurately processed and synced at scale.

OPERA Cloud 25.5

If not adopted, pricing schedules will not be processed to the dependent base rates for large volumes.

Prepare Now

Review your current integration for Base Rate code types that have an associated Standard Rate.
Continue using the existing API operations (postRatePlan, putRatePlan, postRatePlanSchedules, putRatePlanSchedules)

Once the change is live

If you are creating or updating a Base Rate that is linked to a Standard Rate code with 1000 or more pricing schedules, you should still use the existing APIs for updating the rate plan header, but you now need to call asynchronous (ASYNC) operations: startRatePlanSchedulesSyncProcess, headRatePlanSchedulesSyncProcessStatus, and getRatePlanSchedulesSyncProcessSummaryAPIs to handle the pricing schedules.
If you are creating or updating pricing schedules for a Standard Rate code that is linked to more than 75 Base Rate codes, you should first update the Standard Rate using the existing POST/PUT postRatePlanSchedulesRatePlanSchedules APIs, and then use the new ASYNC APIs to make sure all the linked Base Rate codes get the updated pricing schedules.
Test all changes in a UAT environment or sandbox environment to address any issues proactively.
Confirm that the updated logic for processing and synchronizing pricing schedules is now active in your production environment.
Monitor integrations to ensure the new and existing APIs work as expected and that pricing updates are applied correctly to all relevant rate codes.

The “membershipLevel” field is now mandatory in the postMembership operation.

To align the API with the OPERA Cloud user interface, the postMembership operation now requires the membershipLevel attribute to be able to create a membership.

OPERA Cloud 25.3

API calls to postMembership will fail if the request body does not include the membershipLevel field.

If calling the postMembership operation, ensure code always sends the membershipLevel attribute.

Parent topic: Upcoming Major Changes