Airbnb Rooms & Sleeping Arrangements

The four calls

• {id} is the Repull listing id — from GET /v1/properties or GET /v1/channels/airbnb/listings — not the Airbnb listing id. Repull translates it before calling Airbnb.
• GET /v1/channels/airbnb/listings/{id}/rooms — every room in room-number order, each with its beds. Served from Repull's copy; never calls Airbnb.
• POST /v1/channels/airbnb/listings/{id}/rooms — create a room, optionally with its beds in the same call.
• PUT /v1/channels/airbnb/listings/{id}/rooms?roomId=... — change a room's type, number, privacy, room amenities or beds. Send only the fields you want to change.
• DELETE /v1/channels/airbnb/listings/{id}/rooms?roomId=... — remove the room and its beds.

Sleeping arrangements

Beds ride on the room object — there is no separate endpoint. beds replaces the room's whole arrangement, which is Airbnb's own semantics for the field, so always send the complete list. An empty array clears it.

• Bed types seen on live listings: king_bed, queen_bed, double_bed, small_double_bed, single_bed, bunk_bed, sofa_bed, couch, air_mattress, floor_mattress, toddler_bed, crib, hammock.
• The list above is a guide, not a closed set. Airbnb's vocabulary drifts, so Repull validates the shape (lowercase snake_case, quantity a whole number of 1 or more) and lets Airbnb answer on the value itself — an unknown type comes back as 422 airbnb_rejected carrying Airbnb's own message, rather than being refused here on a stale list.
• quantity is how many beds of that type are in the room, 1 to 20.

# One queen and a sofa bed in the main bedroom
curl -X PUT 'https://api.repull.dev/v1/channels/airbnb/listings/4118/rooms?roomId=824113' \
  -H "Authorization: Bearer sk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"beds": [{"type": "queen_bed", "quantity": 1}, {"type": "sofa_bed", "quantity": 1}]}'

Rooms are addressed by room id upstream

Airbnb's room endpoints take a room id with no listing attached, so the listing in your path does not constrain them on Airbnb's side. Repull proves the room belongs to that listing before sending anything: a room id from one of your other listings returns 404 — the same answer a room that does not exist gets. This closes a real hole, where a DELETE could reach a room on a different listing than the one named in the path.

Errors

A successful write returns 200 (201 for a create).

• 422 invalid_params — the body failed validation before anything was sent to Airbnb. field names the field (for example operations.0.max_nights), value_received echoes it and fix says what to send.
• 422 airbnb_rejected — Airbnb refused the change. message carries Airbnb's own reason. Correct the request; sending the same body again is refused again.
• 403 listing_not_api_connected — Airbnb API sync is off for this listing (its sync category is none), so Airbnb accepts no writes to it and nothing was sent. Reconnecting the Airbnb account does not fix this — the host has to turn API sync on for that one listing inside Airbnb. See the section above, and https://repull.dev/docs/errors/listing_not_api_connected
• 403 connection_reauth_required — the host's Airbnb authorization expired or was revoked, or Airbnb refused to refresh it. This takes the whole account down, not one listing. Retrying will not help. Reconnect Airbnb at https://repull.dev/dashboard/connections (or POST /v1/connect/airbnb), then retry.
• 403 listing_inactive — the listing is inactive. Activate it with PATCH /v1/listings/{id} and {"active": true}, then retry.
• 404 not_found — no Airbnb-connected listing with this id in your workspace. Check the id is the Repull listing id. 404 no_connection — the workspace has no Airbnb connection at all.
• 429 airbnb_rate_limited — Airbnb is rate-limiting writes for this host. Wait retry_after seconds when present, otherwise back off exponentially, and put many dates in one operations array instead of one call per date.
• 502 airbnb_error — Airbnb had an outage or timed out. Nothing about the request needs to change: retry with backoff.