February 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

What will Change	Details of the Change	Target Product and Version	Impact	Call to Action
Pagination has been added to the getFolioHistory operation (GET /hotels/{hotelId}/folioHistory).	Pagination has been added to the getFolioHistory operation, with each page limited to 50 rows.	OPERA 26.1.0.0	All integration partners that call the getFolioHistory operation and expect to receive more than 50 rows in the response.	Once the Change is Live: Include the query parameters limit and offset on requests to getFolioHistory, paginating through results one page of 50 at a time.
The RTP API Operations postRatePlan, postRatePlanPackages, postRatePlanSchedules, putRatePlanSchedules, putRatePlan will enforce validation for the Package transactionCode when missing for the rate.	For RTP API Operation postRatePlan - Added validation for packageTransactionCode when it isn’t included in the request with packages or packageGroup, and no default package transaction code is configured in OPERA Control or provided in the postRatePlan request. For RTP API Operation postRatePlanPackages - When invoked for an existing rate code to add packages or package groups, a validation message is returned if no default package transaction code is configured in OPERA Control and the rate header does not contain a packageTransactionCode. For RTP API Operations postRatePlanSchedules and putRatePlanSchedules - When invoked while creating or editing pricing schedule with packages or packageGroups, a validation message is returned if no default package transaction code is configured in OPERA Control and the rate header does not contain a packageTransactionCode. Validation Error message returned for above API calls - "Please set a Package Transaction Code on the rate code or configure a Default Package Transaction Code in OPERA Control." NOTE: For above mentioned APIs no validation message is returned when a Default Package Transaction Code is configured in OPERA Control; the rate code header will use and save the default value. For RTP API Operation putRatePlan - Added validation for packageTransactionCode when it’s missing or removed from the request and the rate code or pricing schedule has packages or packageGroups attached. Validation Error message returned for putRatePlan api - "Package Transaction Code is required and cannot be removed once a package is attached to a rate code or pricing schedule. Provide or Select another valid code to update it."	OPERA 26.2.0.0	All integrations using the following RTP API operations: postRatePlan, postRatePlanPackages, postRatePlanSchedules, putRatePlanSchedules, and putRatePlan. If a packageTransactionCode is not provided and no Default Package Transaction Code is configured in OPERA Control, requests that include packages or packageGroups (or attempt to remove packageTransactionCode when packages are attached) will return a validation error. If a Default Package Transaction Code is configured in OPERA Control, the rate header will automatically use and save the default, and no validation message will be returned.	Prepare Now: Always include packageTransactionCode in requests to the postRatePlan, postRatePlanPackages, postRatePlanSchedules, putRatePlanSchedules, and putRatePlan APIs. Once the Change is Live: Always include packageTransactionCode in requests to the postRatePlan, postRatePlanPackages, postRatePlanSchedules, putRatePlanSchedules, and putRatePlan APIs. Configure a Default Package Transaction Code in OPERA Controls. Review error handling to surface the new validation message in client applications and monitoring.
API operations across multiple modules have been enhanced for flexibility and extensibility to allow advanced querying/filtering and avoid the limitations of URL length. This involved converting GET and DELETE APIs to use the "POST as Search" pattern, placing formerly query parameters into the request body instead of the URL. The APIs' functionality remains the same, but sets a base for enhanced filters in the future.	GET endpoints replaced by POST-based “searches” endpoints. Each of the below GET endpoints will be replaced with a corresponding POST endpoint on the same path, with `/searches` appended. Request parameters previously provided as query strings will now be included in the request body as JSON. DELETE endpoints replaced by POST-based “deletions” endpoints. Each of the below DELETE endpoints will be replaced with a corresponding POST endpoint on the same path, with `/deletions` appended. Parameters previously provided in the URL or query strings will now be supplied in the JSON request body. Request parameters moved from query strings or URL into JSON request bodies. All parameters for the new endpoints will be structured as JSON objects in the request body, enabling more complex and flexible query operations. The parameters will have exactly the same names in the request body as they do today in the query or URL parameters. All legacy endpoints will be marked as deprecated (`"deprecated": true`). For the legacy operation IDs and endpoints and their corresponding replacements, see Legacy and New API Operation IDs and Endpoints.	OPERA 26.2.0.0 OPERA 27.3.0.0 - see September 2026 major change.	To ensure backward compatibility, continue supporting the old GET method for active operations during the 6-month deprecation period and for OPERA environments on earlier versions of OPERA Cloud. Throughout the deprecation window, legacy endpoints will include the response header “deprecated: true” on all responses. After the sunset date, any requests to the deprecated endpoints will receive a 404 Not Found status with no response body.	Prepare Now: Review the list of deprecated endpoints and decide whether you will need to take action. Once the Change is Live: Update code calling the deprecated endpoints to use the new URLs and HTTP method "POST". Update code calling the deprecated endpoints to send query parameters in the request body. For example: Old request: GET /crm/v1/profiles?profileType=Guest&city=Dublin New request: POST /crm/v1/profiles/searches `{ "profileType": "Guest", "city": "Dublin" }` Test thoroughly to ensure parity of the response body. Monitor the OPERA Cloud version of connected environments using this operation, or monitor API responses for the `deprecated: true` header to determine when to switch to the new endpoints.

Pagination has been added to the getFolioHistory operation (GET /hotels/{hotelId}/folioHistory).

Pagination has been added to the getFolioHistory operation, with each page limited to 50 rows.

OPERA 26.1.0.0

All integration partners that call the getFolioHistory operation and expect to receive more than 50 rows in the response.

Once the Change is Live:

Include the query parameters limit and offset on requests to getFolioHistory, paginating through results one page of 50 at a time.

The RTP API Operations postRatePlan, postRatePlanPackages, postRatePlanSchedules, putRatePlanSchedules, putRatePlan will enforce validation for the Package transactionCode when missing for the rate.

For RTP API Operation postRatePlan - Added validation for packageTransactionCode when it isn’t included in the request with packages or packageGroup, and no default package transaction code is configured in OPERA Control or provided in the postRatePlan request.
For RTP API Operation postRatePlanPackages - When invoked for an existing rate code to add packages or package groups, a validation message is returned if no default package transaction code is configured in OPERA Control and the rate header does not contain a packageTransactionCode.
For RTP API Operations postRatePlanSchedules and putRatePlanSchedules - When invoked while creating or editing pricing schedule with packages or packageGroups, a validation message is returned if no default package transaction code is configured in OPERA Control and the rate header does not contain a packageTransactionCode.
Validation Error message returned for above API calls - "Please set a Package Transaction Code on the rate code or configure a Default Package Transaction Code in OPERA Control."
NOTE: For above mentioned APIs no validation message is returned when a Default Package Transaction Code is configured in OPERA Control; the rate code header will use and save the default value.
For RTP API Operation putRatePlan - Added validation for packageTransactionCode when it’s missing or removed from the request and the rate code or pricing schedule has packages or packageGroups attached.
Validation Error message returned for putRatePlan api - "Package Transaction Code is required and cannot be removed once a package is attached to a rate code or pricing schedule. Provide or Select another valid code to update it."

OPERA 26.2.0.0

All integrations using the following RTP API operations: postRatePlan, postRatePlanPackages, postRatePlanSchedules, putRatePlanSchedules, and putRatePlan.

If a packageTransactionCode is not provided and no Default Package Transaction Code is configured in OPERA Control, requests that include packages or packageGroups (or attempt to remove packageTransactionCode when packages are attached) will return a validation error.
If a Default Package Transaction Code is configured in OPERA Control, the rate header will automatically use and save the default, and no validation message will be returned.

Prepare Now:

Always include packageTransactionCode in requests to the postRatePlan, postRatePlanPackages, postRatePlanSchedules, putRatePlanSchedules, and putRatePlan APIs.

Once the Change is Live:

Always include packageTransactionCode in requests to the postRatePlan, postRatePlanPackages, postRatePlanSchedules, putRatePlanSchedules, and putRatePlan APIs.

Configure a Default Package Transaction Code in OPERA Controls.

Review error handling to surface the new validation message in client applications and monitoring.

API operations across multiple modules have been enhanced for flexibility and extensibility to allow advanced querying/filtering and avoid the limitations of URL length.

This involved converting GET and DELETE APIs to use the "POST as Search" pattern, placing formerly query parameters into the request body instead of the URL.

The APIs' functionality remains the same, but sets a base for enhanced filters in the future.

GET endpoints replaced by POST-based “searches” endpoints. Each of the below GET endpoints will be replaced with a corresponding POST endpoint on the same path, with /searches appended. Request parameters previously provided as query strings will now be included in the request body as JSON.
DELETE endpoints replaced by POST-based “deletions” endpoints. Each of the below DELETE endpoints will be replaced with a corresponding POST endpoint on the same path, with /deletions appended. Parameters previously provided in the URL or query strings will now be supplied in the JSON request body.
Request parameters moved from query strings or URL into JSON request bodies. All parameters for the new endpoints will be structured as JSON objects in the request body, enabling more complex and flexible query operations. The parameters will have exactly the same names in the request body as they do today in the query or URL parameters.
All legacy endpoints will be marked as deprecated ("deprecated": true).

For the legacy operation IDs and endpoints and their corresponding replacements, see Legacy and New API Operation IDs and Endpoints.

OPERA 26.2.0.0

OPERA 27.3.0.0 - see September 2026 major change.

To ensure backward compatibility, continue supporting the old GET method for active operations during the 6-month deprecation period and for OPERA environments on earlier versions of OPERA Cloud.

Throughout the deprecation window, legacy endpoints will include the response header “deprecated: true” on all responses.

After the sunset date, any requests to the deprecated endpoints will receive a 404 Not Found status with no response body.

Prepare Now:

Review the list of deprecated endpoints and decide whether you will need to take action.

Once the Change is Live:

Update code calling the deprecated endpoints to use the new URLs and HTTP method "POST".
Update code calling the deprecated endpoints to send query parameters in the request body.

For example:

Old request: GET /crm/v1/profiles?profileType=Guest&city=Dublin

New request: POST /crm/v1/profiles/searches

{
    "profileType": "Guest",
    "city": "Dublin"
}

Test thoroughly to ensure parity of the response body.
Monitor the OPERA Cloud version of connected environments using this operation, or monitor API responses for the deprecated: true header to determine when to switch to the new endpoints.