API Bug Fixes

Hello developer community! Welcome to the API Bug Fix Log. This topic is dedicated to documenting bug fixes for the OwnerRez APIs. You may watch this topic if you are interested in being alerted about fixes that may impact your applications.

Happy coding!

Patch 250212

• GET v2/properties?include_fields=true
  Bug: An error was returned if any property in the result set had a total length of custom field values exceeding 16kb.
  Fix: We've increased the maximum to 256kb.

Patch 250416

• GET v2/property/{id}
  Bug: Incorrect Booking.com Room ID included in response body.

Patch 250521

• GET v2/messages?thread_id={threadId}&since_utc={since_utc}&sinceUtc={sinceUtc}
  Bug: Airbnb request-to-book (RTB) threads did not include the related quote ID.

Patch 250528

• GET v2/bookings/{id}
  Bug: Some bookings with related door codes were causing HTTP 5xx errors.

Patch 20250819

• GET v2/bookings/{id}
  Bug: Currency code was not always populated on bookings fetched singly by Id.
  Fix: We will now populate Currency code from the property or user configuration if not specified explicitly on the booking.

Patch 260513

• GET v2/payments/{id} and GET v2/refunds/{id}
  Bug: Both return is_deposited: false for payments/refunds that were marked deposited via the Deposits → Batch Update tool (or any "Mark as Deposited Elsewhere" path)
  Fix: Both now return the correct deposit status for transactions marked deposited elsewhere.

Patch 261014

Calendar date filters on v2 and v1 endpoints

• v2: GET v2/guests and GET v2/bookings from/to; GET v2/calendar, GET v2/calendar/{property_id}, and GET v2/spotrates from/to; GET v2/propertysearch available_from/available_to; GET v2/properties availability_*
• v1: bookings and listings availability, listings pricing, properties GET/lookup/search/searchandquote, and quotes expiresNotUtc

Bug: A date sent with a time or UTC offset was converted to UTC before it was compared with stay dates, which could shift it to another day. GET v2/guests?from=2026-03-01T00:00:00-05:00 filtered from March 1 at 05:00 and left out a guest departing March 1. to=2026-03-01T00:00:00+14:00 became February 28 and left out a guest arriving March 1. A time with no offset, such as 2026-03-01T12:00:00, also left out boundary stays.

Fix: These parameters now use the calendar date as written and ignore any time or offset. 2026-03-01, 2026-03-01T12:00:00, 2026-03-01T00:00:00-05:00, and 2026-03-01T00:00:00+14:00 all filter on March 1 in the property's time zone. Numeric dates are read month-first (03/01/2026 is March 1). A value that is not a date returns 400: '{value}' is not a valid value for '{param}'; expected a date/time.

Timestamp parameters such as since_utc and created_since_utc are unchanged and still convert to UTC.

Patch 261012

Booking.com reservations in GET v2/bookings and webhooks

Bug: New, changed, and canceled Booking.com reservations, and the holds created for them, were saved without committing. GET v2/bookings sent with the last ETag returned 304 Not Modified until another booking change on the account. Webhooks reported a new Booking.com booking only as entity_update. Linked properties stayed open for those dates for up to 10 minutes.

Fix: Each Booking.com reservation now commits as soon as it is pulled. The bookings ETag changes right away, and linked properties are blocked right away.

Webhook changes:

• A new Booking.com booking now sends entity_create.
• Booking.com holds (blocks titled "Hold for <reservation id>:<room id>", is_block: true) now send entity_create, entity_update, and entity_delete webhooks. Filter on is_block or type to skip them.

Patch 261015

Resolved occasional errors on /v2/deposits endpoint

Bug: The /v2/deposits endpoint was occasionally producing code 500 errors, especially for users with large numbers (hundreds) of deposits.

Fix: These errors should no longer occur for anyone.

Patch 261014

GET v2/properties?include_fields=true

Bug: When a property's custom field values changed and nothing else on the property did, such as a save on the property's Fields page, the response kept the old field values for up to 16 hours, until the next change to any property on the account. A change to a field definition's code had the same delay.

Fix: Custom field value and field definition changes now show in the next response.

The list ETag still tracks only property records, so a request sent with If-None-Match can return 304 Not Modified after a change to custom fields alone. To pick up those changes, send the request without If-None-Match.

GET v2/calendar orphan gaps on properties with set check-out days

Patch 261021

Bug: GET v2/calendar and GET v2/calendar/{property_id} returned status gap with gap_type orphan for open nights a guest could book, on two kinds of property:

• Check-out limited to certain weekdays. With check-out allowed on one weekday only, every open night read as an orphan gap. For example, an open Saturday-to-Saturday week on a Saturday-only property with a 7-night minimum.
• A spot rate allowing check-in or check-out on a weekday the property's rules exclude.

Fix: A night is now an orphan gap only when no stay can book it under the property's check-in, check-out, and minimum stay rules, including spot rate overrides. Check-out is checked on the departure date, as booking does. Nights in an opening shorter than the minimum stay still return orphan.

The API reference now says is_arrival_disallowed and is_departure_disallowed bar check-in and check-out on the night's own date, and defines the required and orphan gap types.

Since October 28, 2026, API bug fixes are posted in the API Change Log topic together with new features and other API changes. This topic will receive no further updates. Follow the API Change Log topic for future bug fixes.