Loading...
This reference explains what Haven currently reads from and writes to Guesty through the native Guesty Marketplace Partners API integration, how multi-unit listings are represented, which webhooks Haven subscribes to, and the important limits of each path.
The native Guesty integration is currently a limited beta controlled by Haven's guesty_integration feature flag. New connection and import screens are available only to enabled accounts. Turning the beta flag off does not stop an existing Guesty connection from continuing to sync.
Haven reads supported:
Haven writes supported:
OTHER payment record after Haven charges the guest through StripeHaven does not write the following to Guesty:
Haven connects as an official Guesty Marketplace partner. The connection does not ask you to create or paste a Guesty Open API client ID and secret.
To connect:
Important token behavior:
During connection, Haven also attempts to create the Guesty webhook subscription and retrieve its per-endpoint Svix signing secret. Webhook setup is best-effort: if it fails, the connection can still complete and scheduled polling remains the safety net.
Guesty exposes three relevant listing types:
SINGLEAn active SINGLE listing imports as one Haven property.
MTLAn active MTL listing is the parent of a Guesty multi-unit property. Haven does not import that parent as a bookable Haven property during the normal listing-selection flow. Instead, Haven creates or reuses a Multi-Unit Site.
The Multi-Unit Site:
MTL_CHILDEach active MTL_CHILD listing imports as its own Haven property and is attached to the Multi-Unit Site for its MTL parent.
Because Guesty sub-units commonly share the parent's public title, Haven uses the child's Guesty nickname when available so units remain distinguishable inside the multi-unit site.
Inactive listings are not offered as importable listings. A standalone SINGLE listing can also be attached to a Haven Multi-Unit Site selected during onboarding, but an MTL_CHILD always follows its Guesty parent grouping.
Haven validates the Guesty listing response, normalizes it, and persists only fields that have an implemented Haven mapping. Unknown or unsupported values are not forced into unrelated fields.
Haven currently writes:
SINGLE: Guesty public title when present, otherwise nicknameMTL_CHILD: Guesty nickname when present, otherwise titleaccommodatesbedroomsbathrooms
2.5 becomes two full bathrooms plus Haven's half-bath indicatorpropertyTyperoomType has an exact supported mapping:
defaultCheckInTimedefaultCheckOutTimeGuesty's beds count is validated and normalized but does not currently populate a Haven field.
Haven uses Guesty's private address object, not publishedAddress, and imports:
Guesty does not currently provide a separate country code mapping in this path.
Haven currently maps:
publicDescription.summary → Haven's main property descriptionpublicDescription.space → Haven's main property description only when no summary is suppliedpublicDescription.access → Guest accesspublicDescription.notes → Other notespublicDescription.neighborhood → Neighborhood descriptionpublicDescription.transit → Getting aroundThe Guesty space value does not currently populate Haven's separate About the space / detailsMarkdown field. That field exists in the Guesty sync registry, but the current normalizer does not supply it.
Haven passes Guesty's amenity names through the shared amenity mapper:
amenitiesNotIncluded is validated but does not currently clear or negate Haven amenities.Haven separately requests Guesty's unit-type house-rules endpoint. When available, it writes:
petsAllowed → Pets allowedpartiesAllowed → Events allowedsmokingAllowed → Haven's smoking-allowed amenityadditionalRules → Haven's house-rules markdownThese Guesty house-rule values are currently not persisted:
If the separate house-rules request fails, Haven continues the property import without house rules and can try again on a later property refresh.
The Guesty listing schema includes more pricing values than the current Haven listing mapper persists. The distinctions below are important when deciding which system is authoritative.
When Guesty supplies them, Haven currently writes:
The imported currency becomes the Haven property's currency at creation. Later Guesty property refreshes do not silently replace the property's currency.
The Guesty field registry includes:
Current behavior is more limited:
prices.basePrice does not populate Haven's property-level default price.prices.weekendBasePrice does not populate Haven's property-level weekend price.prices.cleaningFee does not currently reach Haven's cleaning-fee field.Because default and weekend price are represented in the sync registry and the calendar marks daily pricing as supplied, the UI can describe those controls as integration-managed even though the property-level scalar values are not filled from basePrice or weekendBasePrice.
Security deposit and extra-guest amount/threshold are written by the current mapper, but they are not present in the Guesty field registry. As a result:
This is a current mapping gap, not two-way fee sync. Haven never sends those Haven fee edits back to Guesty.
Haven does not currently import:
terms objectGuesty's documented listing read response does not currently expose the Wi-Fi name and password fields that its listing write API may support. Haven therefore does not import or lock:
The following values are validated, normalized, or retained for integration routing but do not currently populate a host-facing Haven field:
SINGLE, MTL, or MTL_CHILD)MTL_CHILDactive and isListed as Haven public visibilityGuesty photos are read from the listing's pictures array. For each usable photo, Haven uses:
Haven downloads Guesty photos into Haven image storage.
Photo behavior:
Haven does not write photos back to Guesty.
For each imported property, Haven reads Guesty's availability-pricing calendar with allotment data enabled.
Haven imports per date:
cta → check-in closed for that datectd → check-out closed for that dateGuesty calendar prices are treated as major currency units. Haven converts them into the shared calendar pipeline without treating them as cents.
Guesty's multi-unit availability rule differs from single-unit status:
allotment is present, allotment > 0 means available.allotment = 0 means unavailable.status.A calendar.updated.v2 webhook for an imported child refreshes that child's mapped calendar. A calendar webhook for an MTL parent has no direct Haven property mapping, so Haven uses the stored parent Multi-Unit Site association and refreshes every actively imported child in that site.
Guesty calendar sync is two-way. Haven can send:
Haven coalesces adjacent days with identical values and sends updates sequentially for one Guesty listing.
Two-way does not mean Haven echoes the entire imported calendar back to Guesty. Haven applies a provenance filter:
When Manage pricing in Haven is enabled for the property, Haven stops importing Guesty's daily prices. The current outbound filter also omits price from Guesty calendar updates, so Haven-managed prices remain local rather than replacing Guesty prices. Availability and other eligible Haven-authored calendar fields can still sync.
Haven mirrors Guesty reservations onto the Haven calendar as partner-managed unavailable events. These imported rows are calendar reservations, not paid Haven bookings.
Haven uses supported reservation data including:
Status behavior:
confirmed → confirmed mirrorinquiry, reserved, and awaiting_payment → pending mirrorcanceled, declined, expired, and closed → cancelled/removalGuesty reservation totals are not recreated as a Haven pricing snapshot, Stripe charge, payout, or paid booking. The unavailable calendar event stores dates, guest-count information, source notes, and pet information available to the shared handler.
Guest contact data is primarily imported in the context of a reservation:
The hourly reservation safety poll uses Guesty's reservation-search summaries. Those summaries update calendar occupancy, but they do not independently hydrate a full Guesty guest record.
Standalone guest.created and guest.updated webhooks are subscribed and audited, but there is no direct guest-webhook handler that rewrites Guest CRM. Guest changes converge when they are encountered through reservation ingestion or a full guest/reservation backfill.
Haven pushes a confirmed direct booking only when:
Haven first creates a Guesty quote with:
ignoreCalendar: falseignoreTerms: falseignoreBlocks: falsehavenHaven selects the first rate plan that Guesty does not mark inapplicable. If Guesty returns no applicable plan, Haven does not create the Guesty reservation.
The Guesty quote is used as an availability and booking-rule gate only. Haven's pricing engine and Stripe charge remain authoritative; Haven does not replace the amount charged with Guesty's quote total.
Unlike the OwnerRez path, Haven does not currently perform a separate live Guesty reservation-overlap read before the Haven booking is confirmed. The quote performed during the outbound push is the live Guesty-side gate.
After an applicable quote, Haven creates a confirmed Guesty reservation with:
havenoriginIdHaven records the resulting Guesty reservation ID in an outbound mapping. Webhook echo suppression uses that mapping so Guesty's subsequent reservation.new delivery does not create a duplicate unavailable event.
If an earlier create attempt may have committed but Haven did not receive a definitive response, a retry first searches Guesty for a strict match on property, dates, and guest email. This reduces duplicate reservations after a timeout or worker interruption.
After Guesty creates the reservation, Haven attempts to record the Haven charge on the Guesty reservation:
OTHER.This record is informational. Guesty does not process the payment, and Haven remains the financial system of record.
If the informational payment record fails, Haven reports the reconciliation issue but does not delete or roll back the Guesty reservation that was already created.
Reservation creation is retried for retryable failures. If Haven permanently gives up, or the retry limit is exhausted after the Haven booking is already confirmed:
The protective write is best-effort. Haven performs delayed read-back checks for observability, but Guesty's calendar can be eventually consistent, so an accepted write is not downgraded solely because it is not visible immediately.
reservation.updated with a cancelled status.reservation.updated with a cancelled status.canceled.canceledBy: GUEST in the Guesty API payload. This is the value used by the integration endpoint, not a statement that the guest initiated the cancellation in Haven.Haven does not currently push updates to the existing Guesty reservation for:
Cancellation is the only supported outbound mutation after creation.
For each selected Guesty listing, Haven:
SINGLE, MTL, and MTL_CHILD records.MTL_CHILD parents.New Guesty listings are not silently imported unless Auto-import on is enabled. Normal multi-unit grouping is established during listing discovery and selection.
In production, Haven fans out a calendar-and-reservation poll approximately once per hour, with a roughly 50-minute per-connection cooldown.
The poll:
The calendar fetch covers a 30-day lookback and at least Haven's configured forward calendar horizon, extending far enough to cover a property's bookable window plus a probe buffer.
Property content and photos are primarily refreshed by listing.updated webhooks. A separate property poll runs approximately once per day, with a roughly 23-hour cooldown, as a safety net for missed listing webhooks.
Guesty documents webhook delivery as ranging from a few seconds to as much as approximately 30 minutes. Polling therefore remains important even when the subscription is healthy.
Haven creates a Guesty webhook subscription through the API during connection and stores the per-endpoint Svix signing secret. Haven currently requests exactly these eight events:
reservation.newreservation.updatedlisting.newlisting.updatedlisting.removedcalendar.updated.v2guest.createdguest.updatedHaven removes subscriptions for its stored webhook URL during disconnect when Guesty permits the cleanup. Disconnecting Haven does not delete the Marketplace API credentials owned by the Guesty account.
reservation.newreservation.createdreservation.updatedreservation.changedGuesty does not provide a separate subscribed cancellation event; cancellation is a status change delivered through reservation.updated.
listing.newproperty.createdThe listing-selection import flow is the authoritative path for creating Guesty MTL Multi-Unit Sites and attaching MTL_CHILD units.
listing.updatedproperty.changedlisting.removedproperty.deletedHaven-uploaded photos and the Haven property itself are not deleted.
calendar.updated.v2listingId to resolve the imported Haven propertyMTL parent, fans the refresh out to imported children in the associated Haven Multi-Unit Siteguest.createdguest.updatedHaven does not currently subscribe to guest.deleted.
Guesty delivers webhooks through Svix. The signing secret is specific to the connected Guesty account and Haven endpoint.
For every request, Haven:
accountIdsvix-id, svix-timestamp, and svix-signature{svix-id}.{svix-timestamp}.{raw body}v1 signatures in constant timeDeduplication behavior:
meta.eventId is preferred.meta.messageId is used when no event ID is supplied.Delivery responses:
401.accountId, or one for an unknown connection, is acknowledged with 200 and dropped because retrying cannot make it routable.200, reported, and not retried indefinitely.200.200.207.Guesty retries non-2xx deliveries on an increasing schedule. Sustained delivery failures can cause Guesty to disable the endpoint after approximately five days; Guesty API Support may be required to reactivate it. The hourly and daily polls reduce the risk of missed data while webhook delivery is impaired.
Guesty property content and supported property-level fees are inbound-only:
Registered property fields include:
Registration does not guarantee that the current Guesty normalizer supplies a value. The default-price, weekend-price, cleaning-fee, and detailsMarkdown gaps described above remain current limitations.
A registered field can be changed to Edit in Haven:
Guesty's calendar and reservations are two-way domains rather than simple content-field locks. Haven uses provenance-filtered calendar writes and reservation echo suppression so Guesty-originated data is not blindly echoed back.
The native Guesty integration currently does not:
The connector declares a static capability set because Guesty Marketplace tokens carry one partners-api scope. Guesty-side API permissions cannot currently be introspected by Haven, so a Guesty account restriction can still cause an individual read or write to fail even when the connection appears capable in Haven.
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.