Loading...
This reference lists what Haven currently reads from OwnerRez, what Haven writes to OwnerRez, which OwnerRez webhooks Haven uses, and the important limits of each path.
For connection instructions, see Connect OwnerRez to Haven.
Haven reads supported:
Haven writes:
Haven does not write the following to OwnerRez:
Guest reviews sync from OwnerRez only when the account has the WordPress Plugin + Integrated Websites add-on. Even with the add-on, Vrbo reviews are never included: Vrbo does not pass guest reviews to OwnerRez, so they cannot reach Haven this way. Bring Vrbo reviews in with Import reviews (screenshots or copied text) on the Reviews & Testimonials tab. See Import Reviews.
Haven imports these values when OwnerRez supplies them:
max_guestsbedroomsproperty_space_type value: entire_home, private_room, shared_room, or hotel_room
entire_home becomes Haven's entire_place; the other recognized values keep their equivalent Haven typecheck_incheck_outmax_pets
currency_code
OwnerRez listing.rooms populate Haven sleeping spaces: room name, mapped room type, and a per-room bed count (total_beds). OwnerRez does not send bed types, so the public card shows "N beds". OwnerRez does not say which photo is in which room, so every photo stays the host's to move. Each OwnerRez room is sync-locked (Haven never adds a space beside the ones OwnerRez sends): its name and bed count follow OwnerRez. A host who unlocks a room can rename it, replace the count with typed beds, merge it and delete it (it is not recreated by later syncs); later syncs leave an unlocked room alone. See Sleeping Arrangements.
Only rooms whose OwnerRez type maps to Haven's vocabulary are imported. Listing-content rooms require the WordPress Plugin + Integrated Websites add-on.
Haven imports:
OwnerRez does not send a preformatted address string, so Haven formats the address from the supplied parts.
Haven maps only close equivalents:
pent_house → ApartmentOwnerRez types without a clear Haven equivalent are not guessed. The Haven property-type field remains unsupplied and editable.
Everything in this section — public descriptions, Wi-Fi, amenities, photos, room details, and the cancellation-policy text — comes from OwnerRez's Listing Content API. OwnerRez only exposes that API when the connected account has the WordPress Plugin + Integrated Websites add-on enabled (a paid OwnerRez premium feature).
If the add-on is not enabled, none of the enrichment below imports. Haven still imports the core property record (title, address, rooms, bed/bath counts, max guests, check-in/out times, property type, pricing, fees, reservations, and availability), but photos, descriptions, and amenities are left empty and editable. To enable it, turn on WordPress Plugin + Integrated Websites in your OwnerRez account's Premium Features, then reconnect or wait for the next scheduled sync.
When available, Haven maps:
Haven imports:
These values remain protected by Haven's normal guest-access rules.
Some OwnerRez listing values may be validated or retained in integration metadata but do not currently populate a Haven field. These include:
total_beds does populate Where you'll sleep as "N beds")Haven reads OwnerRez amenity categories and amenity call-outs in their listed order, removes duplicates, and maps recognized amenity text to Haven amenity fields.
An OwnerRez amenity without a known Haven equivalent is recorded in sync diagnostics but is not forced into an unrelated Haven amenity.
For each OwnerRez listing photo, Haven uses:
Haven downloads synced OwnerRez photos into Haven's image storage. OwnerRez photos are matched by URL because OwnerRez does not provide a stable photo ID.
Your OwnerRez photo order drives your Haven page: the first photo becomes the Haven cover, the next three fill the story cards, the following ones run as full-width strips, and the rest fill the gallery in the same order. Bathroom and utility shots, and portrait photos, are kept out of the full-width strips when a better photo is available — they move a few places down, nothing is removed. Haven only re-curates your photos when you ask it to (Sort by AI in Photos & Spaces); Use listing order puts your OwnerRez order back at any time.
Photo behavior:
video_url values are not imported as Haven videos.OwnerRez supplies cancellation policy as free text rather than Haven's structured refund tiers.
Haven attempts to convert that text into the same structured cancellation rules used by Haven's policy editor.
Haven does not guess a structured cancellation policy when the text cannot be confidently interpreted.
Haven reads active OwnerRez surcharge and discount rules for each imported property. A rule is mapped only when Haven can charge it the same way OwnerRez does — the amount is never invented, rounded, or guessed from a nearby field.
OwnerRez often stores a guest, pet, cleaning, or management charge as a general rule with an income category rather than a dedicated fee type. Haven reads that category the same way it reads a typed fee, so those rules still land on the matching listing field.
For a mandatory rule to be eligible it must be active, use automatic mode, have no custom criteria (with one exception: a date-limited extra-guest rule, covered below), and apply to bookings on your own website: either every listing site (or no listing-site restriction), or a listing-site list that includes your website. Haven recognizes your website as the OwnerRez listing site whose domain matches your Haven custom domain, so a cleaning fee you limited to Vrbo, Airbnb, and your own site still applies to Haven bookings. A rule limited only to other channels (for example an Airbnb-only rate adjustment) is not charged. Flat fees, length-of-stay discounts, early-bird and last-minute discounts, and named custom fees also need to apply year-round. Extra-guest and pet charges may be tagged to a season in OwnerRez; Haven still imports the published per-unit amount onto the listing occupancy field, because those columns have no season calendar of their own.
Haven maps fixed per-stay rules onto:
Management and community fees also accept a percent of rent. The sync writes that rate and sets the field to % so a leftover flat amount cannot sit next to a freshly synced percentage. A percent cleaning or linen charge has no matching column and is imported as a named custom fee instead.
Your service fee ("keep the margin") is Haven-only and is never synced — see Your Service Fee (Keep the Margin).
Haven maps one pet-fee rule per property when there is no free-pet allowance and no grouped increment:
An OwnerRez cap (for example, "up to two pets") is accepted. Haven has no pet cap of its own, so the imported amount is the per-unit charge guests see.
Haven maps one extra-guest rule when it is a fixed amount charged per night for each additional guest or adult, in groups of one. OwnerRez's included-guest count becomes Apply after this many guests. A cap or a named-season include list does not block the import — those constraints have no home on the year-round field, and dropping the rule would leave the extra-guest field empty while OwnerRez still billed it.
A guest-fee rule limited to explicit dates maps further: it becomes one or more seasonal extra guest pricing windows instead of the year-round field. An arrival-date range produces a window with those exact dates; a month-of-year restriction produces windows for the current year and the next, refreshed on each sync. The included-guest count becomes the window's guest threshold, and an OwnerRez cap ("up to 15 guests") becomes the window's billing cap. The rule must carry exactly one date criterion and an explicit included-guest count; anything Haven cannot prove — an added minimum-night condition, a named season alongside the dates, a missing threshold — stays unmapped and is surfaced on the sync record rather than billed approximately.
Windows written by the sync are marked as OwnerRez-managed in the pricing editor and are replaced whenever the rule changes in OwnerRez. Windows the host creates in Haven are never touched, and a host-authored window keeps its dates even when a synced rule overlaps them. Because the OwnerRez API exposes no dates for named seasons, a rule scoped to a named season still imports year-round; enter the dates in Haven to make it seasonal.
Percent length-of-stay tiers map as:
Haven does not stack those discounts; a stay receives the single highest qualifying tier. Two leftover thresholds in the same rule (for example 14 and 21 nights, with no weekly or monthly tier) stay unmapped, because Haven has only one custom trip-length pair.
An early-bird or last-minute discount maps when it is a single percent off, with one day threshold, and applies year-round.
A leftover automatic fee whose basis Haven can represent — per stay, per night, per guest, per guest per night, or a percent of rent — becomes a custom fee on the listing, using the OwnerRez description as the guest-facing name.
Synced custom fees are locked on the Custom fees card. Choose Edit in Haven on the card's sync label to edit, remove, or change whether tax applies to them in Haven; OwnerRez then stops updating the list until you choose Re-sync from OwnerRez.
Optional OwnerRez add-ons (a pontoon rental, an optional parking charge) become upsells when the amount is a fixed, representable basis. Percentage upsells are not imported; Haven add-ons are priced as a bundle line, not a rate.
Haven reads the taxes OwnerRez charges on a sample quote for the listing and mirrors them as Haven tax rules marked Synced from OwnerRez. Percentage taxes and flat taxes charged per stay or per night (such as a $5-per-night hotel fee) are imported at the same rate OwnerRez uses. A tax Haven can't calculate exactly (a per-guest flat tax, or one on only part of the fees) is not imported; the tax editor lists it so you can add it as a Haven rule. If you had already typed the same tax into Haven at exactly the same rate, your copy is switched off, not deleted, so the guest isn't charged twice.
OwnerRez has no tax API, so Haven works these taxes out by pricing test quotes in OwnerRez's quote engine. If one doesn't match OwnerRez, or you want to set taxes yourself, click the Synced from OwnerRez pill in the tax editor and choose Edit in Haven. OwnerRez then stops updating this listing's taxes until you choose Re-sync from OwnerRez on the same pill. See Taxes synced from your PMS.
Active OwnerRez discount codes come into Haven as discount codes when the account syncs: right after the first import, then on each daily sync. A code imports when it is a percentage off (1–100%) with no tiers and applies to bookings on your own website (every listing site, or a list that includes your website). It can be limited to an arrival-date range; that becomes the code's stay window. OwnerRez's applies to rent only setting becomes Nightly rate only in the code's Discounted charges (every fee left at full price), and its description becomes the code's label.
A code limited to one imported property is created on that listing. A code covering several becomes an account-wide code that leaves out every listing it doesn't cover, including listings that aren't on OwnerRez. These are skipped and listed under your discount codes with the reason:
Each code is created once. After that it is a normal Haven code: edit, pause or delete it in Haven. Changes or deactivation in OwnerRez later do not reach Haven, and a code you delete in Haven is not created again.
These still have no honest Haven counterpart:
Unmapped rules are retained on the sync record rather than being forced into the nearest column.
Every active rule Haven is not charging also appears under Custom fees on the listing Calendar's Price tab, grouped by why:
OwnerRez's computed pricing feed is read-only from Haven's perspective.
For each calendar date, Haven imports:
Important details:
Because OwnerRez is the source of truth for this read-only calendar domain, supported calendar controls are locked in Haven.
Manage pricing in Haven: A host can turn on Manage pricing in Haven from Calendar → Pricing to stop OwnerRez's computed daily prices from overwriting Haven prices. Haven still does not send those prices to OwnerRez. Minimum and maximum stays, check-in/check-out restrictions, advance notice, the booking window, reservations, blocks, and supported fees continue to sync inbound.
OwnerRez returns guest reservations and availability blocks from the same bookings feed. Haven mirrors both onto the calendar.
Haven uses:
For an active OwnerRez reservation, Haven creates or updates a partner-managed unavailable calendar event. Cancelling or deleting the OwnerRez reservation removes that unavailable event.
OwnerRez reservation financial data is not recreated as a paid Haven booking. OwnerRez totals and charge lines may be validated during sync and retained in integration audit or telemetry data, but they are not shown as a Haven Stripe payment, payout, or booking-pricing snapshot.
Haven mirrors OwnerRez rows marked as blocks, including:
Blocks become partner-managed unavailable dates in Haven. Block updates adjust the dates, and block deletion removes the unavailable event.
When a usable, non-proxy guest email is available, Haven can upsert the guest's stay into Guest CRM using:
A standalone OwnerRez guest webhook does not update Guest CRM directly. Guest data is pulled in the context of reservation ingestion and guest backfill.
Haven pushes a confirmed direct booking only when:
Haven sends the guest to OwnerRez under a Haven-owned alias address (pg+…@replies.bookwithhaven.com) rather than the guest's real email, and sends no phone number. The alias is the same for a given guest on every Haven booking, so OwnerRez still recognises a returning Haven guest.
OwnerRez trigger emails and OwnerRez-inbox replies addressed to the alias arrive at Haven. Haven writes each one to the reservation's Messages thread and sends it to the guest as a Haven-branded host message. Every such email is relayed; there is no per-trigger setting in Haven. Bounces and Haven's own outgoing mail are never relayed. A message longer than the guest email allows is shortened with a visible note, and the full text stays on the thread.
OwnerRez thread_message webhooks are not required for this: Haven reads the email itself. Where OwnerRez does deliver a thread_message webhook for the same host email, Haven skips it rather than mirroring the message twice.
Haven creates an OwnerRez booking with:
is_block: falsegenerate_charges: true, so OwnerRez prices the booking from its own rates, surcharges and taxesOwnerRez's create-booking API takes no charge lines and its payments API is read-only. As a result:
OwnerRez sends a booking-created webhook after Haven creates the booking. Haven recognizes the existing outbound mapping and suppresses that echo so it does not create a second unavailable event.
Haven does not currently push date, guest, charge, or note updates to an existing OwnerRez booking.
Before Haven accepts requested dates for an OwnerRez-connected property, Haven performs a live overlap check against OwnerRez bookings and blocks for that property.
The check:
This check complements the mirrored Haven calendar and reduces the chance that a very recent OwnerRez booking is missed before its webhook or poll reaches Haven.
If the OwnerRez availability request fails, Haven records the integration error and allows the booking attempt to continue. This fail-open behavior avoids inventing blocked dates or making every date unavailable solely because OwnerRez is unreachable.
For each selected property, Haven:
Haven periodically re-syncs imported properties as a missed-webhook safety net:
Haven does not silently auto-import every unmapped OwnerRez property unless Auto-import on is enabled. Turning automatic import back on also restores and refreshes mappings from that connection that were previously archived.
Background polling:
The scheduled calendar/reservation and property polls are the production safety nets for missed, dropped, or automatically disabled webhooks. The OwnerRez connector also implements a reconciliation operation that reuses reservation polling, but that operation is not currently scheduled as a separate production job.
Haven does not create OwnerRez webhook subscriptions through the API.
OwnerRez automatically creates a per-user webhook subscription when the host authorizes the Haven OAuth application. The subscription is based on the webhook configuration present on the OwnerRez application at authorization time.
The Haven OwnerRez application subscribes to:
If an account authorized Haven before the webhook configuration was available, that authorization may not have a subscription. Disconnecting and reconnecting OwnerRez creates a fresh authorization and subscription.
OwnerRez may automatically disable a subscription after sustained delivery failures. Background polling and reconciliation provide a safety net, but reconnecting may be needed to restore real-time delivery.
OwnerRez documents these actions:
entity_createentity_updateentity_deleteapplication_authorization_revokedwebhook_testEach delivery includes a unique delivery ID. Haven uses it as the idempotency key within a short, 60-second database deduplication window so immediate OwnerRez retries are not processed twice.
OwnerRez entity_type: booking is used for both reservations and blocks.
reservation.createdreservation.changedreservation.deletedOwnerRez includes change categories on property webhooks.
calendar.updatedproperty.createdproperty.changedproperty.deletedOwnerRez guest create/update/delete webhooks are validated, stored, and logged, but do not have a direct guest-event handler.
Guest details are pulled during reservation ingestion or guest backfill instead. A guest-only edit in OwnerRez therefore does not independently rewrite Haven Guest CRM.
application_authorization_revoked is normalized as integration.disconnected.
Haven:
webhook_test is accepted as a no-op. It verifies delivery without changing Haven property, calendar, reservation, or guest data.
Inquiry, quote, thread-message, user-entity, and future unknown entity events are stored and logged through the fallback path. They do not currently change host-facing Haven data.
OwnerRez does not sign these webhooks with HMAC. Haven verifies the HTTP Basic authentication configured between Haven and the OwnerRez OAuth application.
Delivery behavior:
401 Unauthorized.200 so OwnerRez does not retry it indefinitely; malformed payloads are reported for investigation.500 so OwnerRez can retry the delivery.Only fields OwnerRez actually supplied are marked as synced. This means:
Common locked fields can include:
New to Haven?
Haven is the direct booking platform these guides are written for — a branded site, secure payments, and guest relationships you own. Build yours free.
Free to build · No credit card · Private until you publish