Latest Activity...
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:
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:
The Quote ID
The Stripe Payment Method Token
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:
Charges the deposit immediately.
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!
Hi Dan,
Great question, and you’re thinking about this exactly the right way.
There isn’t a standalone “lookup” endpoint just to validate discount codes on their own. The intended workflow is to pass the discount code into the pricing engine and let OwnerRez evaluate it in the context of the stay details.
You don’t have to create a real quote just to do this. The recommended approach is to use the TEST verb on the quotes endpoint.
When the guest enters a code like SAVE10, you can:
Call TEST /v1/quotes
Include the stay details in the request body
Pass the discount code as a query parameter, for example: ?discountCode=SAVE10
The TEST call runs full pricing and returns the calculated charges without saving anything. If the code is valid for the property, dates, and rules, you’ll see the discounted pricing reflected in the response. If it’s not valid, the pricing will come back unchanged or the response will indicate it couldn’t be applied.
When the guest is ready to book, you make the normal POST /v1/quotes call using the same approach. The discount code is again passed as a query string parameter, not as a field in the Quote JSON model. That’s why you won’t see it listed as a property in the API documentation.
In short:
There’s no separate discount code lookup endpoint
Use TEST quotes to validate and preview pricing
Pass discountCode in the query string, not in the request body
Reuse the same parameter when creating the actual quote
This is outlined more in this support doc:
https://www.ownerrez.com/support/articles/api-quote-bookings
And the endpoints used are in the API Docs here:
https://api.ownerrez.com/help/v1/Api/TEST-v1-quotes_addCharges_skipRuleValidation_ignoreDateConflicts_discountCode
Hope that helps! If you need any more info let us know!
Hi there,
I'm working on a direct booking site and I'm stuck on the logic for discount codes.
When a guest enters a code (e.g., "SAVE10") in my checkout form, I want to validate it and update the total price immediately.
Does the API support a "lookup" endpoint to check if a code exists and is valid for the dates? Or is the standard workflow to simply push the code into the createQuote / updateQuote payload and handle the error if OwnerRez rejects it?
If it's the latter, could you point me to the specific property name I should include in the Quote model? I haven't been able to spot it in the swagger docs.
Thank you!
I submitted a support ticket for this item, but is there a way to set up a subdomain for any direct interaction a guest might have with OwnerRez? For example, when completing the rental agreement, instead of sending an email with the short OwnerRez link, can it be configured to use a subdomain? (e.g., booking.redcanoelodging.com)
Using multiple domains for guest interactions can be confusing and may undermine trust, especially when a guest has made a direct booking.
Hi Dan!
The right endpoint to use would be the v1 properties endpoints, for example, https://api.ownerrez.com/help/v1/Api/GET-v1-properties_paymentMethodId_active
which will include fields such as these:
"securityDepositRule": 1,
"securityDepositType": 0,
"securityDepositAmount": 1.0,
"securityDepositDays": 1,
"securityDepositReleaseDays": 1,
"securityDepositReleaseRemindMe": true,
in each Property object (https://api.ownerrez.com/help/v1/ResourceModel?modelName=Property).
The v2 API property endpoint doesn't yet include this information.
Hope that helps!
What is the correct endpoint to call to get for a property:
1) Security deposit amount
2) Hold information
3) Release details
Thanks much!
New Property: removed_utc on Message
[Change effective Dec 17, 2025]
Messages that are removed by the host or guest will now include a timestamp removed_utc. Messages that have been removed will not include previous body or attachments.
Example:
{
"body": null,
"attachment_urls": null,
"removed_utc": "2025-12-17T12:32:53.7919007Z"
}
New Property: Time Zone information on Property
[Change effective Dec 9, 2025]
The GET v2/properties/{id} and GET v2/properties endpoints now include a time_zone property containing the IANA time zone of the property. If the property time zone is null, the user time zone should be inferred.
Example:
"time_zone": "America/New_York"
New Query parameter and Model property: include_attachments and attachment_urls on POST /v2/messages
[Change effective November 19, 2025]
We've added a new, optional query parameter include_attachments to the GET /v2/messages endpoint, along with a new property attachment_urls on the message model. Possible query values are true or false. If no value is provided, message attachments will not be included in the result set.
Note that URLs are temporary and will expire after a set time.
Example:
GET /v2/messages?include_attachments=true
{
"items": [
{
...
"attachmnet_urls": [ "https://orez.io/...." ]
}
],
"limit": 20,
"offset": 0
}
New Model property: attachment_url on POST /v2/messages
We've also added a new property attachment_url to the POST /v2/messages endpoint, so you can send attachments in your messages. Please note that only one image up to 5MB is supported per new message at present. The URL must be publicly accessible in order for us to retrieve the image and add it to the thread.
Example:
POST /v2/messages
{
...
"attachment_url": "{your-publicly-accessible-image-url}"
}
We've added a new feature when creating a new OAuth App. In the setup page, when first creating an app, you will be automatically opted into receiving updates when we post to the API Change Log or API Bug Fix developer forum topics.
Users can always opt out by unchecking the field, or later by unwatching the forum topics.
This checkbox will only show up when creating a new OAuth App. Developers with an existing app will need to opt into these forum topics manually.
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.