Repull
DocumentationStudioAPI ReferenceBuild with AIChannelsKnowledge BaseWebhooks
Docs/Documentation/Errors

booking_rejected

Booking.com refused the change as sent. `message` carries their reason and `booking_ruid` identifies the call to their support.

HTTP 422The request was understood but refused as sent. Change it before retrying.

When it fires

A write passed Repull's own validation, was sent to Booking.com, and Booking.com refused it as sent. It comes from the Booking.com channel writes — PUT /v1/channels/booking/availability and PUT /v1/channels/booking/listings/{id}/pricing.

messageis Booking.com's own reason, passed through unchanged — a rate plan that is not active for the room, a date outside their calendar horizon, a value the rate plan does not accept. booking_ruid is their request id: quote it to Booking.com connectivity support and they can look the call up.

Response shape

Every Repull error follows the same envelope. The code is stable and safe to switch on.

{
  "error": {
    "code": "booking_rejected",
    "message": "Rate 15436997 is not active for room 543250501",
    "fix": "Booking.com refused this change as sent; `message` carries their reason and `booking_ruid` identifies the call in their support tooling. Correct the request and send it again — resending the same body will be refused again.",
    "docs_url": "https://repull.dev/docs/errors/booking_rejected",
    "request_id": "req_01J5X7Y8Z9ABCDEF12345678",
    "upstream_status": 400,
    "booking_ruid": "UmFuZG9tSVYkc2RlIyh9YW1"
  }
}

How to fix

  1. Read `message` — it is Booking.com's reason for refusing the change.
  2. Confirm the room and rate-plan ids with `GET /v1/channels/booking/properties/{id}/rooms`; a rate plan that is not sold on that room is the most common cause.
  3. Correct the request and send it again. Resending the same body is refused again, so do not retry it unchanged.
  4. If the reason points at the property setup rather than the request, fix it in the Booking.com Extranet — then retry.

Common gotchas

  • This is not the partial case. A rate write that carries restrictions is two writes. If one lands and the other is refused you get 200 with applied: "partial", not this error — see Minimum Stay & Restrictions. booking_rejected means nothing was applied at all.
  • Different from booking_error. This one will be refused identically forever, so retrying is pointless. booking_error (502) is their outage — retry that one.

Examples

curl

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": "00000",
      "dateRange": { "start": "2026-07-01", "end": "2026-07-07" },
      "price": 180,
      "currency": "EUR"
    }]
  }'
# → 422 booking_rejected, message carries Booking.com's reason

TypeScript

const res = await fetch('https://api.repull.dev/v1/channels/booking/availability', {
  method: 'PUT',
  headers: {
    Authorization: `Bearer ${process.env.REPULL_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ type: 'rates', property_id: '1234567', updates }),
})

if (!res.ok) {
  const { error } = await res.json()
  if (error.code === 'booking_rejected') {
    // Surface Booking.com's reason and their RUID; do not retry the same body
    throw new Error(`Booking.com refused the change: ${error.message} (RUID ${error.booking_ruid})`)
  }
}

If you're an AI agent

Booking.com refused the change as sent. Read error.message (their reason) and error.booking_ruid (their request id), correct the request, then send it again. Never resend the same body unchanged. A partial result is a 200 with applied: partial, not this error.

Related

Hit an error that isn't covered? Email hello@repull.dev with the request id from the response headers.

Previous← restriction_not_supportedNextbooking_rate_limited →
AI