Creating Quotes and Bookings

Currently, bookings can only be directly created via the Channel API. The App API can't directly create bookings since that requires the collection of credit card data. Instead, create a quote and send the guest the payment form link to complete the reservation process, and the credit card data will be collected via the standard reservation process.

• Pricing and quoting
• Creating the booking
  • Use the booking widget
  • Create a quote via API and get a payment form link for booking
• Device authorization

Pricing and quoting

If you want to calculate and display availability and rates on your own, you can use the availability and pricing endpoints to access that information.

If you want to run a test quote using the OwnerRez pricing engine, use the TEST verb to the quotes endpoint (required fields are PropertyId, Arrival, Departure, Adults, Children, Pets). This will validate the quote (unless you pass the skipRuleValidation or ignoreDateConflicts) and generate quote and charges, but return them only (rather than saving a quote in the user's account).

Creating the booking

There are two ways to do this. You can embed the booking widget on your site and let it manage the quote creation and guest redirect process, or you can use the API to create a guest and quote, retrieve the quote payment form link, and then redirect the guest to that URL yourself to complete the reservation process.

Use the booking widget

This is the simple way to implement bookings on a custom site, as no development is necessary. Create a booking widget and embed it on your site.

You can find more details in our Widgets Configuration support article.

Create a quote via API and get a payment form link for booking

This is a three (or four) step process. This is the same process as followed with a manually created direct booking, but automated via the API.

First, create a guest and get the guest id. Or if the guest has booked before, you can use an existing guest id. Next, create a quote for that guest, which will return a payment form URL. Finally, redirect the guest to that URL to complete the booking process. And optionally, you can define a post booking redirect URL so the guest will be sent back to your site after booking.

1) Create a guest

To create a guest, POST to the guests endpoint. No fields are required, so populate as much information as you have. The guest will be able to provide any missing contact information or adjust later on during the reservation process.

This will return the fields for the created guest including the id.

2) Create a quote

To create a quote, POST to the quotes endpoint (required fields are GuestId, PropertyId, Arrival, Departure, Adults, Children, Pets) -- example values used:

POST https://app.ownerrez.com/api/quotes
{
  "GuestId": 1234,
  "PropertyId": 5678,
  "Arrival": "2024-12-10",
  "Departure": "2024-12-15",
  "Adults": 5,
  "Children": 2,
  "Pets": 0
}

This will return the fields for the created quote including the PaymentForm. This is the URL to complete booking for the quote.

3) Redirect the guest to complete the booking

Direct the guest to the payment form link, either by a browser redirect, link, button, sending them an email, etc. A booking will be created when the guest completes the reservation process. Any system messages, triggers, etc. will be sent just the same as for a direct booking.

4) Post booking redirect (optional)

If you want, you can configure a post booking redirect so that the guest is sent back to your site after the booking is completed. There are two ways to configure this:

To configure the same URL for all bookings, navigate to Properties > the specific Property > Rules > Change > Payment Methods > and configure the Redirect After Booking URL  Redirect setting.
To configure a different URL for each booking, pass the RedirectAfterBookingUrl field when creating a quote. This will set a specific redirect after the booking URL for that particular quote.

Device authorization

Associate specific devices with a token by sending a POST request to /oauth/device_authorization with your client ID in the request body (using the form-urlencoded data type).

POST /oauth/device_authorization

Starts the device authorization flow ([link to] RFC 8628). Use this for CLI tools, agents, and other clients that cannot receive browser redirects. The client polls POST /oauth/token until the user approves the request on the verification page.

Authentication: HTTP Basic client_id / client_secret.

Body: application/x-www-form-urlencoded

• client_id (string, optional) — Your application's client ID. Optional when already authenticated via Basic auth; if sent, must match the authenticated client.
• scope (string, optional) — Requested access scope. read or full. Defaults to the app's default scope.

Response:

• device_code (string): Secret code the client sends when polling the token endpoint. Do not show this to the user.
• user_code (string): Short code for the user to enter on the verification page (formatted as XXXX-XXXX).
• verification_uri (string): URL where the user enters user_code and approves access (e.g., https://app.ownerrez.com/oauth/device).
• verification_uri_complete (string): Same as verification_uri with user_code pre-filled as a query parameter.
• expires_in (integer): Lifetime in seconds of device_code and user_code
• expires_on (string): UTC expiry instant for the codes in ISO 8601 format. Extension field beyond RFC 8628.
• interval (integer): Minimum polling interval in seconds before the first token poll (5 seconds). Increase wait time when receiving slow-down errors.

{ 
    "device_code": "dc_...", 
    "user_code": "B3KM-7X2P",
    "verification_uri": "https://app.ownerrez.com/oauth/device",    "verification_uri_complete": "https://app.ownerrez.com/oauth/device?   user_code=B3KM-7X2P", 
    "expires_in": 600,  /* always 10 minutes */
    "expires_on": "2026-06-12T15:30:00.0000000Z", 
    "interval": 5 
}