Docs/Channels/Booking.com

Push Availability to Booking.com

Set rooms to sell, stop-sell, and restrictions on Booking.com per room and rate plan. Inventory lives here and only here — a rates update refuses it. For open/closed on every connected channel at once, use PUT /v1/availability/{propertyId} instead.

PUT/v1/channels/booking/availability

Parameters

typestringRequired

availability for inventory and stop-sell (rates and derived-pricing are covered on Update Booking.com Pricing).

property_idstring | integerRequired

Booking.com property id, connected to your workspace.

updatesarrayRequired

{ roomId, rateId, dateRange: { start, end }, availableRooms, closed?, restrictions? } per item. availableRooms: 0 blocks the room; closed: true stops sale regardless of inventory.

Dates are inclusive at both ends

dateRange.start and dateRange.end are both nights that get written, exactly as on a rates write. To close or open a single night, send the same date twice.

# One night — 2026-11-04
"dateRange": { "start": "2026-11-04", "end": "2026-11-04" }

# Four nights — 2026-11-04, 2026-11-05, 2026-11-06 and 2026-11-07
"dateRange": { "start": "2026-11-04", "end": "2026-11-07" }

Inventory here, prices there

This write carries rooms to sell, the stop-sell flag and restrictions. It carries no rate amount, and the rate write carries no inventory: roomsToSell on a rates update is refused with 422 inventory_not_in_rate_update pointing back here.

The two writes are independent. Opening a night for sale does not price it, and a night that is open with no price on the rate plan you sell does not appear on Booking.com.
Rate amounts, the occupancy they are priced at, and the verification that they went live are on Update Booking.com Pricing.

Notes

Scoped to your workspace: a Booking.com property id that is not connected to your workspace returns 404 not_found, the same answer as an id that does not exist.
Read the current state first with GET /v1/channels/booking/availability?property_id=1234567&start_date=2026-07-01&number_of_days=14.
Writes here go to Booking.com only; restrictions never leak to other channels.
Omit availableRooms and closed for a restriction-only write — inventory is then left untouched. See Minimum Stay & Restrictions for the full restriction set and what a partial result looks like.

Example

# Stop-sell one night
curl -X PUT https://api.repull.dev/v1/channels/booking/availability \
  -H "Authorization: Bearer sk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type": "availability", "property_id": "1234567", "updates": [{"roomId": "123456701", "rateId": "98765", "dateRange": {"start": "2026-11-04", "end": "2026-11-04"}, "availableRooms": 0, "closed": true}]}'

# Reopen a whole week — 2026-07-01 through 2026-07-07 inclusive — with one room to sell
curl -X PUT https://api.repull.dev/v1/channels/booking/availability \
  -H "Authorization: Bearer sk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type": "availability", "property_id": "1234567", "updates": [{"roomId": "123456701", "rateId": "98765", "dateRange": {"start": "2026-07-01", "end": "2026-07-07"}, "availableRooms": 1, "closed": false}]}'

Previous← Update Pricing NextMinimum Stay & Restrictions →