Integration guide

The Airbnb API: how access works, and what it actually lets you do

Written for the engineer or technical founder who has been asked to “just connect Airbnb”. It covers how partner access is granted, what the API can and cannot change, and the specific failure modes that make an Airbnb integration look healthy while doing nothing. Every claim here comes from running this integration in production.

What the Airbnb API is

There is no single public “Airbnb API”. What exists is a partner API: a REST surface that Airbnb opens to approved software companies so their customers — hosts and property managers — can run listings from outside airbnb.com. It is not open to anyone with a credit card, and there is no sandbox you can sign up for on a Tuesday afternoon.

The surface itself is broad. A fully authorised connection can read and write listing content, photos, rooms and beds, amenities, the calendar, nightly pricing, booking settings, guest messaging, reservations, reviews, special offers, reservation alterations and payout transactions. The constraints are almost never “the endpoint does not exist”. They are about who authorised what, for which listing.

How do I get Airbnb API access?

Three things have to be true before your first successful write, and they are granted by three different parties.

1. Airbnb approves your company as a software partner. You apply, describe the product you are building, and are reviewed against a product category — property management software, a messaging tool, a pricing tool. Approval brings an OAuth client (a client id and secret) scoped to that category. This is a commercial and compliance review of your business, not a developer sign-up, and it is measured in weeks to months.
2. Each host authorises your app. Approval gets you the ability to ask; it does not get you data. Every host sends themselves through an OAuth consent screen, picks what your app may manage, and grants you tokens for their account. One host, one authorisation.
3. Each listing is opened to the API. This is the step that surprises people, so it has its own section below. Authorising the account does not authorise the listings under it.

On the Repull side that whole flow is one hosted session: your server mints it, you redirect the host, and you get a connection back. The mechanics, including the redirect parameters, are in the Connect Airbnb guide.

curl -X POST 'https://api.repull.dev/v1/connect/airbnb' \
  -H 'Authorization: Bearer sk_live_YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "redirectUrl": "https://yourapp.com/connected", "accessType": "full_access" }'

Which scope should your app ask for?

The consent screen is not one big yes. The host grants a tier, and the tier you ask for decides both what you can do and whether the connection is possible at all.

• Property management (full access) — read plus listing, calendar and pricing writes. What a PMS or channel manager needs.
• Messaging — read everything, plus send guest messages. No listing, calendar or pricing management.
• Read only — listings, reservations, calendars, messages and reviews. The right tier for analytics, reporting and BI.

Narrower tiers also convert better, because the consent screen lists fewer and less alarming permissions. See Connect Airbnb for how to fix a tier per session or let the host choose.

Why a connected account still refuses every write

Airbnb authorises API sync one listing at a time, not one account at a time. Each listing carries its own sync category. A listing whose category is none is closed to the API and Airbnb refuses every write to it, whatever else is true about the account.

The categories that matter:

• sync_all — content, rates and availability are managed through the API.
• sync_rates_and_availability — calendar and pricing writes work; listing content stays with the host.
• none — every write is refused.

Can I update prices and availability through the Airbnb API?

Yes — on a listing that is open to the API, under a property-management grant. This is the part of Airbnb that behaves the way you would hope: per-date writes, applied to the listing calendar, reflected on the listing.

Nightly price, open or closed, minimum and maximum nights, closed-to-arrival and closed-to-departure are all writable per date, alongside listing-level availability rules such as default minimum nights, booking lead time and turnover days.

# Block a range on Airbnb, saying why it is blocked
curl -X PUT 'https://api.repull.dev/v1/channels/airbnb/listings/4118/availability' \
  -H 'Authorization: Bearer sk_live_YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "type": "calendar",
    "operations": [{
      "dates": ["2026-07-01:2026-07-04"],
      "availability": "unavailable",
      "busy_subtype": "OUTSIDE_RESERVATION"
    }]
  }'

Full parameter detail is on Push availability to Airbnb and Update Airbnb pricing. If you want one write to land on every connected channel at once rather than Airbnb alone, that is PUT /v1/availability/{propertyId} — see Update pricing.

Can I change listing content?

Partly, and this is where an Airbnb integration most often quietly fails. Two rules explain nearly all of it.

A publish is not one call

Pushing a listing's content to Airbnb is up to eight independent calls — details, description, amenities, rooms, policies, photos, pricing, checkout tasks — and each can fail on its own. A partial publish is the normal outcome, and there is no rollback: the sections that landed stay applied. Any status model you build that treats publishing as one boolean will be wrong within a week. Report it per section.

A 200 is not proof the change was applied

On an established listing Airbnb treats some content as host-managed and will not accept a change to it through any API. It does not answer with an error. The request returns 200, the response names the locked attributes, and nothing is applied for them. Commonly locked: the title, the summary and space text, the property type category, the check-in option, the address fields, and individual amenities.

Read the locked set up front rather than discovering it by comparison. GET /v1/channels/airbnb/listings/{id}/details returns lockedFields for the listing, and every write returns blockedFields for what your particular request hit. The whole contract — which sections push, what each error code means, what a partial publish looks like — is on the Airbnb publication contract.

Beyond the publish, the granular content surface is real and useful: photos (upload, reorder, set a cover), rooms and beds, amenities, per-locale descriptions, regulatory permits, guest-safety disclosures and the check-in guide.

Messaging, reservations, reviews and alterations

• Messaging — read threads and messages, send, edit, react, mark as read. Available on the messaging tier as well as full access, which is what makes a guest-comms product viable next to an incumbent PMS. Guest messaging.
• Reservations — list and read, with actions on a reservation code. Reservations.
• Alterations — Airbnb is the one major channel with a real alteration flow through the API: create an alteration, read it, accept, decline or cancel. Date and price changes on an Airbnb booking go through it rather than through a direct edit. Alterations.
• Reviews — list, respond, and edit a response. Reviews.
• Special offers and pre-approvals — create and withdraw, which is how you answer an inquiry with a price. Special offers.
• Transactions — payout and financial records, read plus refresh. Transactions.

For a channel-by-channel view of what is supported, partial or unsupported, the capability matrix is the honest version — and it marks partial as partial.

Traps that cost real integrators days

Each of these cost us production time. They are listed in the order they tend to bite.

19-digit ids silently become the wrong account

Modern Airbnb host and listing ids are 19 digits, past 2⁵³ — the largest integer JavaScript represents exactly. Above that, doubles are spaced 256 apart, so JSON.parse snaps the value to a neighbouring, entirely valid-looking id:

JSON.parse('{"user_id":1693389202618766851}').user_id
// → 1693389202618766800   ← a different account

Requests still authenticate, because authentication is the bearer token. But every call keyed on that id — listing enumeration, reservations, availability, messages — then asks about an account that does not exist, and Airbnb answers with an empty result rather than an error. Six hosts across five customers sat like that on our side, every health check green, nothing ever importing.

Read the id out of the raw response text before anything parses it, keep it a string through your whole stack, and compare it as text in the database. Repull returns Airbnb ids as strings everywhere for this reason; see IDs and external IDs.

A 200 that applied nothing

Covered above. The rule to code against: success is an empty blockedFields, not a 2xx.

A healthy account with unwritable listings

Also covered above. Model sync state per listing, not per account, or your dashboard will say connected while three listings silently drift.

Discovering exclusivity during a customer demo

Find out which incumbent your prospective customer uses before you design the consent flow. Asking for property management when the host already granted it elsewhere is a failed connection in front of the customer, and the fix is a product change, not a retry.

Tokens, rate limits and the parts that never stop

Access tokens expire and refresh, hosts revoke, listings are added and removed, Airbnb rate-limits, and the shape of the API moves. An Airbnb integration is not a project with an end date; it is a service you now operate. Budget for the monitoring, the reconnection prompts and the on-call, because they are the majority of the lifetime cost.

What it takes to build this yourself

Honestly, in order:

1. Partner approval. Weeks to months, with a real chance of no. You cannot start engineering against anything but documentation until it lands, and you cannot promise a customer a date.
2. The OAuth and connection lifecycle. Consent, tokens, refresh, scope tiers, revocation, reauthorisation prompts, and a UI that explains an exclusive scope to a non-technical host.
3. The surface itself. Listings, photos, rooms, amenities, descriptions, settings, calendar, pricing, messaging, reservations, reviews, offers, alterations, transactions — each with its own shape, its own partial-failure behaviour, and its own normalisation into whatever model your product actually uses.
4. Correctness work that is invisible until it is not. String ids, locked fields, per-listing sync state, block subtypes, per-section publish results.
5. Ongoing breakage. Upstream changes, deprecations, rate-limit shifts, hosts revoking, listings going dark. This never converges to zero.

It is a genuinely reasonable thing to build if Airbnb connectivity isyour product. It is a poor use of a small team's year if Airbnb is one input to something else you are building — and it gets worse when the second channel arrives, because Booking.com shares almost none of these assumptions. The Booking.com API guide is the comparison.

Where Repull fits

Repull is one REST API and one key across Airbnb, Booking.com, VRBO, Plumguide and 50+ property management systems. We hold the partner relationships; your users connect themselves through a hosted flow that carries your branding; you never handle their credentials.

• One connect flow per channel. POST /v1/connect/{provider} mints a hosted session and hands you back a connection. Connect.
• One calendar write for every channel. PUT /v1/availability/{propertyId} pushes price and availability to every channel a property is connected to; the per-channel routes are there for the settings that exist on one channel only.
• Failure modes surfaced, not smoothed over. Locked fields, per-listing sync state and per-section publish results come back as data you can show a user, because pretending a write landed is worse than reporting that it did not.
• Webhooks with delivery history and replay. Webhooks.

Start at the quickstart, or read the channels overview for the shape of the per-channel surface. If you are a platform embedding this for your own customers rather than integrating for yourself, the guide for platforms covers that model question by question.

Frequently asked questions