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:
- Property structure and listing content
- Photos and recognized amenities
- Property currency and deterministically mappable fee/discount rules
- Computed daily prices and stay rules
- Reservations and availability blocks
- Guest identity and contact data associated with reservations
- Connection-revocation events
Haven writes:
- A guest record when no OwnerRez guest with the exact email exists
- A booking for a confirmed Haven direct booking
Haven does not write the following to OwnerRez:
- Property content or photos
- Amenities or Wi-Fi details
- Nightly rates or daily price overrides
- Minimum-stay or check-in/check-out rules
- Manual availability blocks created in Haven
- Fees, discounts, taxes, or security deposits
- Payments, refunds, payouts, or Stripe data
- Booking date or guest-detail modifications after the booking is created
- Booking cancellations
- Messages
- Reviews
Haven imports these values when OwnerRez supplies them:
- Haven property title
- OwnerRez listing headline, when available
- Otherwise OwnerRez external name
- Otherwise OwnerRez internal property name
- Maximum guests from
max_guests
- Bedrooms from
bedrooms
- Bathrooms from full- and half-bath counts when available; otherwise the total bathroom count
- Property type when the OwnerRez value has an exact Haven equivalent
- Listing/space type when OwnerRez supplies a recognized
property_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 type- Haven may set this value during import
- It is not currently registered as a synced/locked OwnerRez field
- Check-in time from
check_in
- Check-out time from
check_out
- Pets allowed from
max_pets
- More than zero means pets are allowed
- Zero means pets are not allowed
- Missing means Haven leaves the field unsupplied
- Listing currency from
currency_code
- Adopted when the Haven property is first imported
- Not silently replaced by later inbound syncs
Haven imports:
- Street address, including the second address line when supplied
- City
- State or region
- Postal code
- Country
- Latitude
- Longitude
- Time zone when OwnerRez explicitly supplies one
OwnerRez does not send a preformatted address string, so Haven formats the address from the supplied parts.
Haven maps only close equivalents:
- House, holiday home, country house, farmhouse, guest house, and tiny house → House
- Apartment, corporate apartment, serviced apartment, hotel apartment, and OwnerRez API value
pent_house → Apartment
- Condo → Condo
- Cabin, log cabin, chalet, ski chalet, and lodge → Cabin
- Villa → Villa
- Cottage → Cottage
- Townhome → Townhouse
- Bungalow → Bungalow
- Loft → Loft
- Studio → Studio
OwnerRez types without a clear Haven equivalent are not guessed. The Haven property-type field remains unsupplied and editable.
Detailed listing content depends on OwnerRez making its listing endpoint available to the connected account. If that enrichment is unavailable, Haven still imports the core property record.
When available, Haven maps:
- OwnerRez headline → Haven property title
- Short description → Haven main property description
- Full description → Haven main property description when no short description is supplied
- Accommodations summary and accommodations detail → About the space
- Guest access → Guest access
- Getting around → Getting around
- Location description and nearby activities → Neighborhood description
- Features description and unique benefits → Other notes
- House manual → During your stay
Haven imports:
- Wi-Fi network name
- Wi-Fi password
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:
- Bed count calculated from OwnerRez room data
- OwnerRez active/snoozed state as Haven public visibility
- Check-in instructions and directions
- Registration number and date
- Review average and review count
- Listing minimum/maximum rate summaries
- Location-type tags
- OwnerRez room and bathroom descriptions
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:
- Original image URL, or the large URL when no original URL is supplied
- OwnerRez photo order
- Caption, when supplied
- Cropped image URL as the thumbnail, when supplied
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.
Photo behavior:
- New OwnerRez photos are added.
- OwnerRez photos no longer returned by the listing are removed from the active synced set.
- A photo the host intentionally archived in Haven remains archived and is not re-added.
- Haven-uploaded photos are never removed or overwritten by OwnerRez photo sync.
- A suspicious empty OwnerRez photo response does not wipe an existing gallery; Haven keeps the current photos and retries later.
- OwnerRez
video_url values are not imported as Haven videos.
OwnerRez supplies cancellation policy as free text rather than Haven's structured refund tiers.
When Haven's OwnerRez cancellation-policy parsing feature is enabled for the account, Haven attempts to convert that text into structured Haven cancellation rules. When the feature is not enabled, Haven does not auto-parse the text and the structured cancellation field stays editable.
- A confident parse writes the structured tiers and marks the field Synced from OwnerRez.
- An unclear or low-confidence result writes no structured rules and leaves the Haven field editable.
- Unchanged OwnerRez text is not reparsed on every sync.
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, but maps a rule only when its behavior matches a Haven field exactly.
For a rule to be eligible, it must:
- Be active
- Use automatic mode
- Have no custom criteria
- Apply to all seasons, or have no season restriction
- Apply to all listing sites, or have no listing-site restriction
- Use amount semantics Haven can represent without approximation
Haven maps non-percent, fixed per-stay rules for:
- Cleaning fee
- Linen fee
- Resort fee, when represented by OwnerRez's resort category
- Management fee, when represented by OwnerRez's management category
- Community/association fee, when represented by OwnerRez's association-property category
Percent-based versions and per-night versions of these flat Haven fields are not mapped.
Haven maps one exact pet-fee rule per property when the rule has no free allowance, cap, or grouped increment:
- Per stay
- Per night
- Per pet per stay
- Per pet per night
Haven maps one extra-guest rule when it is:
- A fixed amount
- Charged per night and per additional guest or adult
- Based on groups of one
- Not capped
OwnerRez's included-guest count becomes Haven's Apply after this many guests threshold when supplied.
Haven maps percent-based length-of-stay tiers only when every tier has a supported threshold:
- 7 nights → weekly discount
- 28 nights → monthly discount
- 30 nights → monthly discount
If one tier in the rule cannot be represented exactly, Haven does not partially map the rule.
Examples include:
- Manual, optional, offline, or code-based rules
- OwnerRez discount codes
- Early-bird or last-minute discounts
- Audience, member, new-listing, or highly rated guest promotions
- Complex or rate-adjustment rules
- Rules with custom criteria
- Season-specific or channel-specific rules
- Unsupported percentage/fixed-amount combinations
- Unsupported length-of-stay thresholds
- Multiple rules competing for one Haven field
- Taxes and security deposits
These rules are not approximated into Haven pricing.
OwnerRez's computed pricing feed is read-only from Haven's perspective.
For each calendar date, Haven imports:
- Computed nightly amount → a Haven daily price override
- Minimum nights → a per-date minimum-stay rule
- Arrival disallowed → check-in restriction
- Departure disallowed → check-out restriction
Important details:
- Haven requests OwnerRez's computed price with pricing rules included.
- Values are treated as major currency units, not cents.
- The feed creates per-date prices; it does not set Haven's property-level default or weekend price.
- The feed does not provide the availability mirror Haven uses for bookings and blocks.
- OwnerRez's
isStayDisallowed feed value is not currently mapped to a separate Haven field.
- Haven does not send calendar edits back to OwnerRez.
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:
- OwnerRez booking ID
- OwnerRez property ID
- Arrival and departure dates
- Status
- Active → confirmed
- Pending → pending
- Canceled, or a cancellation timestamp → cancelled
- Listing site/source channel
- Guest first and last name, when available
- Adult count
- Child count
- Infant count
- Pet count
- Guest email and phone when available through the reservation/guest lookup
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:
- Owner blocks
- Standard external blocks
- Linked-availability blocks
- Quote holds
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:
- Email
- First name
- Last name
- Haven property
- Check-in and check-out dates
- Source channel
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:
- The Haven property has an active OwnerRez mapping
- The OwnerRez connection is connected
- The connection has full write access
- The Haven event has a guest
- The booking has not already been pushed
Haven searches OwnerRez by the Haven guest's email address.
- An exact, case-insensitive email match reuses the existing OwnerRez guest.
- If there is no exact match, Haven creates a guest with first name, last name, email, and phone when available.
- Haven does not match by name alone.
Haven creates an OwnerRez booking with:
- OwnerRez property ID
- Arrival date
- Departure date
- OwnerRez guest ID
is_block: false- A note containing:
- Haven booking reference
- Adult count
- Child count, when greater than zero
- Booking currency and total, when available
OwnerRez's create-booking API does not accept Haven's structured guest counts, detailed charges, or payment fields. As a result:
- Adult/child counts and the total are informational text in the booking note.
- Infants and pets are not sent as structured OwnerRez booking fields.
- Nightly charges, fees, taxes, discounts, Stripe payment IDs, and payouts are not sent.
- Haven remains the financial system of record for the direct booking.
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.
- OwnerRez sends a booking update or delete webhook.
- Haven removes the mirrored unavailable event.
- The dates become available in Haven, subject to any other bookings or blocks.
- OwnerRez sends the cancellation to Haven.
- Haven treats it as a host cancellation.
- Haven cancels the Haven event and runs Haven's cancellation/refund workflow.
- The outbound mapping is archived.
- Haven cannot cancel it through the OwnerRez API.
- Haven creates an action-required host notification.
- Haven emails the host with the OwnerRez booking number.
- The host must cancel the booking manually in OwnerRez.
- Haven does not apply the changed dates to the paid Haven booking.
- Haven keeps the Haven booking dates unchanged.
- Haven creates a modification-rejected notification and emails the host.
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:
- Ignores explicitly cancelled OwnerRez rows
- Treats active and pending bookings as unavailable
- Treats OwnerRez blocks as unavailable
- Checks check-in through the night before check-out, allowing same-day turnover
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:
- Fetches the core OwnerRez property.
- Attempts listing-content and photo enrichment.
- Fetches active surcharge and discount rules.
- Creates the Haven property and field mapping.
- Downloads OwnerRez photos.
- Imports the forward daily pricing and stay-rule window.
- Queues additional background enrichment and reservation/guest backfill work.
Haven periodically re-syncs imported properties as a missed-webhook safety net:
- Calendar pricing, stay rules, reservations, and blocks are polled approximately hourly, with a roughly 50-minute per-connection cooldown.
- Property content, photos, and fees are refreshed by OwnerRez property webhooks and by a separate property safety poll approximately once per day.
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:
- Re-fetches OwnerRez computed daily prices and stay rules
- Re-fetches bookings and blocks for imported properties
- Updates existing calendar events
- Backfills events missed by webhooks
- Removes orphaned mirrored events when an OwnerRez booking/block no longer appears
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:
- Booking
- Guest
- Property
- User
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_test
Each 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.
- entity_create
- Normalized as
reservation.created
- Creates a partner-managed unavailable event when the property is imported
- Suppresses the echo when Haven created the OwnerRez booking
- entity_update
- Normalized as
reservation.changed
- Updates dates, guest counts, pets, source, and display notes for OwnerRez-originated events
- Removes the unavailable event when cancelled
- Runs Haven's inbound cancellation flow for a Haven-originated booking cancelled in OwnerRez
- Rejects OwnerRez date changes to a Haven-originated paid booking and notifies the host
- entity_delete
- Normalized as
reservation.deleted
- Treated as cancellation/removal
- Removes the mirrored unavailable event
OwnerRez includes change categories on property webhooks.
- Rates/availability-only categories
- Normalized as
calendar.updated
- Re-fetches the forward OwnerRez pricing feed
- Updates daily prices, minimum stays, and check-in/check-out restrictions
- Does not run a full listing-content refresh
- entity_create
- Normalized as
property.created
- Automatically imports the property only when Auto-import on is enabled
- Otherwise leaves it available for manual import
- entity_update with content-relevant, mixed, empty, or missing categories
- Normalized as
property.changed
- Re-fetches core property data, listing enrichment, fees/discounts, and photos
- entity_delete
- Normalized as
property.deleted
- Detaches the OwnerRez mapping
- Keeps the Haven property and its content
- Shows Listing removed on the property card and Removed from OwnerRez in the integration property list
- Removes active OwnerRez-sourced photos
- Pauses the property's add-on billing at the next renewal
- Emails the host
OwnerRez 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:
- Marks the matching OwnerRez connection disconnected
- Cancels queued or in-progress integration work that can no longer complete
- Stops accepting sync work for that connection
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:
- OwnerRez expects a response within approximately two seconds and may retry failed deliveries up to ten times.
- Haven validates the webhook envelope before routing it.
- Booking, property, and guest entities are also validated against their OwnerRez schemas.
- The OwnerRez user ID routes the event to the matching Haven connection.
- The referenced property mapping is used as a fallback when needed.
- Raw payloads are stored for integration auditing.
- Duplicate delivery IDs are acknowledged without reprocessing.
- The webhook request enqueues background work instead of performing slow property/calendar API calls inline.
- Failed authentication returns
401 Unauthorized.
- A duplicate or malformed authenticated payload is acknowledged with
200 so OwnerRez does not retry it indefinitely; malformed payloads are reported for investigation.
- A transient failure to enqueue the background sync returns
500 so OwnerRez can retry the delivery.
- Domain-handler failures happen later in the worker, are recorded on the sync job, and do not change the original webhook acknowledgement.
Only fields OwnerRez actually supplied are marked as synced. This means:
- A supplied supported field shows Synced from OwnerRez and is locked.
- An empty, unavailable, or unmappable OwnerRez field remains editable in Haven.
- Calendar pricing and stay-rule controls are inbound-only because Haven cannot write calendar changes to OwnerRez.
- Haven-only fields remain editable.
- A host can select a supported field's Synced from OwnerRez badge and choose Edit in Haven. The field changes to Overriding, and OwnerRez stops overwriting that field until Re-sync from OwnerRez is selected. The local override is not pushed back to OwnerRez.
Common locked fields can include:
- Property title
- Maximum guests
- Property type
- Address
- Check-in and check-out times
- Pet policy
- Supported descriptions and public details
- Neighborhood description and getting around
- Recognized amenities
- Wi-Fi network and password
- During-stay information
- Confidently parsed cancellation rules
- Currency
- Supported fees and discounts
- Extra-guest and pet-fee settings
- Daily calendar prices
- Minimum-stay rules
- Check-in and check-out restrictions
- Blocked-date controls governed by OwnerRez availability