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.

OHIP version 26.2

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.

color: Color value is invalid. 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.

Parent topic: Upcoming Major Changes