Minimum Stay & Restrictions

Set a minimum stay, a maximum stay, and closed-to-arrival / closed-to-departure on a Booking.com room and rate plan — on their own, or in the same call as a price. The response tells you which of the two actually landed.

What you can set

Every field is optional. Omit one and that restriction is left exactly as it is — nothing you leave out is touched.

Set a minimum stay

A restriction-only write needs no price. roomId and rateId come from GET /v1/channels/booking/properties/{id}/rooms. Dates are inclusive at both ends — start equal to end is exactly 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-07-01", "end": "2026-07-31" },
      "restrictions": { "minStay": 3, "closedToArrival": true }
    }]
  }'

Set a price and a restriction together

Send both in one type: "rates"update. Booking.com receives them as two writes — a rate amount and a restriction notification — so the response reports each separately. A rate amount also needs an occupancy; omit it and Repull resolves it from Booking.com's own data and echoes the value back. See Update Booking.com Pricing.

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": "rates",
    "property_id": "1234567",
    "updates": [{
      "roomId": "123456701",
      "rateId": "98765",
      "dateRange": { "start": "2026-07-01", "end": "2026-07-07" },
      "price": 182,
      "currency": "EUR",
      "occupancy": 4,
      "restrictions": { "minStay": 4 }
    }]
  }'

Reading the result

Booking.com acknowledges a write without saying what happened to each night, so Repull reads the nights back off Booking.com afterwards — prices and restrictions in one read — and reports what is actually live.

What a partial result looks like

The price was written and verified; the minimum stay was refused. This is a 200 — a half that landed is never reported as a failure — and restrictions.rejection.messageis Booking.com's own reason for the half that did not.

{
  "propertyId": "1234567",
  "requested": 1,
  "applied": "partial",
  "occupancy": [
    { "index": 0, "roomId": "123456701", "rateId": "98765", "value": 4, "source": "request" }
  ],
  "price": {
    "requested": 1,
    "applied": "verified",
    "verification": {
      "ran": true,
      "matched": 7,
      "mismatched": 0,
      "rows": [
        { "date": "2026-07-01", "expectedPrice": 182, "bookingPrice": 182, "match": true }
      ]
    },
    "errors": []
  },
  "restrictions": {
    "requested": 1,
    "fields": ["minStay"],
    "dates": [
      { "index": 0, "roomId": "123456701", "rateId": "98765", "start": "2026-07-01", "end": "2026-07-07", "fields": ["minStay"] }
    ],
    "applied": "rejected",
    "verification": { "ran": false, "skippedReason": "not_requested", "matched": 0, "mismatched": 0, "unreported": 0, "rows": [] },
    "errors": [],
    "rejection": {
      "status": 400,
      "message": "Minimum stay is not supported for rate 98765 on room 123456701",
      "ruid": "UmFuZG9tSVYkc2RlIyh9YW1"
    }
  }
}

Act on it in that order: check applied, and when it is partial read each half. The half that landed needs nothing. The half that did not carries rejection.message— Booking.com's words, not a paraphrase — and rejection.ruid, their request id, which Booking.com connectivity support can look up.

const result = await res.json()

if (result.applied === 'partial') {
  // Do NOT re-send the half that already landed.
  if (result.price.applied !== 'verified') {
    console.warn('prices did not land:', result.price.rejection?.message)
  }
  if (result.restrictions.applied !== 'verified') {
    console.warn('restrictions did not land:', result.restrictions.rejection?.message)
    console.warn('affected nights:', result.restrictions.dates)
  }
}

Clearing a restriction

Send false to clear a closed-to-arrival or closed-to-departure flag, and minStay: 1 (or 0) to drop a minimum stay. Omitting the field does not clear it — it leaves whatever is already set.

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-31" },
      "restrictions": { "minStay": 1, "closedToArrival": false }
    }]
  }'

When it fails

• 422 restriction_not_supported — the restriction cannot be written through the API. field names it; nothing was sent.
• 422 booking_rejected — Booking.com refused the whole write. message is their reason, booking_ruid their request id. Resending the same body is refused again.
• 429 booking_rate_limited — back off and put more dates into one request.
• 502 booking_error — Booking.com had an outage. The request is fine; retry with backoff.
• 404 not_found — the property is not connected to your workspace, which is also the answer for an id that does not exist.

Related

• Update Booking.com Pricing — rates, occupancy, and the read-back.
• Push Availability to Booking.com — rooms to sell and stop-sell.
• Manage Properties — where roomId and rateId come from.