Latest Activity...
Patch 20250819
GET v2/bookings/{id}
New Query Parameter and model Property: include_drafts and is_draft on /v2/messages
[Change effective August 13, 2025]
We've added a new, optional query parameter to the GET /v2/messages endpoint, along with a new property on the message model. Possible query values are true or false. If no value is provided, draft messages will not be included in the result set.
Example:
GET /v2/messages?include_drafts=true
{
"items": [
{
...
"is_draft": true
}
],
"limit": 20,
"offset": 0
}
Breaking Change: sinceUtc parameter removed from /v2/messages
[Change effective August 13, 2025]
Long ago we deprecated sinceUtc on GET /v2/messages in favor of since_utc. We have now completely removed sinceUtc. Please use since_utc instead.
Two exciting new features to announce today, and one minor breaking change:
status filter to the bookings GETsinceUtc parameter from the bookings GET. Use since_utc instead.
New Property: entity on Webhooks
[Change effective August 6, 2025]
All webhooks now include a new property entity which contains an object representing the related record.
Example:
{
"action": "entity_update",
"categories": [
"other"
],
"entity": {
"adults": 1,
"agreements": [
{
"date": "2025-08-01T23:49:22Z",
"name": "Example Guest",
"url": "example"
}
],
"arrival": "2025-08-03",
"booked_utc": "2025-07-11T23:32:11Z",
"cancellation_policy_description": "Moderate: Free cancellation at least 5 days before check-in. After that, cancel before check-in and get a 50% refund, minus the first night and service fee.",
"charges": [
{
"amount": 1631,
"commission_amount": 0,
"description": "Rent",
"is_channel_managed": true,
"is_commission_all": false,
"is_expense_all": false,
"is_taxable": true,
"owner_amount": 1631,
"owner_commission_percent": 0,
"position": 0,
"rate": 1631,
"rate_is_percent": false,
"type": "rent"
},
{
"amount": 99,
"commission_amount": 0,
"description": "Management Fee",
"is_channel_managed": true,
"is_commission_all": false,
"is_expense_all": false,
"is_taxable": false,
"owner_amount": 99,
"owner_commission_percent": 0,
"position": 1,
"rate": 99,
"rate_is_percent": false,
"surcharge_id": 12345,
"type": "surcharge"
},
{
"amount": 300,
"commission_amount": 0,
"description": "Cleaning Fee",
"is_channel_managed": true,
"is_commission_all": false,
"is_expense_all": false,
"is_taxable": true,
"owner_amount": 300,
"owner_commission_percent": 0,
"position": 2,
"rate": 300,
"rate_is_percent": false,
"surcharge_id": 12346,
"type": "surcharge"
},
{
"amount": 154.48,
"commission_amount": 0,
"description": "Tax",
"is_channel_managed": true,
"is_commission_all": false,
"is_expense_all": false,
"is_taxable": false,
"owner_amount": 0,
"owner_commission_percent": 0,
"position": 3,
"rate": 8,
"rate_is_percent": true,
"tax_id": 1234,
"type": "tax"
}
],
"check_in": "16:00",
"check_out": "11:00",
"children": 0,
"created_utc": "2025-07-11T23:32:11Z",
"currency_code": "USD",
"departure": "2025-08-05",
"form_key": "example",
"guest": {
"first_name": "Example",
"id": 54321,
"last_name": "Guest"
},
"guest_id": 54321,
"id": 14380310,
"infants": 0,
"is_block": false,
"listing_site": "Airbnb",
"pets": 0,
"platform_reservation_number": "HMXXXXEX",
"property": {
"external_name": "Example House",
"id": 12345,
"internal_code": "Example House Code",
"name": "Internal Example House",
"public_url": "https://example.com/property/example-house/"
},
"property_id": 12345,
"status": "active",
"thread_ids": [
12345
],
"total_amount": 2184.48,
"total_host_fees": 60.9,
"total_paid": 2184.48,
"travel_insurance": {
"can_purchase": false,
"is_purchased": false
},
"type": "booking",
"updated_utc": "2025-07-11T23:45:53Z"
},
"entity_id": 12345,
"entity_type": "booking",
"id": "globally unique id",
"user_id": 12345
}
This feature should reduce the need to fetch the record details foreach webhook received. Please consider updating your integration to take advantage.
New Query Parameter: status on /v2/bookings
[Change effective August 6, 2025]
We've added a new query parameter to the GET /v2/bookings endpoint for booking status. Possible values are active, canceled, or pending.
Example:
GET /v2/bookings?status=canceled&since_utc=2025-08-01
{
"items": [
{
...
"status": "pending"
}
],
"limit": 20,
"offset": 0
}
This change should help reduce the number of requests needed to fetch a subset of bookings.
Breaking Change: sinceUtc parameter removed from /v2/bookings
[Change effective August 6, 2025]
Long ago we deprecated sinceUtc on GET /v2/bookings in favor of since_utc. We have now completely removed sinceUtc. Please use since_utc instead.
Breaking Change: PATCH /v2/users/me removed
[Change effective August 1, 2025]
We identified a potential attack vector related to patching user details. Upon thorough review we determined that this endpoint is not heavily used. Nor is there any evidence this vector has ever been exploited. We've removed the endpoint for now. If you need this endpoint for your purposes, please reach out to partner help to let us know your use case.
New Property: Is Snoozed on Properties
[Change effective July 23, 2025]
The GET v2/properties/{id} endpoint and GET v2/properties endpoint now include an is_snoozed property indicating that a property is "snoozed" to prevent new bookings.
Example:
"is_snoozed": false
Breaking Change: Uncategorized webhooks are no longer sent to categorized subscriptions
Some changes do not fall under any specific Webhook category. Historically, we sent such changes to all webhook subscribers of the related entity_type, even if the subscription was explicitly for only some categories. With the release on July 9, 2025, this is no longer the case.
We will now include the category "other" on any webhook which does not have an explicit category. In addition, subscribers who specify a category in their subscription will not receive webhooks with uncategorized changes. To receive webhooks for uncategorized changes you must now create an subscription with no category filter which will receive all webhooks for an entity_type.
Example Payload:
{
"id": 12345,
"user_id": 56789,
"action": "entity_update",
"entity_type": "property",
"entity_id": 12345,
"categories": ["other"]
}
Patch 250416
GET v2/property/{id}Patch 250521
GET v2/messages?thread_id={threadId}&since_utc={since_utc}&sinceUtc={sinceUtc} Patch 250528
GET v2/bookings/{id}
New Property: Travel Insurance information on Bookings
[Change effective April 2, 2025]
The GET v2/bookings/{id} endpoint and GET v2/bookings endpoint now include a travel_insurance property containing information about the availability of Travel Insurance for a specific booking.
Example:
"travel_insurance": {
"can_purchase": true,
"is_purchased": true,
"purchase_url": "sample string 1"
}
Hi Deb, thank you for writing in. Unfortunately, I don't believe you will be able to edit content within the widget iframe using JavaScript due to cross-origin restrictions. If you'd like to make a feature request for a separate property search URL from the public URL, you can do so by adding a post to our feature request forum.
Regarding the script here, I did not run into that error, but did have issues with a couple of other items. The first was that to use the url parameter in querySelector, backticks must be used instead of single quotes.const iframe = document.querySelector(`iframe[src^="${url}"]`);
The other issue is that to access the button in the iframe, it needs to be fetched from the iframe document. This would look something like the following:
const iframeDoc = iframe.contentDocument || iframe.contentWindow.document;if (iframeDoc) { const link = iframeDoc.querySelector('.btn.btn-default');
<your code>
Hi folks! I'm trying to update the href of the details button on the availability widget. I want to send it to a specific page when results come back and not to the page that is configured under the property URL. This is what I have so far
Hi, is there a way using javascript to update the link on the details button located in the availability widget? I have this so far:
const url = 'https://';
const iframe = document.querySelector('iframe[src^="${url}"]');
iframe.addEventListener('load', function() {
const link = document.getElementsByClassName('btn btn-default');
var txtQS = window.location.search;
var newURL='https://glencairnknoll.com/book-glencairn-knoll/' + txtQS;
link.setAttribute('href', newURL);
});
I'm getting this error in chrome: Uncaught TypeError: Failed to execute 'observe' on 'MutationObserver': parameter 1 is not of type 'Node'.
Breaking Change: v1.1 Quotes Arrival and Departure dates should not include time values
[Change effective February 12, 2025]
This is a validation change to the legacy v1.1 API. Prior to this change, if a user submitted a Quote value to v1/quotes containing Arrival and Departure dates that also included timestamps, we would not error but would attempt to store those time values. This caused problems downstream because Arrival and Departure are only intended to be timeless dates.
We have modified the PUT, POST, and TEST verbs on v1/quotes to validate that Arrival and Departure parameters do not include a timestamp. If a timestamp is included, a 400 error will be returned.
Patch 250212
GET v2/properties?include_fields=true
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!
Breaking Change: Required Field "currency" on SpotRates
[This change was announced on January 6, 2025 and goes into effect on March 1, 2025]
The PATCH v2/spotrates endpoint now requires currency to be explicitly specified for each rate. With this update, every rate entry must include a 3-character currency specification.
Example:
{
"property_id": 123,
"date": "yyyy-mm-dd",
"amount": 123.00,
"currency": "USD"
}
This change ensures the currency provided matches the property's configured currency. The purpose of this change is to avoid mis-pricing issues caused by differences in configuration between the rate supplier and OwnerRez.
You may begin sending requests containing currency immediately, but validation will only be enforced starting on March 1.
From March 1, any patch requests to SpotRates that do not include a currency value will result in an error. Additionally, any patch requests that contain a currency value different from the property's configured currency in OwnerRez will result in an error.
Hello developer community! Welcome to the API Change Log. This topic is dedicated to important updates about the OwnerRez APIs. We recommend you watch this topic to be alerted about changes that may impact your applications.
Happy coding!
I am also very interested in this. I have mulitiple HA connected properties and mutiple OR properties. I am happy to help test. I am not a coder but have done Product Management and have done a lot of work in the intersection of Short-Term Rental and Home Automation.
Can each of you that replied give a brief update of the current status? Does it make sense to coordinate a zoom call to discuss?
Hi Brittany & Andrew- It looks like there is a script loading on your site that causes a delay before the widgets and some other elements start loading. You can try removing scripts/plugins on your site one at a time to see if you can narrow down the culprit. If you need additional assistance with this, feel free to reach out to our Helpdesk.
If you have any suggestions for the widget design, consider sharing those on our feature requests forum. We always appreciate constructive feedback that helps us improve the app.
Any way to get the Embedded Widget to load faster? My widgets are taking 3-5 seconds to load on the page. Unfortunately, with the way the widgets are built, it doesnt look like I have access to the full code for the widget.
Im considering going the API route and building my own form for the website (the widget UI is a bit dated), but curious if anyone has found any other solutions before I do that.
Using WordPress with Elementor if it helps!
Taxes are not currently available, but you can get a single Surcharge from the legacy API: https://app.ownerrez.com/help/api/get-api-surcharges-id-get We've not yet ported this endpoint to v2.
I see that in the v2.BookingChargeModel there are a surcharge_id and tax_id exposed, is there anywhere to get the complete list of surcharges and taxes defined for a user?
Use case is- continuing to plod along on a chunk of middleware that ties ownerrez into xero. Currently have ownerrez pushing guests (and updates) into xero, now eyeing up the invoice generation side of things and eyeing up how to map the ownerrez (individual taxes listed as line items applicable to the entire invoice) to xero (tax category per line item).
Thanks for the clarification- the way that article was worded led me to believe that site was specific to channel integrations but it's exactly what I'm looking for!
- Brendan
To test your integration, register for an OwnerRez account on our stage environment.
This document outlines the info:
https://www.ownerrez.com/support/articles/api-channel-integration-setup-configuration#sandbox
I'm currently writing a wrapper for the API in ruby (with the ultimate goal of building a service to sync guest info and invoices into Xero-- maybe payments too if those become accessible. Just curious if there is a sandbox API I can use to test against or if I have to do it against my personal account.
Duh. I just found the "since_utc" parameter in the API, which is exactly what I needed. Never mind....
Here's the problem: I pull booking data for a date range, let's say daily or weekly or monthly and put it into SQL
Then, someone gives a refund to a guest a few days after checkout. My data is now obsolete.
The only way to avoid this that I can see is to continually pull old data in case it's changed.
Ideally, each record would have a "last modified" timestamp (I suspect this might already be the case, but only internally). The API would allow me to specify a "modified since" parameter, and only return data modified since that date. Then, I can update my data.
This would reduce the load on both servers, and provide a better "API experience"
Tim
Yes, since by definition if you manually entered a booking, we don't really know where it came from. There has been discussion over the years about adding "manual" as its own listing site entry, but that's never seemed quite satisfactory either.
I also found a booking with NULL listing_site. When I looked in OR it was a manual quote and manual booking that I had made. Is this also expected?
Tim
Yes, this is normal. Bookings booked through your own website don't have a platform reservation number, because they weren't booked on a booking platform (Airbnb, Vrbo, etc.) - they were booked directly on your website. The relevant number for them is the ORB number that all bookings of every type have, which is in the id column.
When using the API to retrieve bookings, AirBNB and VRBO come in with a correct platform_reservation_number.
But bookings made through my personal website have no reservation number
Here is a screenshot of the data dumped into Excel
Hey Tim,
I've done a bit of work on this, but it got put on the shelf during the holidays. Would love to collaborate with you and anyone else looking for this type of integration!
Best, Paul