Developer Community

Sort by

• Newest Reply
• Newest Topic

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

OR tracks the Guest Listing Site Fee (what Airbnb/Vrbo charge the guest) and shows it in the booking UI under Guest Balance -- but it's not available via the API.

Request: Add a read-only field like total_guest_listing_fee to the GET /v2/bookings/{id} response.

Why it's useful: Any integration doing booking analytics, revenue reporting, or direct-vs-OTA comparisons needs this number. Right now there's no way to programmatically get the full picture of what the guest actually paid.

Our specific use case is a "direct booking opportunity" report, but I'd imagine anyone building dashboards or guest-facing pricing tools would benefit.

- Jerry

Hi Dan,

Great question, and I completely understand why you’d want guest-facing links to stay on your own domain for consistency and trust.

At this time, OwnerRez doesn’t support hosting guest actions (like rental agreement signing or payment collection pages) on a customer-owned subdomain such as booking.redcanoelodging.com.

The main reason is security and compliance. Those pages can involve sensitive data (especially payments), and they must be served from OwnerRez’s secure, PCI-compliant infrastructure. Allowing them to load under a custom subdomain would introduce additional security and compliance complexity that we can’t support safely.

That said, there are still a few good ways to keep the guest experience feeling more “on brand.” For example, using your own domain for your Hosted Website or direct booking site keeps the shopping and booking flow on your brand domain up until the point the booking is made. Using a branded email sending domain also helps a lot, since guests see the message coming from your domain, which often builds more trust than the URL alone. And finally, a small tweak to the wording in your email templates can go a long way, clearly explaining that the link is taking them to a secure OwnerRez page for signing and/or payment.

I understand that outside of vacation rentals, some guests may be trained to be cautious of what looks like a third-party link. However, this is very common in the vacation rental industry. It’s not unusual for guests to be redirected to a secure vendor-hosted page to complete steps like signing a rental agreement or submitting payment. In fact, many competing systems don’t allow custom domains for guest-facing booking pages at all. With OwnerRez, your experience can stay fully branded through the shopping and booking flow, and then only switches to the secure OwnerRez page when it needs to. And those pages are still branded with your logo and information, so it typically reinforces your brand rather than diminishing it.

Most guests won’t find this unfamiliar, and a little bit of communication in your email templates can go a long way toward setting expectations, easing concerns, and maintaining a strong brand experience.

Hope that helps explain why the booking experience flows the way it does, and please let us know if you’d like suggestions on guest-friendly wording you can add to your templates. You can always reach our Helpdesk team at help@ownerrez.com

We've released several new endpoints for accessing financial information. These endpoints are read-only at present.

[Change effective January 14, 2026]

New Endpoints: Deposits

We've added GET v2/deposits and GET v2/deposits/{id} for fetching information about deposit/payout records.

New Endpoints: Fees

We've added GET v2/fees and GET v2/fees/{id} for fetching information about booking fees.

New Endpoints: Payments

We've added GET v2/payments and GET v2/payments/{id} for fetching information about guest payments.

New Endpoints: Refunds

We've added GET v2/refunds and GET v2/refunds/{id} for fetching information about guest refunds.

When I query the status page API (https://status.ownerrez.com/api/v1/components), I see 7 components listed, but I couldn't find an explicit "API" or "Booking Engine" component. The overall status shows "degraded", and the only active notice references Airbnb synchronization.

Is the Booking API affected by this incident? The status page notice only mentions "Airbnb synchronization," but I'm seeing 500 errors on the core Booking API, which seems unrelated to Airbnb.

My API Integration Details:

• Endpoint affected: POST https://api.ownerrez.com/v2/bookings (creating quotes/bookings)
• GET /v2/properties works fine
• Error persists across multiple retry attempts (5+ retries with exponential backoff)

I have also submitted a service ticket, but wanted to check if the general community had any additional observations.

Hi everyone,

As noted, I am building a custom direct booking site (Headless React/Node) and I have hit a specific architectural roadblock regarding PCI compliance and the "Merchant of Record" workflow.

My Goal: I want to collect credit card details on my site (using Stripe Elements) to maintain a seamless, on-brand UX, but I want OwnerRez to handle the actual charging and card storage.

• Ideal State: My site generates a Stripe Payment Method ID (pm_...) -> I pass this token to OwnerRez via API -> OwnerRez executes the charge and saves the card for future auto-payments (balance due).

• Constraint: I am trying to avoid a full page redirect to the hosted OwnerRez payment form if at all possible.

My Research So Far: Based on the API v2 documentation and previous forum discussions, my understanding is that this "Pass-Through" workflow is strictly blocked for standard API integrations due to PCI compliance. It appears that only certified Channel Partners (using the OLB API) are permitted to inject tokens or raw card data.

The Question: Is my assessment correct that there is zero capability in the current v2 API for a standard app to pass a payment_method_id or token to create a booking?

If I am mistaken, could someone point me to the specific endpoint or payload parameter that accepts a Stripe Token?

If I am correct (and this is impossible), I will proceed with building my own "Merchant of Record" logic (handling the Stripe charges and scheduling future payments on my own backend), but I wanted to double-check before I commit to rebuilding that entire billing engine myself.

Thanks for the clarification!

Hi everyone,

I am developing a custom direct booking website using the OwnerRez API v2. I need guidance on the correct workflow to convert a "Quote" into a confirmed "Booking" while ensuring OwnerRez handles the payment processing and card storage.

My Goal: I want OwnerRez to remain the "System of Truth" for all financials. I do not want to charge the card on my own backend and simply record a manual payment. Instead, I want to collect the card details on my site and pass them to OwnerRez to execute the charge and save the card for future scheduled payments (second payment, security deposit, etc.).

My Current Setup:

• Stack: Custom React/Node frontend.

• Processor: Stripe (integrated via OwnerRez).

• Flow: I am using Stripe Elements on my frontend to generate a Payment Method ID (pm_...).

The Question: Once I have the pm_... token from Stripe and a valid Quote ID from OwnerRez, which specific API endpoint sequence should I use?

I am looking for the equivalent of a "Process & Book" endpoint where I can send:

1. The Quote ID

2. The Stripe Payment Method Token

3. The Authorization to charge the deposit amount

Is the correct path to use POST /v2/quotes/{id}/book? If so, how do I format the payload to include the Stripe token so that OwnerRez:

1. Charges the deposit immediately.

2. Tokens/Saves the card to the guest record for the future balance due.

Any documentation references or JSON payload examples for this specific "Handoff" workflow would be greatly appreciated.

Thanks!