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:
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". Photo group and display name are host-owned in Haven; structure stays sync-locked. 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 with AI 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, and apply to every listing site (or have no listing-site restriction). 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 seasonal include list does not block the import — those constraints have no Haven column, and dropping the rule would leave the extra-guest field empty while OwnerRez still billed it.
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.
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.
These still have no honest Haven counterpart:
Unmapped rules are retained on the sync record rather than being forced into the nearest column.
OwnerRez's computed pricing feed is read-only from Haven's perspective.
For each calendar date, Haven imports:
Important details:
isStayDisallowed feed value is not currently mapped to a separate Haven field.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 stays, check-in/check-out restrictions, 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 searches OwnerRez by the Haven guest's email address.
Haven creates an OwnerRez booking with:
is_block: falseOwnerRez's create-booking API does not accept Haven's structured guest counts, detailed charges, or payment fields. 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
© 2026 Book With Haven, LLC.