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
The time zone used by write operations for guest messages will be aligned to the hotel's time zone. Module: rsv Affected operations: postGuestMessages, putGuestMessages, and putResvGuestMessages. Fields impacted: resvMessageType.messageDate messageDeliveryType.deliveryDate No change to read operations (for example, getGuestMessages), which already return hotel time zone.	Current: GET responses return messageDate and deliveryDate in the hotel's time zone. POST/PUT requests expect/interpret these fields in the database time zone. After the change: POST/PUT requests provide messageDate and deliveryDate in the hotel's time zone, consistent with GET.	OPERA Cloud 26.1	Submitted timestamp requests will be interpreted in the hotel's time zone rather than the database time zone, causing: Incorrect message scheduling and delivery times (offset by the difference between DB and hotel time zones). Inconsistent data between GET and POST/PUT flows. Potential operational issues (for example, premature/late deliveries)	Call to action - prepare now Inventory usage: Identify all integrations calling postGuestMessages, putGuestMessages, and putResvGuestMessages. Update client logic: Convert any logic that currently builds messageDate or deliveryDate in the database time zone to produce timestamps in the hotel's time zone (with correct offset). Ensure DST is handled according to the hotel's time zone rules. Testing: Add test cases that round-trip a message via POST/PUT then GET to confirm timestamps match in the hotel's time zone. Validate any scheduled/delayed delivery scenarios across DST boundaries. Documentation: Update internal runbooks, mappings, and configuration to reference hotel time zone for these fields. Call to action - once live Deploy client changes that send messageDate and deliveryDate in the hotel's time zone. Monitor: Compare POST/PUT payloads to subsequent GET responses to verify alignment. Watch for unexpected shifts in scheduled delivery times. Remediate: Correct any hard-coded UTC/DB-timezone conversions. Re-run workflows (for example, scheduled sends) to ensure alignment.
The operations getCCAuthorizationInstructions and getCCAuthorizationInstructionsByProfile will be retired and replaced with POST operations using a request body for auth instructions.	The following GET endpoints will be deprecated: GET /hotels/{hotelId}/reservations/{reservationId}/paymentMethods/creditCard/authorizeInstructions GET /hotels/{hotelId}/profiles/{profileId}/paymentMethods/creditCard/authorizeInstructions New POST endpoints must be used with a request payload for all authorization instruction retrievals.	OPERA Cloud 26.1	All integrations, partners, or custom code utilizing the deprecated GET endpoints will experience failures once these endpoints are retired. This impacts all use-cases involving authorization instructions, including PasserBy, Check-in, settlement, and any flows that perform post payments with credit cards. All such integrations and processes must be updated to use the new POST endpoints to ensure continued functionality.	Call to action - prepare now Inventory all usage of the deprecated GET endpoints. Update integrations and client logic to use the new POST endpoints and construct the appropriate request bodies. Test all key flows for breakage. Call to action - once live Remove any legacy references to GET endpoints. Ensure all calls use POST. Monitor error logs and integration health for any missed migrations after go-live.
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 is not included in the request with packages or packageGroup, and no default package transaction code is configured in OPERA Controls 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 Controls and the rate header does not contain a packageTransactionCode. For RTP API Operations postRatePlanSchedules and putRatePlanSchedules — When invoked while creating or editing a pricing schedule with packages or packageGroups, a validation message is returned if no default package transaction code is configured in OPERA Controls 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 the above mentioned APIs, no validation message is returned when a Default Package Transaction Code is configured in OPERA Controls; the rate code header will use and save the default value. For RTP API Operation putRatePlan — Added validation for packageTransactionCode when it is 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 the former query parameters into the request body instead of the URL. The API 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). Refer to this table for a list of legacy endpoints and their corresponding new endpoints.	OPERA 26.2.0.0	To ensure backward compatibility, continue supporting the old GET method for active operations during the 6-month deprecation period and for OPERA Cloud 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.	Call to Action - Prepare Now Review the list of deprecated endpoints and decide whether you will need to take action. Call to Action - Once 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 the connected environments using this operation, or monitor API responses for the deprecated: true header to determine when to switch to the new endpoints.

• Legacy and New API Operation IDs and Endpoints