This reference lists what Haven currently reads after you connect your Airbnb account, what Haven can write back, how updates arrive, and the important limits of each path.
If a PMS (Hostaway, Hostex, or similar) already publishes your listings to Airbnb, this path imports that same inbound listing, pricing, calendar, and reservation data. The only material write-back limit is availability: Haven bookings and manual blocks close dates through the Haven iCal feed, which you add in the PMS. See Connect via Airbnb when you use another PMS.
Haven reads supported:
- Listing content, address, capacity, and listing settings
- Photos and recognized amenities
- Wi-Fi details and house rules
- Recognized listing fees
- Per-day prices, minimum stays, check-in/check-out restrictions, and availability
- Reservations and associated guest details
- Public guest reviews
- Connection and listing lifecycle events
Haven's direct Airbnb integration has only two outbound write paths:
- Eligible per-day price changes as dated
PRICE values
- Approved message templates, currently including the Haven guidebook message when the required template is available
These are narrow, operation-specific paths. They do not make the integration a general two-way reservation or availability connection.
Haven does not write the following through the direct Airbnb integration:
- New reservations
- Reservation changes or cancellations
- Availability blocks or open-date commands
- Haven direct bookings as Airbnb reservations
- Manual Haven blocks through the calendar API
- Minimum-stay changes
- Closed-to-arrival or closed-to-departure changes
- Property content, descriptions, photos, amenities, Wi-Fi details, or house rules
- Fees, discounts, taxes, security deposits, or listing-level pricing rules
- Free-form guest messages
- Payments, refunds, payouts, or Stripe data
- Reviews or review responses
Use the Haven iCal feed to block Airbnb dates for Haven direct bookings and manual Haven blocks. The API connection itself cannot send those availability changes.
Airbnb only returns listings where the connected Airbnb user is the listing's primary owner.
- A listing owned by the connected account can be imported.
- A listing where the connected account is only a co-host is not returned.
- A co-host-only Airbnb account can therefore connect successfully but show zero importable listings.
Haven cannot work around this ownership restriction. The primary listing owner must connect their Airbnb account for those listings to appear.
Haven refetches the full Airbnb listing record before applying a listing webhook. The webhook is a change signal; it is not treated as the complete listing.
Only fields that Airbnb actually supplies are marked as synced. Empty, missing, or unmappable values remain editable in Haven.
Haven persists:
- Haven property title from the public Airbnb listing name when available
- The private Airbnb listing name only when no public name is available
- A generic listing name only when neither public nor private name is available
- Main description from the Airbnb summary when supplied
- The longer Airbnb description when no summary is supplied
The private listing name is not preferred over the public name for the guest-facing Haven title.
Haven persists:
- Maximum guests
- Bedrooms
- Full and half bathrooms
- Property type
- Listing/space type when it has a recognized Haven equivalent:
- Entire home → Entire place
- Private room → Private room
- Shared room → Shared room
- Hotel room → Hotel room
The Airbnb bed count is validated but is not currently written to a Haven field.
Haven persists supplied:
- Street address and apartment/unit
- City
- State or region
- Postal code
- Country code and resolved country name
- Latitude
- Longitude
- Time zone
Haven builds the formatted address from these components. Airbnb does not control a host-owned Haven display-location override.
Haven persists:
- Default check-in time
- Default check-out time
Per-day check-in and check-out restrictions come from the calendar feed and are stored separately from these default times.
Haven persists:
- Space overview → About the space
- Guest access → Guest access
- Notes → Other notes
- Neighborhood description
- Getting around
Airbnb's interaction text is validated, but it is not currently materialized into Haven's Interaction with guests field.
Haven persists:
- Wi-Fi network name
- Wi-Fi password
These values remain protected by Haven's normal guest-access controls.
Haven combines structured Airbnb rules with free-form additional rules.
Structured values persisted include:
- Pets allowed
- Events allowed
- Smoking allowed
When a structured rule is explicitly disallowed, Haven also renders it into the house-rules text, including:
- No smoking
- No pets
- No parties or events
- Not suitable for children
Airbnb's free-form additional rules are appended to the same house-rules content.
Haven adopts a supported Airbnb listing currency when the Haven property is first imported.
- The currency is not silently replaced during later inbound listing refreshes.
- Per-day outbound prices use the property's stored currency.
- Haven does not assume a different currency for an individual price update.
Haven reads Airbnb's amenity names and maps recognized values to Haven amenity fields.
Examples can include:
- Wi-Fi and Ethernet
- Kitchen, refrigerator, oven, stove, microwave, dishwasher, and cooking basics
- Washer and dryer
- Heating and air conditioning
- Pool, hot tub, sauna, gym, and fireplace
- Parking and EV charging
- Workspace, TV, books, games, and sound systems
- Crib, high chair, bathtub, and family amenities
- Patio, balcony, backyard, barbecue, fire pit, and outdoor furniture
- Beach, lake, waterfront, and ski access
- Safety equipment and toiletries
- Pet-friendly and accessibility-related amenities with a known Haven equivalent
Unknown amenity text is retained in sync diagnostics. Haven does not force an unknown amenity into an unrelated field.
Haven retrieves the listing's separate photo feed and persists:
- Full image URL
- Thumbnail URL when supplied
- Caption when supplied
- Airbnb photo order
Photo behavior:
- Haven requests high-resolution Airbnb image variants before storing them.
- The first visible photos can be downloaded during initial setup while the remainder finish in a background photo job.
- New Airbnb photos are added on sync.
- Photos no longer returned by Airbnb are removed from the active synced set.
- A photo intentionally archived in Haven remains archived.
- Your Airbnb photo order drives your Haven page: your Airbnb cover becomes the Haven cover, the next three photos 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 Airbnb order back at any time.
- Haven-uploaded photos are not removed by Airbnb photo sync.
- A suspicious empty photo response does not wipe an existing gallery.
- Airbnb does not provide a stable photo ID in this feed, so Haven derives one from the photo URL and order.
Haven reads Airbnb listing fee rows and persists supported fixed amounts for:
- Cleaning fee
- Linen fee
- Community fee
- Resort fee
- Management fee
Important limits:
- The integration converts the supplied minor-unit amount into the property's major currency unit.
- Unrecognized fee types are not mapped into a Haven fee field.
- Pet-fee rows are not currently materialized through this listing-fee path.
- Charge-period and charge-type details that do not fit Haven's scalar fee fields are not recreated as custom pricing logic.
- Fees are inbound only. Editing a synced fee in Haven does not send it to Airbnb.
- Haven's management fee and community fee can each be a flat amount or a percentage of the nightly rate, but a sync always writes a flat amount and resets the field to
$. Unlock the fee field to keep Haven's percentage.
- Your service fee ("keep the margin") is Haven-only and never synced — see Your Service Fee (Keep the Margin).
The Airbnb payload contains more information than Haven currently materializes into host-facing property fields.
The following can be validated, used for routing, or retained in integration diagnostics without becoming an editable Haven field:
- Airbnb platform listing ID and internal integration listing ID
- Channel ID, account identity, channel name, image, and connection timestamps
- Private listing name when the public name is available
- Bed count
- Cover-picture URL when it is not part of the synchronized photo set
- Listing-level published state
- Raw room details
- Listing pricing, availability, and platform-settings placeholders
- Unknown amenities
- Unsupported fee names, charge types, and charge periods
- Per-day maximum stay
- Per-day availability reason text and source type
- Reservation confirmation identifiers, status history, and financial breakdowns
- Review lifecycle fields that do not become a public testimonial
These values must not be mistaken for persisted Haven booking, pricing, or listing configuration.
Haven reads the forward Airbnb calendar one date at a time.
For each supplied date, Haven can persist:
- Nightly price → a Haven per-day price override
- Minimum stay → a per-date minimum-stay override
- Check-in disallowed → a per-date check-in block
- Check-out disallowed → a per-date check-out block
- Unavailable → an Airbnb-managed unavailable event
Haven reads but does not currently persist per-date maximum stay because Haven has no matching maximum-stay model.
Airbnb can report dates unavailable because of:
- A reservation
- A host or calendar block
- An external iCal calendar
- Notice or booking rules
- A rolling booking-window limit
- Other Airbnb-specific reasons
Haven mirrors genuine unavailable dates. A date that is unavailable only because it falls beyond Airbnb's rolling booking window is not converted into a hard block. Instead, Haven mirrors the detected booking-window limit.
The direct Airbnb calendar has a maximum forward API horizon of 540 days.
- Haven never requests past calendar dates through this endpoint.
- A single request covers at most 365 inclusive dates.
- Longer forward windows are split into API-compliant batches.
- Haven caps the property's mirrored advance-booking window at 540 days even when no earlier Airbnb boundary is detected.
Airbnb supplies dated prices, not a property-level base-rate or weekend-rate rule.
When the calendar returns prices:
- Haven writes per-day price overrides.
- Haven marks the Base nightly rate and Weekend rate controls as managed by Airbnb.
- Those two baseline controls are locked so a scalar edit cannot conflict with the authoritative dated price stream.
- Haven does not infer a base price, weekend price, smart-pricing rule, seasonal rule, or discount formula from the dated values.
The baseline locks therefore describe ownership of the nightly-rate stream. They do not mean Airbnb sent separate base and weekend scalar values.
Manage pricing in Haven changes only nightly-rate ownership for that property.
When enabled:
- Base and weekend rate controls become editable.
- Haven calendar custom-price tools become editable.
- Haven stops replacing local per-day prices with the next Airbnb calendar pull.
- Minimum stays, check-in/check-out restrictions, unavailable dates, reservations, fees, and listing content continue to sync inbound.
- The current shared toggle keeps those Haven-managed nightly rates local; it does not use the Airbnb price-write path.
When disabled again:
- Airbnb resumes as the source of the per-day price stream.
- The next price sync can replace Haven-managed per-day prices.
- Base and weekend controls lock again as ownership indicators.
See Manage Pricing in Haven.
For a supported synced listing field:
- Synced from Airbnb means Airbnb supplied the field and Haven currently accepts inbound updates.
- Edit in Haven changes that field to a local override.
- While overridden, inbound listing refreshes do not replace the Haven value.
- Re-sync from Airbnb restores inbound ownership.
- A local content or fee override is not pushed back to Airbnb.
Per-field content overrides are separate from the property-wide Manage pricing in Haven nightly-rate control.
Airbnb reservations are inbound only.
For a supported reservation, Haven uses:
- Integration reservation ID
- Airbnb confirmation/platform identity
- Mapped Airbnb listing
- Arrival date
- Departure date
- Reservation status
- Lead guest first and last name when supplied
- Guest email when supplied
- Guest phone when supplied
- Adult count
- Child count
- Infant count
- Pet count
- Booking channel
- A new or active Airbnb reservation creates or updates an Airbnb-managed unavailable event.
- A changed reservation updates its mirrored dates and guest counts.
- A cancelled or voided reservation removes the mirrored unavailable event.
- Partner-managed reservation events are locked against normal Haven editing.
- Periodic reservation polling removes orphaned mirrored events that no longer exist upstream.
An Airbnb reservation is not recreated as a paid Haven direct booking.
- Airbnb totals do not become a Haven booking-pricing snapshot.
- Airbnb payments do not become Stripe payments.
- Airbnb payouts, taxes, discounts, service fees, and security deposits are not copied into Haven's direct-booking accounting.
- Haven does not send reservation creates, changes, or cancellations back through this integration.
Airbnb does not send pre-existing reservations as new webhooks when the account first connects. Haven therefore runs a reservation backfill after the user selects listings to import.
The backfill:
- Lists existing reservations for the connection
- Keeps only reservations belonging to mapped Haven properties
- Creates or updates the same locked unavailable events used by live reservation webhooks
- Establishes inbound reservation mappings used by supported guest-message workflows
Haven also runs a connection-scoped guest backfill:
- A reservation with a usable, non-proxy email can create or update a Guest CRM record.
- The record can include first name, last name, property, stay dates, and booking channel.
- Airbnb relay/proxy addresses are excluded from Guest CRM retargeting.
- A reservation without a usable email still blocks the calendar but does not create a marketable guest contact.
Live reservation webhooks apply the same non-proxy-email rule before updating Guest CRM.
Haven imports guest-authored Airbnb reviews with public text as testimonials.
Persisted testimonial fields can include:
- Public review text
- Rating
- Guest first name
- Airbnb as the platform
- Review date
- External review ID for idempotent updates
Review behavior:
- Host-authored reviews of guests are not property testimonials.
- A review with no public text is not published as a testimonial.
- Synced review updates refresh provider-owned text, rating, platform, and date.
- Host-controlled visibility choices are preserved when a review refreshes.
- Reviews are not written back to Airbnb.
Private guest feedback, when supplied, is stored separately for host-only Guest Insights. It is never used as public testimonial text.
The Airbnb calendar write endpoint accepts only dated PRICE operations.
An eligible Haven-authored price write includes:
- Airbnb listing identity
- Date
- Positive nightly amount
- Property currency
- An idempotency key
Haven converts the property's major-unit price to the correct minor-unit amount before sending it.
Only Haven-authored per-day values that pass the calendar ownership and provenance gates are eligible. Haven does not echo an Airbnb-sourced price back to Airbnb and does not blanket-write a Haven base scalar across the calendar.
The price endpoint is asynchronous and returns a request ID. A successful API response means the price update was accepted for processing; it does not turn the payload into a general calendar update.
The connector rejects an outbound calendar payload if it contains:
- Availability
- Closed for check-in
- Closed for check-out
Minimum-stay values are not sent by the price-only implementation, even though Haven's shared calendar model can represent them.
The direct Airbnb API cannot block or reopen dates.
To make these Haven dates unavailable on Airbnb, add Haven's iCal export URL to Airbnb:
- Confirmed Haven direct bookings
- Pending or held dates included by the Haven calendar feed
- Manual unavailable blocks created in Haven
This creates an Airbnb calendar block through iCal. It does not create an Airbnb reservation, transfer guest details, or copy Haven payment data.
The direction matters:
- Airbnb API → Haven: Airbnb reservations and blocks are read into Haven.
- Haven iCal → Airbnb: Haven bookings and manual blocks reserve dates on Airbnb.
- Haven price API → Airbnb: only eligible per-day prices are written.
Without the Haven-to-Airbnb iCal subscription, a Haven direct booking or manual Haven block is not guaranteed to block Airbnb through this integration.
See Calendar Sync (iCal).
The integration can send a message to an Airbnb reservation thread only through a pre-approved template.
Current behavior:
- No free-form message body is accepted.
- The reservation and Airbnb channel must be known.
- The approved template must exist for the connected account.
- Haven currently looks for the approved Haven Guidebook template.
- The template can receive its approved replacement values, including the Haven guidebook URL.
- Each send carries an idempotency key.
If the channel or approved template is missing, Haven returns a non-retryable configuration error rather than falling back to free-form text.
This outbound template path does not mean Airbnb conversation history or inbound guest messages are synchronized into Haven.
Before Haven accepts requested dates for a connected property, Haven performs a live Airbnb calendar check for the requested stay.
The check:
- Reads check-in through the night before check-out
- Allows same-day turnover on the checkout date
- Treats a date as blocked only when Airbnb explicitly returns it as unavailable
- Complements the mirrored Haven calendar in case a very recent Airbnb change has not reached Haven by webhook or poll yet
If the live Airbnb request fails, Haven records the integration error and allows checkout to continue. This is fail-open behavior: Haven does not invent blocked dates or make the entire property unavailable solely because Airbnb cannot be reached.
The iCal export remains required for the opposite direction so Haven-originated bookings and manual blocks reach Airbnb.
Connecting the Airbnb account and importing listings are separate steps.
- Haven creates a pending connection.
- You authorize your Airbnb account.
- The
channel.activated event marks the connection connected.
- Haven stores the channel identity needed to route later webhooks.
- You choose Sync everything or select specific listings.
Haven does not auto-import listings merely because the account was authorized.
For each selected listing, Haven:
- Fetches the full listing.
- Fetches the listing photo feed.
- Normalizes and persists supported listing, location, amenity, rule, Wi-Fi, and fee fields.
- Creates the Airbnb-to-Haven property mapping.
- Downloads the first visible photos and queues remaining photos when needed.
- Imports the forward per-day calendar, capped at 540 days.
- Imports existing reservations for mapped listings.
- Runs connection-scoped Guest CRM backfill.
- Imports reviews during the property's review-enrichment pass.
New Airbnb listings are automatically imported later only when Auto-import new listings is enabled.
Webhooks are the fast path. Polling is the missed-webhook and reconciliation safety net.
- Calendar and reservations: scheduled approximately hourly, with a roughly 50-minute per-connection cooldown
- Property content, photos, amenities, and fees: scheduled approximately daily, with a roughly 23-hour per-connection cooldown
- Reviews: scheduled approximately every 12 hours, with a roughly 11-hour per-connection cooldown
Polling is skipped while the same connection has an active initial import, avoiding duplicate listing and calendar requests.
- The connection remains pending until Airbnb authorization completes and
channel.activated arrives.
- A healthy channel marks the connection connected.
- Listing import waits for the user's explicit selection.
When channel.deactivated arrives, Haven:
- Marks the connection disconnected
- Cancels queued or in-progress work that can no longer complete
- Stops accepting normal sync work for the connection
The host can reconnect through Haven to establish a fresh active channel.
When a user disconnects in Haven:
- Haven removes the active channel connection associated with Haven.
- Haven removes the integration customer record associated with the Haven connection.
- Haven marks the local connection disconnected and stops its work.
- This disconnects Airbnb from Haven; it does not delete the Airbnb account.
- A deactivated Airbnb listing keeps its Haven property.
- Haven shows the listing's upstream status and refreshes its content.
- Reactivation clears the deactivated status after the next event or refresh.
- Haven removes the Airbnb mapping.
- The Haven property remains available to the account rather than being silently deleted.
- Airbnb-sourced photos are removed from the active synced set.
- The property is marked as removed upstream so the user can archive or relink it.
channel.activated
- Marks a pending connection connected
- Stores channel identity and routing metadata
- Does not import listings until the user chooses what to import
channel.deactivated
- Marks the connection disconnected
- Cancels work for the disconnected connection
Every supported listing event is followed by a full listing API fetch when content must be refreshed.
listing.created
- Imports the listing only when auto-import is enabled
- Otherwise leaves it available for manual selection
listing.changed
- Refetches and updates supported listing content, amenities, fees, and photos
listing.deactivated
- Refetches the listing
- Marks the upstream listing inactive without deleting the Haven property
listing.reactivated
- Refetches the listing
- Clears the upstream-inactive state
listing.deleted
- Detaches the Airbnb mapping
- Keeps the Haven property
- Removes active Airbnb-sourced photos
Calendar and reservation refreshes run through their dedicated poll paths rather than being redundantly launched by each listing webhook.
reservation.created
- Creates or updates a locked unavailable event for a mapped listing
- Creates the inbound reservation mapping used by supported message workflows
- Updates Guest CRM only when a usable non-proxy email is supplied
reservation.changed
- Updates dates and guest counts for the mirrored event
- Removes the event when the status becomes cancelled or voided
- Archives the inbound reservation mapping after cancellation
There is no reservation-deleted action in the supported Airbnb webhook set. Cancellation and void states arrive through reservation.changed.
review.created
- Records that the review window opened
- Does not create a testimonial without public review text
review.submitted
- Refetches the review and upserts eligible public testimonial content
review.published
- Refetches the now-published review and upserts it
review.expired
- Records the lifecycle event
- Does not change testimonial content by itself
review.changed
- Refetches and updates eligible testimonial content
review.response_submitted
- Refetches the review after a response is added
- Updates supported provider-owned review fields without changing host visibility choices
Host-authored reviews and reviews without public text do not become public Haven testimonials.
Every webhook must include a Signature header.
Haven:
- Computes HMAC-SHA256 over the exact raw request body
- Uses the configured webhook secret
- Compares signatures using a timing-safe comparison
- Returns
401 Unauthorized when verification fails
Haven verifies the signature against the raw body, before any parsed representation can change those bytes.
After signature verification, Haven:
- Validates the webhook envelope.
- Uses the event action, customer, listing, or channel identity to find the single owning connection.
- Stores a redacted audit sample.
- Enqueues one background webhook job.
- Runs the matching channel, listing, reservation, or review handler asynchronously.
A webhook for an unmapped or disconnected connection is acknowledged without creating work for another account.
The webhook's unique event ID is Haven's idempotency key.
- Haven uses a database-level provider-plus-event-ID key.
- Rapid duplicate deliveries are skipped within a 60-second deduplication window.
- A duplicate is acknowledged with
200 OK.
- Domain writes also use stable external IDs and upserts so a repeated lifecycle event does not intentionally create a second property, reservation event, or testimonial.
Airbnb's integration delivery service retries a non-200 response up to five times with exponential intervals:
- 1 second
- 5 seconds
- 10 seconds
- 1 hour
- 6 hours
Haven's response behavior:
- Invalid HMAC signature →
401
- Verified duplicate →
200
- Verified but malformed payload →
200 after reporting it, because retrying the same malformed body cannot repair it
- Temporary failure to enqueue the background job →
500, allowing retry
- Successfully enqueued event →
200
- A later background handler failure is recorded on the sync job and does not change the original acknowledgement
There is no user-facing self-service replay control for failed webhook deliveries. Periodic polls are the normal safety net for missed listing, calendar, reservation, and review updates.
The direct Airbnb integration does not expose Airbnb's listing-level discount rules.
Haven does not receive or recreate:
- Weekly or monthly Airbnb discounts
- Last-minute or early-bird discounts
- Smart Pricing rules
- Promotions
- Audience or loyalty discounts
- Seasonal formulas
- Airbnb checkout-only price adjustments
The calendar API supplies a per-day nightly amount. That amount can differ from the discounted figure Airbnb later shows a guest in search or checkout.
Haven uses the supplied per-day amount and does not guess or reconstruct a missing discount. An Airbnb discount is not proof that the same discount exists on Haven.
The direct Airbnb integration does not currently support:
- Importing co-host-only listings
- Creating, modifying, or cancelling Airbnb reservations
- Sending Haven guest or payment data as an Airbnb reservation
- Writing availability blocks or reopening Airbnb dates through the API
- Writing minimum stays
- Writing check-in or check-out restrictions
- Writing listing content, photos, amenities, Wi-Fi, rules, or fees
- Writing discount rules or reproducing Airbnb checkout discounts
- Importing a per-day maximum stay into Haven
- Importing Airbnb conversation history
- Sending free-form Airbnb messages
- Writing reviews or review responses
- Creating Stripe payments, refunds, or payouts from Airbnb financial data
- Syncing Airbnb payout and transaction records into Haven booking accounting
Use iCal for outbound availability, the approved template path for supported guest messages, and Airbnb itself for all other unsupported edits.