Feature Requests

Sort by

• Newest Reply
• Newest Topic

Great suggestion—thanks for submitting! Know anyone else who'd benefit from this? Send them the link so they can add their vote and show there's interest in making this happen.

We've received your feature request—thank you! If you think others would love this too, spread the word and invite them to upvote. Community feedback really helps us prioritize what to build next.

Hi Alece,

That’s really helpful feedback, thank you!

Can you tell us a little more about how you’d use that in practice?

The main use case we had in mind for this feature was booking creation, where other processes often run in the background, such as generating a lock code or setting up a cleaning in a third-party system. In those cases, adding a short delay before sending a message makes a lot of sense.  So those items have time to populate before sending the message

So, when it comes to something like signing the rental agreement, I’m curious about your workflow. What’s happening in that moment where having a 10-minute delay before sending a message would make things easier for you?

We did start a bit more focused with this feature, both from a usability and technical standpoint, just to make sure we got the core use cases right first. That said, we’re not opposed to expanding it, especially if there are strong, repeatable use cases like what you’re describing.

Not pushing back at all, just want to make sure we fully understand the need so our devs can build this in the most helpful way.

Thanks!

Thank you so much! This is a game changer for us. 

This is great to see, Bri! 

I'm really hoping this will also be extended to events such as the rental agreement being signed. Being able to schedule an email for, say, 10 minutes after rental agreement is signed would be SO HELPFUL! 

We've adjusted the existing trigger condition (Code Generated Successfully) to wait for all door codes to generate. Now triggers wait until all door codes for a booking are successfully generated before firing.

We will likely expand on this in the future and add another condition for "Any Code Generated" as well, but that would come at a later date.

Today's release included the ability to create triggers that run a specific number of minutes before or after booking events, rather than just days. This allows more precise timing for pre-arrival communications and other time-sensitive messages, with options from 10 minutes up to 24 hours.

 It would be very helpful if the reservation number or guest name could flow through with the "new" Airbnb Host Fee into QuickBooks. As it stands, this requires quite a bit of manual work on our end. Currently the only information it pulls in is the posting date which is two days after the reservation arrival. That is confusing to both our team and our owners, and it is insufficient for accounting.

Great suggestion—thanks for submitting! Know anyone else who'd benefit from this? Send them the link so they can add their vote and show there's interest in making this happen.

Hey Douglas!

Typically, the API will override any changes made directly on the channel the next time it syncs. Can you please submit a ticket to help@ownerrez.com and let us know which property this is for so we can take a look?

We've received your feature request—thank you! If you think others would love this too, spread the word and invite them to upvote. Community feedback really helps us prioritize what to build next.

We’ve noticed that when an block is created in OwnerRez for an Owner Stay, it syncs to Breezeway as a “hold” instead of a stay. Because of this, Breezeway does not automatically generate a cleaning task, and our team has to manually schedule it.

Is there a planned update or workaround on the OwnerRez side that would allow Blocks to sync as Owner Stays so cleaning tasks can be triggered automatically?

This would greatly help reduce manual workload and improve efficiency.

[This topic has been merged with another topic (Read-Only Scope for OAuth Applications/API Access). All unique votes have also been merged.]

[Another topic was closed as a duplicate of this topic (Read-Only or Scoped Permissions for OwnerRez API Tokens)]

We're using the OwnerRez API to pull booking data, guest details, and compliance information into our internal operations system, and it has been working very well for us.

However, we've noticed that API tokens currently have full read/write access, with no way to limit permissions. For our use case, we only need read access. We never modify bookings, payments, or property data through the API.

Having a full-access token introduces unnecessary risk. If a token were compromised, or if a script contained a bug, it could potentially modify or delete data without any platform-level safeguard.

Would it be possible to add one of the following?

• Scoped API tokens — the ability to choose read-only vs. read/write when generating a token
• Role-based API access — tokens inherit the permissions of the user account that created them (for example, a user with a Viewer role would receive a read-only token)
• Per-endpoint permissions (this would be the best) — granular control over which API endpoints a token can access, such as GET only, with no POST, PUT, or DELETE access

Any of these options would help us follow the principle of least privilege and reduce our exposure. I imagine other property managers using the API for reporting, dashboards, and internal tools would benefit from this as well.

We are currently enforcing read-only access at the application layer. However, things could change in the future, or those protections could potentially be altered on our end, so we would appreciate the added safeguard of enforcing read-only access on the API side as well.

It's crazy to me that this is not possible!

I would also greatly benefit from Owner Rez recognizing automatically when payment have been remitted to owners directly already because of Airbnbs split payout/co-hosting model. A lot of my owners really appreciate being paid after every booking and I also prefer not to touch their money and just have my portion automatically paid out to me. Having to manually make this on each booking in OR is INCREDIBLY time consuming 😭. Please help! 🙏

Thanks, Alece! 

Your secondary ask there sounds like a bug to me, so I've asked our dev team to take a look. 

My company would be a perfect candidate for this integration. Currently, there are minimal hotels in our area and Marriott would benefit from having our home offerings that align with their brand.

I should mention during day-to-day ops, I spend most of my time on OR on an iPhone (mobile). So having in that cluster would be incredibly beneficial—particularly for mobile user layouts.

Recurring Triggers has already landed in testing, and we're steadily working out the quirks to get it release-ready as I write this. While I don't have an ETA to provide, we are very close!

Thanks for the recommendation! There are not many integrations we build out from the OwnerRez end. Typically, those partners write to us, not the other way around. We do have an open API, so if you know anyone on the HomeExchange or weneedavacation.com side, you can suggest they get in contact with us about developing an API connection.

While building a cancellation/date change directive, I created logic that branches based on whether a guest purchased travel insurance. In sandbox testing, Rezzy's interjection and certainty feedback explicitly stated things like:

• "I've verified the booking has no Travel Insurance Purchased tag and the Insurance tab would show 'No travel insurance has been purchased'"
• "The booking shows no travel insurance tag"

The problem is that, according to OR Support, Rezzy doesn't actually have access to this data. After testing with two bookings — one with insurance and one without — Rezzy returned the same "no insurance" result for both. It was confidently reporting verification of data it can't see.

OR support confirmed: "Travel insurance purchase status — including the Insurance tab data, policy details, and booking-level insurance tags — is not listed as part of Rezzy's available data sources."

The Request: Add Booking Tags and Insurance Data to Rezzy's Data Sources

For Rezzy to support directive logic around travel insurance (and other tag-based workflows), it needs access to:

• Insurance tab — purchased status, policy type, certificate number
• Booking tags — both custom and system-generated

These are standard fields visible on every booking. Adding them to Rezzy's data sources would unlock more reliable directive branching and increase the use-cases in which Rezzy can provide genuine, beneficial assistance. 

Secondary Ask: If Rezzy Can't Access a Data Source, It Should Say So

Right now, when Rezzy can't see a field, it fabricates a verification rather than acknowledging the gap. If a data source isn't available, Rezzy should respond with "I don't have access to this data" instead of generating a confident but false confirmation. This would save significant time during directive development and testing.

Screenshots attached: [See below — Rezzy's Sandbox interjection and certainty output claiming to verify insurance data OR says it cannot access]

Thanks for this suggestion! You're right that tag automation currently doesn't support cancellation events.

Current Capabilities: Right now, Tag Automations can automatically apply tags based on various conditions when bookings are created or modified (things like renter agreement status, payment status, pets, seasons, guest count, etc.), but cancellation isn't available as a trigger event.

Truthfully, A Cancelled booking already gets a tag applied by the system, also it is clearly colored differently on most lists.  And is a filterable condition in the majority of reports and other things.   So I believe this is why it is not part of the tag automation system.  

However, you can use the existing messaging trigger system to handle cancellations and staff workflows:

1. Create an immediate trigger with Event: Booking is canceled/deleted
   
   
2. Use this trigger to send notifications directly to staff members via email or SMS
3. You can include all relevant booking details in the notification

For example, check out the Notify Owner of a Cancellation Template and Trigger article - you can adapt this approach to notify any staff members who need to take action.

Here is a quick loom video showing how we currently mark a cancelled booking as well as a quick look at triggers:

Managing Cancelled Bookings and Third-Party Alerts - Watch Video

|

I also mention in the video the option of third party alerts.  They can be helpful if you want to send a simple notificiation to a team member whenever a booking is Created, Changed, or Cancelled.   Can read more about them here:  
https://www.ownerrez.com/support/articles/third-party-communications-options#third-party-alerts

Does the trigger-based notification approach work for your needs in the meantime?

When a guest cancels, we'd like to tag the booking for several staff actions.  I'd like to see the list of triggers for tag automation to include a cancellation.

I like this idea.  Not sure I would put it with the create booking 'cluster', but it is good to have easy access to the most used features. Is this one of them? When I do manual expenses, it is at the end of the month, all at once, so I'm hanging out in the PM > Expenses page. I'm not going there every day.   Let's hear from others with their votes and voices.

Hi Chelsea.  I like this idea, I'd vote for it.  Also, I know there is work ongoing on a new 'Guest Portal' that could ultimately become the best place for this type of interaction. No ETA available on that yet.

Hi Alece, this sounds like a good idea. I'd vote for it.  If you know anyone else who you think would value this function, get them to add their voice and vote.

Hi Randy,

Thanks for adding your perspective to this recently added report option. Hopefully, we can hear from other users to see their preferences

Know other OwnerRez users who would also benefit from this feature? Point them to your request to add their vote or voice!