Creating Bookings, Blocks and Quotes

Your app can put four types of items on a host's calendar: a guest booking, an owner stay, a block, or a quote that holds dates until the guest pays. This article covers which one to create, how to create it, and what happens next.

You need a write-capable token for everything here.

• Pick the Right One
• Quotes
  • Create a quote and send the guest to pay
  • Hold the dates while the guest decides
  • Other quote options
• Bookings, owner stays and blocks
  • Guest booking
  • Owner booking
  • Block
  • Rules for POST /v2/bookings
• What happens next
• Pricing without creating anything
• Don't want to build a checkout?

Pick the Right One

A quote runs the host's pricing, rules, payment schedule, agreements, and messages, exactly like a booking made on their website.

Quotes

Create a quote and send the guest to pay

1. Create the guest, or reuse one you created. POST /v2/guests always creates a new guest and returns its id. No fields are required; the guest can fill in the rest at checkout. Store that id with the person in your app and send it again for their next stay. Don't use GET /v2/guests?q= to find someone by email: q matches every guest whose details contain each word in it, so q=jane@example.com also returns jane.doe@example.com.

2. Create the quote.

   POST https://api.ownerrez.com/v2/quotes
   {
     "guest_id": 1234,
     "property_id": 5678,
     "arrival": "2026-12-10",
     "departure": "2026-12-15",
     "adults": 4,
     "children": 2,
     "pets": 0,
     "hold_dates": true,
     "redirect_after_booking_url": "https://example.com/thanks"
   }
   

   The response includes payment_form, the link where the guest reviews the quote and books.

3. Send the guest to payment_form. Redirect them, link to it, or email it. When they finish, the booking is created, with the same system messages and triggers as any direct booking. The booking's quote_id points back to your quote.

4. Optional: bring them back. redirect_after_booking_url in the quote's POST body sends the guest to your site after they book.

Hold the dates while the guest decides

Without hold_dates, a quote doesn't block the calendar, so someone else can book those dates first, and the booking arrives as a new booking (a create webhook) when the guest pays. With "hold_dates": true:

• The dates show on the calendar as a quote_hold.
• The quote's expires_utc is when the hold lapses: by default, the end of the day in the property's time zone, a number of days after quoting set by the host's quote expiration setting.
• When the quote expires or is declined, the hold is released: its status becomes canceled.
• When the guest books, the hold becomes the booking. Same id, type changes to booking, and you get an update, not a create.

hold_dates only works when you create the quote. Setting it on an update does nothing.

Other quote options

Bookings, owner stays and blocks

All three use POST /v2/bookings. Set type to booking, owner or block. (is_block still works but is deprecated. Don't send both.)

Guest booking

"type": "booking" needs a guest_id. The booking is created with no charges unless you pass "generate_charges": true, which calculates charges from the host's pricing. The API doesn't record payments: collect them yourself, or use a quote so the guest pays through OwnerRez.

Owner booking

"type": "owner" records the owner staying. The host's account needs Property Management turned on; otherwise the request fails with "Owner bookings require the Property Management module." Don't send guest_id; the request fails if you do. OwnerRez uses the owner contact for the property and arrival date, and fails the request if the property has none; the host sets that up in OwnerRez.

OwnerRez doesn't send the guest booking confirmation, because the owner is the guest. The host's triggers run as they do for any booking, unless a trigger's Booking Type condition leaves owner stays out. The host gets the usual new-booking alert either way. Charges are optional, as for a guest booking.

Block

"type": "block" closes the dates. Put the reason in notes (500 characters at most). Blocks have no charges and no check-in or check-out times.

POST https://api.ownerrez.com/v2/bookings
{
  "type": "block",
  "property_id": 5678,
  "arrival": "2026-11-03",
  "departure": "2026-11-06",
  "notes": "Deck repair"
}

departure works like a checkout day: it's the day after the last closed night. This example closes the nights of November 3, 4, and 5.

Rules for POST /v2/bookings

• Dates must be free. If anything else holds those dates on that property (a booking, a block, a pending hold, a quote hold), the request fails with a validation error.
• Stay rules apply only when we price it. With generate_charges, the property's minimum and maximum nights and occupancy are enforced, and adults must be at least 1. Without it, they aren't checked.
• You can't change type through the API. You can update dates, guest counts, notes and other fields with PATCH /v2/bookings/{id}. OwnerRez changes a hold's type itself when it becomes a booking.
• No cancel or delete. The API can't cancel or delete a booking or block. The host does that in OwnerRez.
• Check before you retry. If a create times out, look for it with GET /v2/bookings for that property and those dates before you send it again, or the retry fails on the dates the first one already took.

What happens next

• Your changes come back as webhooks. Everything you create or update arrives at your webhook URL like any other change. Apply them like any other webhook.
• Channels update on their own. A booking or block you create closes the dates on the host's connected channels, the same as one made in OwnerRez.

For how to read the calendar and react to changes, see Keeping Availability in Sync.

Pricing without creating anything

To show availability and prices yourself, use the calendar and listings endpoints, or create a quote with "test": true.

Don't want to build a checkout?

Embed the host's booking widget on your site. No development needed.