June 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 searchCashiers operation endpoint has been renamed to better align with POST-as-search naming conventions.

The original endpoint for searchCashiers introduced in 26.2 of "/cashierDetails/cashiers/search" is being changed to "/cashierDetails/cashiers/searches" (adding an "es" to the end of the search resource).

OPERA Cloud 26.3

Customers who are already using the /cashierDetails/cashiers/search endpoint will need to update their integrations to use /cashierDetails/cashiers/searches. After the change is live, requests to the old endpoint will return 404 Not Found.

Call to action - prepare now

Ensure integrations first attempt to use /cashierDetails/cashiers/searches and, if that endpoint is unavailable, fall back to/cashierDetails/cashiers/search.

Call to action - once live

Monitor integrations for 404 Not Found responses from /cashierDetails/cashiers/search and verify that all calls now call /cashierDetails/cashiers/seaches.

The data type for the TruncBeginDate input parameter has been corrected from DateTime to Date.

The change has been made in the BookingReservationExtended API input parameter of the Data APIs.

Reporting & Analytics 26.1

Any query built against the BookingReservationExtended API which uses the input parameter TruncBeginDate will fail if still passing a DateTime value.

Call to action - prepare now

Correct all queries made against the BookingReservationExtended Data API and ensure the value being passed in the input parameter includes only the date component. If this call fails, pass a DateTime value.

Call to action - once live

Correct all queries made against the BookingReservationExtended Data API and ensure the value being passed in the input parameter includes only the date component.

To increase the flexibility of querying, input parameters to the Data APIs have been rearranged into a mandatory group and an optional group. All Data APIs must now be invoked with at least two input parameters: one parameter from Group 1 and at least one additional parameter from Group 2. To determine the specific parameters required for each API query being developed, refer to the corresponding API Specifications for that API.

Validation requirements have been introduced for all Data APIs to ensure sufficient filtering criteria are provided in API requests. Going forward, every Data API request must include:
  • One input parameter from Group 1, and
  • At least one additional input parameter from Group 2. The applicable parameters may differ across APIs. Therefore, developers must refer to the respective API Specifications to identify the valid Group 1 and Group 2 parameters for each API query implementation.

Reporting & Analytics 26.3

This change may impact existing customers whose integrations invoke Data APIs without providing the required combination of input parameters. Requests that do not include one parameter from Group 1 and at least one parameter from Group 2, as defined in the respective API Specification, may fail validation and return an error response.

Customers with existing integrations should review their API requests and update them, if necessary, to comply with the new input parameter requirements.

Call to action - prepare now

To ensure a smooth transition and avoid service disruptions, customers should review all existing Data API integrations and verify that requests comply with the new input parameter requirements.

Recommended actions:
  • Identify all integrations that consume the affected Data APIs.
  • Review the corresponding API Specifications to determine the valid Group 1 and Group 2 parameters for each API.
  • Update API requests to include one parameter from Group 1 and at least one parameter from Group 2. Taking these steps now will help ensure uninterrupted API functionality and a seamless adoption of the new validation requirements.

Call to action - once live

Once this change is live, customers should monitor their Data API integrations to ensure requests are being processed successfully and are compliant with the new validation requirements.

Recommended actions:
  • Verify that all Data API requests include one parameter from Group 1 and at least one parameter from Group 2, as defined in the relevant API Specification.
  • Monitor application logs and API responses for validation errors related to missing or invalid input parameters.
  • Review newly developed or modified integrations to ensure continued compliance with the API requirements.
  • Refer to the API Specifications for guidance when troubleshooting or implementing future enhancements.

Audit metadata fields for creation and modification information in the BookingsReservationExtended and FinancialTransactionDetailsExtended Data APIs have been renamed. API consumers must update their integrations to use the new field names instead of the legacy createdOn, createdBy, modifiedOn, and modifiedBy fields.

The audit metadata fields used to capture record creation and modification information in the BookingsReservationExtended and FinancialTransactionDetailsExtended Data APIs have been renamed for consistency with the updated API schema. This change affects the fields representing the creator, creation timestamp, last modifier, and last modification timestamp.

 Reporting & Analytics 26.1

This is a breaking change for consumers of the Extended Data APIs that reference the existing audit metadata field names. Failure to update may result in missing data, mapping errors, or integration failures when processing API responses. No impact is expected for consumers that do not use these fields.

Prepare Now:

Review and update any integrations or custom code that reference the affected audit fields.

Once the Change is Live:

Verify that your integrations and applications are successfully consuming the renamed fields and update any remaining references to the legacy field names.