Changelog

A changelog records and lists notable changes to products or projects with links to the relevant documentation. This changelog also includes changes to the documentation. The logs are chronological, with the newest date on top. Every two weeks you can find an overview of:

• What is new?
  Refers to new API products or features.
  
• What is going to change?
  Refers to upcoming changes or updates to existing API products or features.
  
• What has changed?
  Refers to minor changes or updates to existing API products or features.
  
• What was fixed?
  Refers to bug fixes.

In this release cycle, we don't have any major updates. However, we want to bring your attention to two bug fixes. Read on for more information.

• [Rates and Availability API] [Documentation] Prices are removed when switching pricing type (ACI-4727)

  Changing a pricing type removes all existing prices for the affected room-rates. We now have added this expected behavior in the documentation. Re-push all prices after pricing type changes. When switching to or from OBP or LOS, also redefine closed dates, restrictions, and inventory.

  For more information, see Effects of changing the pricing type.

• Reservations API Duplicated room reservations (ACI-4748)

  The system no longer incorrectly returns the same room reservations more than once again when using the reservationssummary endpoint.

In this release cycle, we would like to introduce new withheld tax charge types in the payout breakdown of the Payments API. We've also added a new security measure to protect guests’ phone numbers. In addition, we want to bring your attention to a bug fix. Read on for more information.

• Payments API New withheld tax charge types in the payout breakdown

  The GET /connectivity-payments/reservations/{reservation-id} and GET /connectivity-payments/reservations/{reservation-id}/breakdown endpoints can now return VAT on Commission and VAT on Payment Charge in price_breakdown.charges[].type, alongside Short Term Rental (Withheld Tax) and France Social Security Tax (Withheld Tax).

  These charges are withheld from the partner payout, so they return is_included_total_partner_payout: FALSE. The type field has always been dynamic, so no integration changes are required.

• Reservations API New security measure to protect guests’ phone numbers

  The Reservations API no longer includes phone numbers of guests globally as of September 28, 2026.

  The phone-number field will no longer be provided through the reservations API response. Other reservation fields and reservation processing remain unchanged. Note that there is a difference between OTA (removal of the entire telephone element) and BXML (omission of the phone number, but not of the entire element).

For more information, see the Guest phone number changes in reservation payloads in the Migration guide.

• Reservations API Incorrect total amount shared for some modified bookings (ACI-4703)

  The system now correctly returns the accurate total amount again for modified bookings when using the Reservations API.

In this release cycle, we don't have any major updates. However, we want to bring your attention to a bug fix and a documentation change. Read on for more information.

• Reservations API Missing cancellation messages and fallback emails (ACI-4695)

  The system now correctly returns cancellation messages again when using the Reservations API.

• Reporting API documentation Clarified existing request requirements

  The documentation now clarifies that each request must contain either report or stay_change, and that price is required in every stay_change. The price can be a non-negative decimal number; it is not restricted to integers. Guest misconduct reports require misconduct_details with a non-empty details_text of at most 240 characters. The documentation previously described price and details_text as optional.

  We also clarified the required property-damage fields and the optional damage_unavailable field, which defaults to 0 (no) when omitted. These are documentation corrections describing existing API behavior; the API's validation behavior has not changed.

In this release cycle, we would like to introduce a new Photo API feature and a new version of the Messaging API, and share few updates including the sustainability facility type copy. We also want to bring your attention to a couple of bug fixes. Read on for more information.

• [Developer Portal] Improved search results

  Search now returns more relevant results across all API documentation, making it easier to find the right topic for any API or endpoint.

• Photo API Upload 360-degree panoramic photos

  You can now upload 360-degree panoramic photos through the Photo API.

• Messaging API Introducing version 1.3 with the is_redacted attribute

  Version 1.3 of the Messaging API adds the is_redacted attribute to the attributes object of every message.

  We scan messages for phishing content and redact the messages in which we detect it. We still return a redacted message in API responses, but we replace its content with the text This message was deleted and remove its attachments. The is_redacted attribute indicates whether we redacted the content of a message, which lets you distinguish a redacted message from a message that happens to contain the same text.

  We redact these messages irrespective of the version you use. If you use a version earlier than 1.3, you receive the redacted content without the is_redacted attribute.

  We detect phishing content shortly after a message is created, so a message that you already retrieved and stored might be redacted in a later response. To identify such a message, use the ACCSEC_PARTNER_PHISHING notification of the Connectivity Notifications Service (CNS).

  For more information, see version 1.3 and Understanding redacted messages.

• Content API Updated suggested copy for sustainability facility types

  The suggested copy for sustainability facility types introduced in 2020, such as plastic removal, has changed. If you display these facility names in your application, review the updated suggested copy and apply the changes.

• Reservations API Confirmation XML events not generated (ACI-4670, ACI-4700)

  Reservation confirmation messages were not generated for reservations made prior to 4 August 2026, which meant that confirmation XML events were not sent. These reservations have now been fixed.

• Room and Rate Plan Management API Valid roomrate-creation requests rejected in v1.3 (ACI-4690)

  Valid roomrate-creation requests via POST /hotels/ota/OTA_HotelProductNotif (v1.3) failed with the error Defined policy code is not available for this hotel: 38, even though equivalent requests succeeded in v1.0. The issue has been resolved and v1.3 now processes valid requests with consistent policy validation.

  For more information, see Creating a roomrate.

In this release cycle, we don't have any major updates. However, we want to bring your attention to a few bug fixes. Read on for more information.

• Content API Incorrect 400 error returned when setting RoomType as Single (ACI-4671)

  The system now correctly updates room types to Single via the POST OTA_HotelInvNotif endpoint when the occupancy configuration is valid.

• Reservations API Cancellation messages with RoomStay element (ACI-4680)

  The system now returns cancellation messages without RoomStay elements again when calling the GET OTA_HotelResModifyNotif endpoint.

• Reservations API Missing confirmation XML messages (ACI-4682)

  The system now correctly returns confirmation XML messages for reservations again when using the Reservations API.

• Reservations API Missing cancellation XML messages (ACI-4687)

  The system now correctly returns cancellation XML messages again when using the Reservations API.

In this release cycle, we would like to introduce two new Request to Book API features. We've also added stateful testing for Payments by Booking Onboarding API. In addition, we want to bring your attention to a bug fix. Read on for more information.

• Request to Book API Introducing a new inventory-management model in Request to Book (RtB) 2.0

  Request to Book (RtB) 2.0 introduces a new inventory-management model. Unlike the existing 1.x versions, where availability was blocked only after a request became booked, RtB 2.0 requires connectivity partners to block availability as soon as a request is created. In addition to blocking availability, RtB 2.0 changes how payment and confirmation work for RTB requests.

  For more information, see RtB 2.0 overview and the Migration guide.

• Request to Book API Introducing guest withdrawals

  The API now enables guests to cancel their own pending booking request before the partner has acted on it. When this happens, the request moves to the WITHDRAWN_PENDING_APPROVAL status.

  This new feature applies to both INQUIRY flow (version 1.x) and RTB flow (version 2.x / RtB 2.0).

  For more information, see Handling guest withdrawals.

• Payments by Booking Onboarding API Enabling stateful testing

  Payments by Booking Onboarding API supports stateful testing. Providers can choose the Mock (stateful simulator) option when using the Try it option in the developer portal. See Payments by Booking Onboarding API.

  For more information on the Try it functionality, see About Try it.

• Reservations API Missing legacy reservation failover email alerts (ACI-4653)

  The system now sends legacy reservation failover email alerts again to configured providers when reservations are not picked up within 30 minutes.

In this release cycle, we do not have any updates for you.

In this release cycle, we do not have any updates for you.