Developer Community

Sort by

• Newest Reply
• Newest Topic

[Changes take effect on November 2, 2026]

Breaking changes

v2 property rules stop returning no_agreement on November 2, 2026

From November 2, 2026, GET v2/properties with include_rules=true and GET v2/properties/{id} no longer return rules.no_agreement. Read rules.agreement_rule and the other new fields below instead. A property that returns no_agreement true before the release returns agreement_rule not_required after it. Previously, no_agreement true meant the property's bookings signed no rental agreement.

Rental agreement, contact info and security deposit rules on v2 properties

The rules object on GET v2/properties with include_rules=true and on GET v2/properties/{id} has seven new fields. They say which booking sources are asked to sign a rental agreement, confirm their contact info and authorize a security deposit, and which agreement each source signs. Previously, rules held no setting by source, and no_agreement was its only rental agreement field.

Each source is a listing site id, the value a booking's listing_site_id holds and GET v2/listingsites returns. The id 999 (Any Custom Source) stands for direct bookings, which have no listing_site_id, and for the account's own custom sources. A list with no entries is left out of the response, as elsewhere in v2.

• agreement_rule says which sources' bookings sign a rental agreement: required (all sources), not_required (no sources) or required_except (all sources except those in agreement_listing_site_ids).
• agreement_listing_site_ids lists the sources whose bookings sign no rental agreement while agreement_rule is required_except.
• agreement_id is the rental agreement the property's bookings sign unless source_agreements gives their source a different one. The property keeps it while agreement_rule is not_required. It is left out when the property names no agreement.
• source_agreements lists the sources whose bookings sign a different agreement, each as a listing_site_id and an agreement_id.
• contact_information_rule says which sources' guests are asked to confirm their contact info, with the same three values.
• contact_information_listing_site_ids lists the sources whose guests aren't asked while contact_information_rule is required_except. A booking with a rental agreement to sign or a security deposit to authorize asks for contact info whatever these two fields say.
• security_deposit_listing_site_ids lists the sources whose bookings get no automatic security deposit. Other sources follow security_deposit_rule.

A booking signs the agreement these fields give its source:

• When agreement_rule is not_required, no source signs one.
• When agreement_rule is required_except, a source in agreement_listing_site_ids signs none. 999 in that list also excludes direct bookings and custom sources, except a custom source with its own row in source_agreements.
• Otherwise, a source with a row in source_agreements signs that row's agreement. A direct booking, or a custom source without its own row, signs the agreement in the 999 row when there is one.
• Every other source signs agreement_id.

No agreement is signed when the property names none, or when the agreement these fields pick is turned off or deleted.

GET v2/properties/16064

{
  "id": 16064,
  ...
  "rules": {
    "agreement_id": 4123,
    "agreement_listing_site_ids": [15],
    "agreement_rule": "required_except",
    ...
    "contact_information_listing_site_ids": [15],
    "contact_information_rule": "required_except",
    ...
    "security_deposit_listing_site_ids": [15, 999],
    ...
    "source_agreements": [
      {
        "agreement_id": 4188,
        "listing_site_id": 2
      }
    ],
    ...
  }
}

In this example, Airbnb (15) guests sign no agreement and aren't asked to confirm contact info. Vrbo (2) guests sign agreement 4188, and every other source signs agreement 4123. Airbnb bookings, direct bookings and custom sources get no automatic security deposit.

New GET v2/agreements endpoint

GET v2/agreements lists the account's rental agreements with id, name, description, active, created_utc and updated_utc, without the agreement text. These are the ids that agreement_id and source_agreements hold. The optional active parameter filters by status. Without it, the list holds both active and turned-off agreements and leaves out deleted ones. The endpoint is read-only, and there is no endpoint for a single agreement. Previously, the v2 API had no agreements endpoint.

GET v2/agreements?active=true

{
  "items": [
    {
      "active": true,
      "created_utc": "2025-04-02T15:12:40Z",
      "description": "Standard terms",
      "id": 4123,
      "name": "Rental Agreement",
      "updated_utc": "2026-09-18T20:05:11Z"
    },
    ...
  ],
  ...
}

Bookings and quotes made through the API follow the property's rules for their source

A booking made with POST v2/bookings or a quote made with POST v2/quotes takes these rules for its listing_site_id when it is made. One without a listing_site_id counts as a direct booking. Bookings made before November 2 keep the requirements they have.

• The guest signs the agreement the rules give the source, or none. The booking keeps that agreement when the property's rules or the agreement change later. Previously, each agreement's own property and listing site lists decided which bookings signed it, and a built-in agreement applied when none matched. A booking's agreement also followed later changes to the agreements until its guest signed.
• A source in security_deposit_listing_site_ids gets no automatic security deposit. Previously, a booking or quote made through the API took the property's security_deposit_rule whatever its source.
• The guest is asked to confirm contact info as contact_information_rule says for the source. Previously, every guest was asked.

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.

[Changes effective October 28, 2026]

Filter reviews by several properties

GET /v2/reviews now accepts property_ids, a comma-separated list of property ids, like the other list endpoints. property_id still works. A request that sends both gets the reviews of every property in either parameter. Previously, the endpoint ignored property_ids and returned the reviews of every property with a 200.

GET /v2/reviews?property_ids=123,456

Bug fixes

Request errors

• A query or route value that isn't a valid date now returns 400 with a message that names the parameter, such as 'notadate' is not a valid value for 'from'; expected a date/time. Previously, it returned 500.
• A query value that isn't a valid integer, number, true or false, or enum value now returns a 400 message that names the parameter and the values it accepts, such as 'abc' is not a valid value for 'property_id'; expected an integer. Previously, the message did not name the parameter.
• A 400 for a query value or request body that can't be read or fails validation now carries the code validation_failed and its doc_url. Previously, these responses had no code or doc_url.
• GET /v2/messages without threadId, GET /v2/fields and GET /v2/tags without entity_id or entity_type, DELETE /v2/tags/byname and DELETE /v2/fields/bydefinition without one of their required parameters, and GET /v1/guests without q now return 400 with one message for each missing parameter, such as A value for the 'threadId' parameter or property was not provided. A misspelled parameter, such as thread_id, counts as missing. Previously, these requests returned 405 with the code UnsupportedApiVersion, or 404, and the response did not name the parameter.

Lists filtered by since_utc

• GET /v2/fees, GET /v2/payments, GET /v2/refunds, GET /v2/inquiries and GET /v2/quotes with a since_utc filter now answer for the exact since_utc sent, to the millisecond. Previously, a request could get the cached response to an earlier request from the same account whose since_utc fell in the same second. That response could leave out records changed between the two values.

Breaking Change: Quotes now require a guest

[Change effective October 21, 2026]

POST v2/quotes now returns 400 guest_id is required unless test is true. when the request has no guest_id and isn't a test quote. Before this change, OwnerRez saved these quotes, but the guest couldn't book them: saving the Contact section of the quote's payment_form failed, so the form couldn't be submitted.

The same rule applies everywhere a quote is created or changed:

• POST v1/quotes without a guest now fails validation.
• PATCH v2/quotes/{id} can't remove a quote's guest.
• Existing quotes that already have a guest work as before.

Creating a bookable quote:

Create the guest first, then send its ID with the quote, as the Creating Quotes and Bookings article describes. POST v2/guests needs no fields, so you can create the guest before you know who the visitor is and fill in their details later.

{
  "property_id": 16064,
  "arrival": "2026-11-13",
  "departure": "2026-11-16",
  "guest_id": 9927183
}

Price checks:

To get pricing without creating a quote, send test: true. A test quote needs no guest, stores nothing and has no payment_form. Please don't create a guest for every price check: those guests fill the host's guest list.

Existing quotes without a guest:

Quotes that were saved without a guest have been deleted, along with their charges. No guest had booked any of them. Quotes that hold dates or that sent an email were kept. Requests for a deleted quote's ID, such as GET v2/quotes/{id}, now return 404. No webhooks were sent for the deletions.

[Patch 261021: changes effective October 21, 2026]

Owner bookings on every account

POST v2/bookings with type owner now works on every account. Previously, it required the Property Management module.

• OwnerRez sets an owner booking's contact: the owner assigned to the property for the arrival date or, when no owner is assigned for that date, the property's Owner Booking Contact, which the host sets on the property's General Info page. When neither applies, the request returns a validation error.
• An owner booking's contact changes only when its owner changes. PATCH v2/bookings/{id} that changes an owner booking's guest_id returns a validation error. Previously, the request changed the contact.
• An owner booking follows the property's owner-stay rules and needs no rate, and the check and custom payment windows do not apply to it. Previously, it followed the guest booking rules.

Webhook subscription validation

POST v2/webhooksubscriptions now returns 400 for a subscription that can never send a webhook. Previously, these subscriptions saved without an error.

• action must be entity_create, entity_update, entity_delete or application_authorization_revoked.
• An entity action needs a type that includes at least one of booking, guest, property, message, quote, inquiry, surcharge or discount.
• A category needs type to be exactly one of booking, guest or property, and must be a category that GET v2/webhooksubscriptions/categories lists for that type. Previously, an unknown category saved as no category, and the subscription received every change of its type.
• An application_authorization_revoked subscription stores no type or category.

Authorization revoked webhooks

When an account disconnects an application or closes, or the application revokes the connection's last token, OwnerRez sends application_authorization_revoked to the application's webhook URL and to the URL of each of that connection's application_authorization_revoked subscriptions, once per URL. URLs are compared case-insensitively. Deleting the application sends no revoke. Previously, the revoke went only to the application's webhook URL.

Bug fixes

Webhook subscriptions

• GET v2/webhooksubscriptions returns only the calling connection's subscriptions, and 401 to a personal access token. Previously, it returned every connected app's subscriptions, with their webhook_url.
• GET and DELETE v2/webhooksubscriptions/{id} return 404 for another connection's subscription and 401 to a personal access token. Previously, GET returned the subscription, and DELETE returned 401 or 500.
• category comes back as its name, such as "dates". Previously, it came back as a number, such as "7".
• GET v2/webhooksubscriptions/categories lists each category once. Previously, it listed transaction twice.
• The app owner email after a 410 Gone unsubscribe uses the webhook unsubscribed alert type. Previously, it used the webhook failed type.

Booking webhooks

• A subscription with category transaction gets scheduled transaction changes. Previously, it got none.
• A tag that a tag automation removed and put back is listed under related with "action": "entity_update". Previously, it was listed with "entity_delete".

Property search

• GET v2/propertysearch returns an empty list for an empty property_ids and ignores an empty include_tag_ids or exclude_tag_ids. Previously, each returned 500.
• GET v1/properties/search and GET v1/properties/searchandquote ignore an empty includedTagIds or excludedTagIds. Previously, each returned 500.

Calendar

• GET v2/calendar and GET v2/calendar/{property_id} mark a night orphan only when no stay can book it. Previously, they marked bookable nights orphan on properties that limit check-out weekdays, or where a spot rate allows an excluded weekday.

Deposits

• GET v2/deposits loads every page. Previously, some pages returned 500.

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.

[These changes were announced on October 19, 2026. The rate limit goes into effect on November 3, 2026 and the paging changes on January 5, 2027, both at 15:00 UTC]

Breaking Change: offset paging, unknown parameters and mismatched cursors are rejected from January 5, 2027

Every API v2 list endpoint (every response with items and next_page_url) is moving to cursor paging, and offset is now deprecated on all of them. From January 5, 2027 at 15:00 UTC, a list request with offset above 0 returns 400 with code offset_not_supported.

Bookings, deposits, fees, guests, inquiries, messages, payments, quotes, refunds and reviews return a cursor in next_page_url today. Every other list will switch from offset links to cursor links by November 16, 2026.

How to page a list:

Request the first page with no cursor or offset, then request the URL in next_page_url exactly as returned until next_page_url is null. This works today on every list, whichever kind of link it returns, so you can switch now.

• Don't build later page URLs yourself or read values out of next_page_url.
• Pages come one after another: a cursor can't jump to a page number or fetch pages in parallel.

GET /v2/bookings?property_ids=123&since_utc=2026-10-01T00:00:00Z&limit=100
{ "items": [ … ], "next_page_url": "/v2/bookings?property_ids=123&since_utc=2026-10-01T00:00:00Z&limit=100&cursor=eyJ…" }
GET /v2/bookings?property_ids=123&since_utc=2026-10-01T00:00:00Z&limit=100&cursor=eyJ…

With a cursor, rows added or deleted during a walk do not cause duplicates or gaps.

Also rejected on the same dates, on every API v2 endpoint:

• Unknown query parameters return 400 with code unknown_parameter. The parameters each endpoint reads are the ones its API reference page lists; check your requests against it now. The error names each parameter the endpoint doesn't read and, for common misspellings, the documented one. Today these are ignored: on /v2/spotrates, property_id instead of property_ids returns every property's overrides, and page=2 returns the first page. Request bodies aren't checked.
• Mismatched cursors return 400 with code invalid_cursor: a cursor the API didn't issue, or one sent with different filters from the request that issued it. Filters are every query parameter except cursor, limit and offset. Today the cursor is dropped and the first page comes back. Request next_page_url exactly as returned, and start again from the first page when you change a filter.

Brownouts:

Before January 5, all three fail with the same 400s during these windows:

• Tuesday, November 17, 2026, 15:00–16:00 UTC
• Tuesday, December 1, 2026, 15:00–19:00 UTC
• Tuesday, December 8, 2026, 15:00 UTC to Wednesday, December 9, 2026, 15:00 UTC

Details: Pagination & ETags and API errors.

Rate limit: 1,000 requests per 5 minutes per access token from November 3, 2026

From November 3, 2026 at 15:00 UTC, each API access token (an app's connection to an account, or a personal access token) may make 1,000 requests in any 5 minutes, whatever addresses the requests come from. This is in addition to the existing per-address limit. A request over either limit returns 429 with a Retry-After header giving the seconds to wait.

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.

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 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 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.

[Change effective October 14, 2026]

v2 properties now return each property's stay, booking window, and payment rules, plus audit timestamps and culture fields. Pricing and availability partners can read the same limits OwnerRez enforces, such as Max Availability, without scraping settings.

New rules object on v2 properties:

• GET v2/properties accepts a new include_rules query parameter (default false). Set it to true to add a rules object to each property in the list.
• GET v2/properties/{id} now always includes rules, tags, fields, and listing_numbers. It takes no include parameters.

rules contains:

• Stay and changeover: min_nights, max_nights, min_holiday_nights, min_weekend_nights, min_gap_nights, min_gap_nights_is_override, require_gap_nights, min_disallow_gap_nights, max_disallow_gap_nights, arrival_days, departure_days, weekend_type
• Booking window: min_hours_before_arrival, max_days_before_arrival, max_days_before_arrival_is_departure_blocked
• Policy: require_confirmation_for_online_bookings, cancellation_policy_id, quote_expiration_days
• Payments and holds: first_payment_rule, first_payment_amount, second_payment_rule, second_payment_days, security_deposit_rule, security_deposit_type, security_deposit_amount, security_deposit_days, security_deposit_release_days, security_deposit_release_remind_me, pending_hours_for_credit_card, pending_hours_for_check, pending_hours_for_custom, days_before_arrival_for_check, days_before_arrival_for_custom, pending_for, pending_action, send_payment_reminder, send_security_deposit_reminder, allowed_payment_mode, travel_insurance_rule, no_agreement

The API reference lists every field's description and the allowed values for the enum fields.

Example:

GET v2/properties?include_rules=true

{
  "items": [
    {
      "id": 16064,
      "time_zone": "America/New_York",
      ...
      "rules": {
        "min_nights": 2,
        "max_nights": 28,
        "require_gap_nights": 1,
        "arrival_days": "friday, saturday",
        "min_hours_before_arrival": 24,
        "max_days_before_arrival": 365,
        "max_days_before_arrival_is_departure_blocked": false,
        "require_confirmation_for_online_bookings": false,
        "quote_expiration_days": 3,
        ...
      }
    }
  ],
  "limit": 20,
  "offset": 0
}

Reading the booking window:

• max_days_before_arrival is how many days ahead a stay may arrive, counted from today in the property's time_zone (or the account's time zone when time_zone is null). min_hours_before_arrival is the minimum hours between now and arrival.
• The window limits arrival only. When max_days_before_arrival_is_departure_blocked is false (the default), a stay that arrives inside the window may depart after it, so nights past the window are not unavailable. When it is true, the departure must also fall inside the window.
• 365 is the default max_days_before_arrival, and many properties have never changed it.
• arrival_days and departure_days list the allowed days, comma-separated. Null allows any day of the week.
• All values are relative day and hour counts; no dates are computed for you. For per-night availability, use v2/calendar.

New fields on every property:

GET v2/properties and GET v2/properties/{id} now return:

• created_utc and updated_utc.
• display_culture: the property's culture override, such as en-US. Null when the property uses the account's culture. currency_code is unchanged and still returns the property's resolved currency.
• default_description_locale: the locale of the property's default listing description, such as en or fr, or null.

{
  "id": 16064,
  "created_utc": "2023-04-11T18:22:05Z",
  "updated_utc": "2026-10-02T14:09:51Z",
  "currency_code": "EUR",
  "display_culture": "fr-FR",
  "default_description_locale": "fr",
  ...
}

Listing numbers fixes:

• When a property is linked twice on the same channel, listing_numbers returns the newest link for that channel. Previously GET v2/properties/{id} returned an error for these properties.
• A link with a blank listing number no longer replaces a real number from an older link.
• The list and single property endpoints now return the same listing_numbers for a property.

[Changes effective October 7, 2026]

Create owner bookings through v2/bookings:

POST v2/bookings now accepts an optional type: booking, block, or owner. Omitting it behaves as before.

• Owner bookings require the Property Management module.
• The guest is always the property's owner contact. Don't send guest_id.
• generate_charges adds the property's surcharges and taxes but no rent. Surcharges limited to guest bookings are skipped.
• The owner contact gets no guest confirmation email.

{
  "type": "owner",
  "property_id": 16064,
  "arrival": "2026-11-13",
  "departure": "2026-11-16",
  "adults": 2,
  "generate_charges": true
}

Other changes:

• is_block still works but is deprecated in favor of type.
• PATCH v2/bookings/{id} can't change a booking's type.
• Guest bookings created through v2/bookings now get the property's cancellation policy.

Also jumping in to support this one - we have a workaround but it's fragile because it's based on parsing the review posted email. 

[Changes effective September 23, 2026]

Listing sites on v2 bookings and quotes:

POST v2/bookings and PATCH v2/bookings/{id} now accept listing_site_id, matching v2/quotes. Use the IDs from GET v2/listingsites.

• GET v2/bookings, GET v2/bookings/{id}, GET v2/quotes, and GET v2/quotes/{id} now return listing_site_id alongside listing_site.
• A PATCH that omits listing_site_id leaves the current value unchanged. Send null to clear it.
• An unknown ID returns 400 ListingSiteId X not found or not available.
• The listing site of a channel-linked booking or quote can't be changed or cleared. Sending its current value is accepted.

Payment form URL and redirect on v2 quotes:

The documented booking flow (create a quote, send the guest to its payment form, optionally redirect them after booking) now works on v2.

• Quote responses include payment_form, the URL of the guest payment form for that quote. It is null for a test: true quote.
• POST v2/quotes and PATCH v2/quotes/{id} accept redirect_after_booking_url, which overrides the property's after-booking redirect for that quote. It must be an absolute URL beginning with http:// or https://, 256 characters max. A blank value clears the override so the property's setting applies.

{
  "id": 123456,
  "property_id": 16064,
  "arrival": "2026-10-09",
  "departure": "2026-10-12",
  "payment_form": "https://...",
  "redirect_after_booking_url": "https://example.com/thanks",
  "listing_site": "Vrbo",
  "listing_site_id": 2
}

Charges and guest counts on v2 bookings:

• POST v2/bookings and PATCH v2/bookings/{id} accept generate_charges (default false). On create, the property's default charges are added and the property's rules are enforced (maximum occupancy, minimum and maximum nights). On update, the booking's existing charges are replaced with freshly calculated ones. It requires adults of at least 1 and is not supported for blocks.
• Both now also accept adults, children, infants, and pets.
• Bookings created through v2/bookings now get the property's currency and QuickBooks settings and, on property management accounts, the property's owner and commission, as bookings created in the app already did. These bookings now reach owner statements and QuickBooks.

Adding support for this. Confirming the data exists in OwnerRez but isn't exposed via the API — the Reviews spreadsheet export includes CleanlinessStars, CommunicationStars, AccuracyStars, CheckinStars, LocationStars, ValueStars (plus Booking.com-specific fields) and a Private Feedback column, while GET /v2/reviews returns only overall stars, body, and response. Would like to see both the sub-category scores and private feedback added to the API response. Private feedback in particular contains actionable guest requests that are invisible to any automated analysis today.

Anyone have made any progress here? I'm about to build my own integration and rather not start from scratch. BTW there is a commercial application in Beta: https://rentalhelm.com/

I haven't tested so I don't know if it exposes reservations in HA but it does manage locks, pool, and thermostats linked to HA using OR data. If anyone has tried it curious of any success

We've added a new calendar resource that returns computed per-night rates, booking rules, and availability in a single call, plus a GET for raw spot-rate overrides. Partners pulling pricing and availability separately can now replace both with one request per property page.

[Change effective September 16, 2026]

New Calendar endpoints:

GET v2/calendar - Calendar nights for multiple properties. Requires from and to (property-local calendar dates, inclusive); the range may not exceed 90 days. Accepts property_ids (comma-separated; unrecognized IDs are omitted from the result rather than erroring) and active (default true for active properties, false for inactive). Returns a standard paged list of properties, each with property_id, currency_code, and a days array.

GET v2/calendar/{property_id} - The same property envelope for a single property, with a maximum range of 366 days.

A night, not a day cell:

Each entry in days is one night - date through the following morning. Values are the effective result of seasons, spot rates, and rules already resolved for you; there is no live recalculation to do on your end.

{
  "property_id": 16064,
  "currency_code": "USD",
  "days": [
    {
      "date": "2026-07-03",
      "status": "available",
      "rate": { "rent": 275.00, "amount": 296.00, "season_id": 12345 },
      "rules": { "min_nights": 2 }
    },
    {
      "date": "2026-07-04",
      "status": "booked",
      "is_arrival": true,
      "is_departure": true,
      "booking_id": 987654,
      "rate": { "rent": 395.00, "amount": 419.00, "is_spot_rate": true },
      "rules": { "min_nights": 3, "is_gap_required": true },
      "holiday_name": "Independence Day"
    },
    {
      "date": "2026-07-09",
      "status": "gap",
      "gap_type": "orphan",
      "rate": { "rent": 275.00, "amount": 296.00, "season_id": 12345 },
      "rules": { "min_nights": 2 }
    }
  ]
}

Reading status:

Any value other than available means the night cannot be sold.

• available - Nothing occupies the night.
• booked - A guest booking or an owner booking occupies the night.
• blocked - An owner block, a linked-property block, or a quote hold occupies the night.
• gap - Vacant but not sellable, qualified by gap_type.
• unavailable - OwnerRez does not recognize the night's stored state. Treat it as not for sale.

The reverse does not hold: a night marked available can still be unsellable when rules.is_stay_disallowed is set. Sellability is status == available and no stay-disallow rule.

Rules versus gap analysis:

rules.is_gap_required is a rule - a setting in force for the night. status: gap with gap_type is analysis - the computed outcome of those rules against adjacent bookings, which you cannot derive from the rules alone. gap_type appears only when status is gap:

• required - The night is held vacant as an intentional turnover gap.
• orphan - The night is vacant but no valid stay fits it.

A night qualifying as both reports required.

Turnover days name two different bookings:

is_arrival and is_departure are date-edge facts, not facts about booking_id. On a turnover day both are true, and they refer to different reservations: is_departure is the prior booking leaving that morning, while booking_id is the incoming booking that occupies the night. The departing booking's ID does not appear on the row. booking_id is a reference only - fetch guest, charge, and door-code detail from GET v2/bookings/{id}.

Omitted fields and missing nights:

The response is sparse by design. Boolean flags are omitted when false, min_nights is omitted when 1, and the rate and rules groups are omitted entirely when there is nothing to report - so a vacant, unrestricted night is just {date, status, rate}. Treat an absent field as "not set", not as an error.

Nights with no calendar data are omitted from days, including nights past the property's booking window and nights before recorded history. A 200 with fewer days than you requested is expected, and when no nights exist for the range at all, days is omitted. Historical dates are supported; rate and rules may be absent on older nights.

New SpotRates endpoint:

GET v2/spotrates - Returns the raw per-night overrides you set through PATCH v2/spotrates, in the same model. The result is sparse: only nights carrying an override are returned. Accepts optional property_ids, from, and to, and is paged.

Use this endpoint to read back what you wrote. For the effective nightly price and rules a guest would see - seasonal rates, adjusters, and rule interplay already applied - use v2/calendar. The currency field is validated on PATCH only and is not returned on read.

Things to know before you integrate:

• Calendar data can lag a short time behind live changes. Confirm a night is genuinely free with the Quote or Booking endpoints before taking a reservation.
• There is no since or delta filter on either endpoint. Re-pull the ranges you care about.
• rate figures are nightly and exclude fees and taxes. For full stay pricing, use v2/quotes.
• All dates are property-local calendar dates with no time or UTC offset.

Owner bookings now appear in the Bookings API

[Change effective July 7, 2026]

OwnerRez now supports owner bookings — reservations that owners create to track their own stays at a property, distinct from guest bookings and from simple blocked-off time. These reservations flow through the same v2/bookings endpoints you already use, and they are identified by a new value on the booking type field.

The read-only type field returned on every booking can now be owner, in addition to the values it already returned. No new endpoint and no new query parameter — owner bookings are simply included in the normal responses and tagged for you to branch on.

• booking — A standard booking for a guest
• block — Block of time marked unavailable without a guest
• quote_hold — Hold the time as unavailable for a quote pending booking
• linked_availability — Block off the time as unavailable due to a linked property
• owner (New) — Owner booking

Owner bookings are returned by both GET v2/bookings (list) and GET v2/bookings/{id} (single), right alongside guest bookings and blocks. If you don’t want them, filter on type in your own code.

{
  "id": 3812044,
  "type": "owner",
  "is_block": false,
  "property_id": 16064,
  "guest_id": 9927183,
  "arrival": "2026-08-14",
  "departure": "2026-08-18",
  "adults": 2,
  "children": 1,
  "pets": 0,
  "status": "active"
}

Unlike a block, an owner booking is a full booking entity: it has a contact (guest_id), can carry charges, and participates in the same downstream features guest bookings do. Rent is excluded, but other charges (e.g. a cleaning fee) may still be present. Integrations that read a booking’s guest or charges keep working without changes — just be aware the record may represent an owner stay.

Every type value now carries its own description, so the meanings above render on the reference site and in the machine-readable OpenAPI spec. Code generators and agent tooling pick up the new owner value automatically.

Writes are unchanged for now
Creating and updating bookings still uses the is_block flag — there is no type parameter on POST/PATCH v2/bookings yet, so owner bookings can be read through the API but not yet created through it. We’ll announce write support separately when it lands.

We've rebuilt the API documentation from the ground up — a modern, server-rendered site that's just as readable by AI agents as it is by people.

[Change effective July 1, 2026]

A rebuilt documentation site:

The old auto-generated help pages are gone. Every endpoint now has a clean, server-rendered reference page at api.ownerrez.com/help/v2 — parameters, request bodies, response codes, and schemas, organized by resource in the sidebar.

Markdown for every page:

Every docs page is available as clean markdown — add .md to any endpoint URL, or use the "View as Markdown" link at the top of the page. A "Copy for LLM" button copies that markdown straight to your clipboard, ready to paste into an agent's context window.

A curated llms.txt:

We've published a hand-curated index at api.ownerrez.com/llms.txt, following the llms.txt convention, so AI agents can discover what the API offers and where to find it.

A machine-readable OpenAPI spec:

The full API is now described by an OpenAPI 3.0 document at api.ownerrez.com/openapi/v2.json. Point your code generator, Postman, or agent tooling at it for typed clients and request/response schemas out of the box.

Hello, I would like the API to be able to call review sub-categories.  

We've added full create, read, update, and delete support for surcharges and discounts. These are the fee and discount definitions that drive pricing across your properties — previously read-only via the API, now fully writable. Partners managing pricing programmatically (e.g. length-of-stay and last-minute discounts) can now do so end to end.

[Change effective June 3, 2026]

New Surcharge endpoints:

GET v2/surcharges - List surcharges. Accepts since_utc (delta sync), active (default true), type (repeatable for multiple types), category, mode, and property_id (surcharges applicable to that property, including "all"-scope ones).

GET v2/surcharges/{id} - Get a single surcharge with full detail, including scoping, criteria, and tiered amounts.

POST v2/surcharges - Create a surcharge. type and description are required; omitted fields fall back to the same defaults the app applies for that type. Covers cleaning, guest, pet, linen, and other fees, rate adjusters, and fully custom (complex) surcharges.

PATCH v2/surcharges/{id} - Update a surcharge. Only the fields you send change. type is immutable and cannot be changed after creation.

DELETE v2/surcharges/{id} - Delete a surcharge.

New Discount endpoints:

We've added a parallel set of endpoints for discounts — GET v2/discounts, GET v2/discounts/{id}, POST v2/discounts, PATCH v2/discounts/{id}, and DELETE v2/discounts/{id} — covering length-of-stay, last-minute, and early-bird discounts as well as promotions. Amounts and percentages are positive on the discounts endpoint, matching how they appear in the app. Each endpoint rejects the other's types, so fees go through v2/surcharges and discounts through v2/discounts.

Tiered amounts and criteria:

Both endpoints support tiered amounts (e.g. a length-of-stay discount with separate rates at 7 and 28 nights) and criteria-based rules (date ranges, nights, guest counts, and more). Surcharges can be scoped to specific properties, listing sites, and seasons. On PATCH, sending amounts or criteria replaces the full set.

New webhook types:

Surcharge and discount create/update/delete events now fire webhooks. Subscribe via the existing v2/webhooksubscriptions endpoint using the surcharge and discount categories.

Hi OwnerRez Team, I'm a property manager using OwnerRez to manage a short-term rental portfolio across multiple markets, and I've been actively building AI-assisted automation workflows on top of your v2 API. I love where the platform is heading and wanted to submit a formal feature request for two related enhancements to the API for Apps. ---  **Feature Request 

1: Writable Endpoint for Photo Captions** Currently, the v2 API allows reading property listing content (photos, amenities, descriptions, etc.) via GET /v2/listings and GET /v2/properties, but there is no way to programmatically write or update photo captions. Requested endpoint: PATCH /v2/properties/{property_id}/photos/{photo_id} With a request body along the lines of: { "caption": "Stunning Gulf-front master bedroom with king bed and panoramic water views." } This would allow property managers and developers to update captions without logging into the UI for each photo individually — particularly valuable for those of us managing portfolios of 5–10+ properties. --- **Feature Request 2: Writable Endpoint for Photo Sort Order / Reordering** In addition to captions, there is currently no API endpoint to change the sort order or sequence of photos for a property listing. This means photo reordering must always be done manually through the OwnerRez UI. Requested endpoint: PATCH /v2/properties/{property_id}/photos/order With a request body such as: { "photo_ids": [1042, 1038, 1055, 1041, 1039, ...] } ...where the array represents the desired display order (first item = hero/cover photo). Alternatively, a sort_order integer field on the photo PATCH endpoint above would also work: PATCH /v2/properties/{property_id}/photos/{photo_id} { "caption": "Bright open kitchen with quartz countertops.", "sort_order": 3 } --- **Why This Matters** Together, these two capabilities would unlock a powerful and practical automation loop: 1. Pull existing property photos from OwnerRez via the API 2. Use an AI tool (such as Claude) to analyze the photos, generate optimized listing captions, and recommend an ideal photo sequence based on STR best practices (e.g., hero shot first, outdoor/amenity shots sequenced for conversion) 
3. Write the captions and new sort order back to OwnerRez via API — no manual UI interaction required For property managers running multi-property portfolios, this could dramatically reduce the time spent on listing optimization and ensure captions are consistent, professional, and up to date across all properties and connected channels. Note: I'm aware that Airbnb-connected listings cap captions at 250 characters — that constraint is understood and can be respected in any automation built on top of this endpoint. --- Thank you for continuing to improve the API — it's one of the things that sets OwnerRez apart. I'd be happy to beta test either of these endpoints if that would be helpful. 
 Best regards, Gareth Bowen Rest & Enjoy Vacation Rentals info@restandenjoyvacationrentals.com

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.

Hello,

I am trying to add a logo to the title area of a property page, see attached screenshot. Is this possible? If so, how/where do I access the CSS/HTML to add the logo? And where do I upload the logo image to call it in the code?

Thanks,

Chris

Thanks for the response!

You're right that Airbnb's shift reduces the guest-fee side for one major channel. But Vrbo is still charging 6-15% to guests on top of the listing price -- on a $3,000 booking that's $180-$450 -- and there's no way to get the actual number through the API today.

Without it, integrations have to estimate. We use ~8% for Vrbo as a rough midpoint of their sliding scale, but the real fee varies per booking. That guesswork adds up across a portfolio and reduces the confidence we can put behind the numbers we show OR users. We end up labeling things "(est.)" throughout our UI and explaining the estimation methodology in our help docs -- all for a value OR already tracks.

The core issue is that anyone building financial reporting on top of the OR API can't answer "what did the guest actually pay?" with full accuracy. Whether that's us, another integration, or an owner pulling data directly -- the guest-facing fee is a gap in the picture.

To your point about where the industry is headed -- if every channel eventually goes host-only, the field just returns 0 for new bookings. No maintenance burden. But the historical data from the split-fee era will matter for YoY comparisons for a while, and Vrbo isn't there yet.

A read-only field on GET /v2/bookings/{id} would let any integration consuming booking data deliver more accurate reporting to OR users.

Thanks for the suggestion! I'm curious, do you think this is useful even though Airbnb no longer charges a guest fee?

We could certainly add it and it has relevance to Vrbo for now, but not Airbnb. I do not know where the industry is going to go as a whole, but Airbnb's move to place the entire fee on the host might result in other channels doing the same which would make this obsolete.

Agreed!

We've added write endpoints to the Quotes, along with new read endpoints for listing sites.

[Change effective April 1, 2026]

New Quote write endpoints:

POST v2/quotes - Create a new quote. Accepts fields including property_id, arrival, departure, check_in, check_out, expires_utc, adults, children, infants, pets, guest_id, notes, listing_site, and discount_code. Charges are generated by default (generate_charges: true). Set hold_dates: true to block off the dates on the property calendar.

PATCH v2/quotes/{id} - Update an existing quote. Set generate_charges: true to regenerate charges from scratch.

DELETE v2/quotes/{id} - Delete a quote.

Both POST and PATCH support a test parameter (default false). When test: true, the operation is fully evaluated and the resulting quote - including charges - is returned in the response, but nothing is persisted to the database. This is useful for previewing pricing before committing a quote.

Updates to existing quote endpoints:
GET v2/quotes now accepts an include_charges query parameter (default false). Set to true to include the charges array on each quote in the list.

GET v2/quotes/{id} now always includes the charges array.

New listing site endpoints:

We've also added endpoints for fetching available listing sites, which can be used to populate the listing_site field on a quote.

GET v2/listing_sites - Returns all listing sites. Accepts an active filter (default true). Each record includes id, name, domain, and active.

GET v2/listing_sites/{id} - Returns a single listing site by ID.

Hello ~ I'd like a way to run a report showing specific information about responses. I see this as a training tool for my co-hosts and KPI tool for my company. 
I would like to be able to sort: 
1. Who Responded (host, specifically which co-host, or automated)
2. Day and time of response (working hours vs after hours/weekends)
3. % of responses/communications during business hours vs after business hours, per person or automation
4. Timeliness of response
5. any other items that you feel would be useful to help break down KPI's 
6. Historical data view over days, weeks, months, and years. (especially over a monthly timeline).
7. Retroactive to show the past few years from the inception of this report.