repull 0.2.15 → 0.2.16

data/lib/repull/api/booking_com_api.rb

@@ -485,13 +485,14 @@ module Repull
     end
 
     # Get Booking.com pricing for a listing
-    # Resolves the Vanio listing ID to its Booking.com `hotel_id` (via the `listings_booking` mapping owned by the authenticated workspace), then proxies Booking's `getRoomRateAvailability` for the requested window. Pricing on Booking is per-room/per-rate-plan, so `room_id` and `room_level` flow through query params unchanged.  Mirrors the per-channel `/listings/{id}/pricing` shape used by Airbnb so SDK consumers can carry a Vanio listing ID across channels.  Returns `403 listing_inactive` when the listing is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
-    # @param id [Integer] Vanio listing ID — resolved to a Booking.com hotel ID via the workspace mapping.
+    # Resolves the Repull listing id to its Booking.com `hotel_id` (via the room mapping the Connect flow records for the authenticated workspace), then proxies Booking's `getRoomRateAvailability` for the requested window. Pricing on Booking is per-room/per-rate-plan, so `room_id` and `room_level` flow through query params unchanged.  Mirrors the per-channel `/listings/{id}/pricing` shape used by Airbnb so SDK consumers can carry a Repull listing id across channels. `id` is a Repull listing id, never a Booking.com hotel id — the hotel-id surface is `/v1/channels/booking/availability`.  A listing can be published under several Booking.com properties. GET uses the oldest and reports the rest in `otherHotelIds`; PUT refuses with `409 ambiguous_booking_mapping` rather than push rates into a property it guessed at. `?hotel_id=` names the property explicitly for either.  Returns `403 listing_inactive` when the listing is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
+    # @param id [Integer] Repull listing id — NOT a Booking.com hotel id. Resolved to a Booking.com hotel id via the workspace mapping.
     # @param [Hash] opts the optional parameters
     # @option opts [Date] :start_date 
     # @option opts [Integer] :number_of_days 
     # @option opts [String] :room_id 
     # @option opts [Boolean] :room_level When true, returns room-level (vs rate-plan-level) availability.
+    # @option opts [String] :hotel_id Booking.com hotel id, when this listing is published under more than one property. Omit it and a read uses the oldest mapping (reporting the rest in `otherHotelIds`), while a write is refused with `409 ambiguous_booking_mapping` rather than guess. `GET /v1/channels/booking/properties` lists the valid ids.
     # @return [BookingPricingResponse]
     def get_booking_listing_pricing(id, opts = {})
       data, _status_code, _headers = get_booking_listing_pricing_with_http_info(id, opts)
@@ -499,13 +500,14 @@ module Repull
     end
 
     # Get Booking.com pricing for a listing
-    # Resolves the Vanio listing ID to its Booking.com `hotel_id` (via the `listings_booking` mapping owned by the authenticated workspace), then proxies Booking's `getRoomRateAvailability` for the requested window. Pricing on Booking is per-room/per-rate-plan, so `room_id` and `room_level` flow through query params unchanged.  Mirrors the per-channel `/listings/{id}/pricing` shape used by Airbnb so SDK consumers can carry a Vanio listing ID across channels.  Returns `403 listing_inactive` when the listing is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
-    # @param id [Integer] Vanio listing ID — resolved to a Booking.com hotel ID via the workspace mapping.
+    # Resolves the Repull listing id to its Booking.com `hotel_id` (via the room mapping the Connect flow records for the authenticated workspace), then proxies Booking's `getRoomRateAvailability` for the requested window. Pricing on Booking is per-room/per-rate-plan, so `room_id` and `room_level` flow through query params unchanged.  Mirrors the per-channel `/listings/{id}/pricing` shape used by Airbnb so SDK consumers can carry a Repull listing id across channels. `id` is a Repull listing id, never a Booking.com hotel id — the hotel-id surface is `/v1/channels/booking/availability`.  A listing can be published under several Booking.com properties. GET uses the oldest and reports the rest in `otherHotelIds`; PUT refuses with `409 ambiguous_booking_mapping` rather than push rates into a property it guessed at. `?hotel_id=` names the property explicitly for either.  Returns `403 listing_inactive` when the listing is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
+    # @param id [Integer] Repull listing id — NOT a Booking.com hotel id. Resolved to a Booking.com hotel id via the workspace mapping.
     # @param [Hash] opts the optional parameters
     # @option opts [Date] :start_date 
     # @option opts [Integer] :number_of_days 
     # @option opts [String] :room_id 
     # @option opts [Boolean] :room_level When true, returns room-level (vs rate-plan-level) availability.
+    # @option opts [String] :hotel_id Booking.com hotel id, when this listing is published under more than one property. Omit it and a read uses the oldest mapping (reporting the rest in `otherHotelIds`), while a write is refused with `409 ambiguous_booking_mapping` rather than guess. `GET /v1/channels/booking/properties` lists the valid ids.
     # @return [Array<(BookingPricingResponse, Integer, Hash)>] BookingPricingResponse data, response status code and response headers
     def get_booking_listing_pricing_with_http_info(id, opts = {})
       if @api_client.config.debugging
@@ -524,6 +526,7 @@ module Repull
       query_params[:'number_of_days'] = opts[:'number_of_days'] if !opts[:'number_of_days'].nil?
       query_params[:'room_id'] = opts[:'room_id'] if !opts[:'room_id'].nil?
       query_params[:'room_level'] = opts[:'room_level'] if !opts[:'room_level'].nil?
+      query_params[:'hotel_id'] = opts[:'hotel_id'] if !opts[:'hotel_id'].nil?
 
       # header parameters
       header_params = opts[:header_params] || {}
@@ -560,8 +563,8 @@ module Repull
     end
 
     # Get Booking.com connection for a listing
-    # Return the Booking.com connection record(s) for a Vanio listing — the linked Booking hotel id, sync flags, markup, sync category, and suspension state. Scoped to the authenticated workspace; a listing with no Booking.com connection returns 404.  Returns `403 listing_inactive` when the listing is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
-    # @param id [Integer] Vanio listing ID.
+    # Return the Booking.com connection record(s) for a Repull listing — the linked Booking hotel id, sync flags, markup, sync category, suspension state, and the Booking room the mapping runs through.  `id` is a **Repull listing id**, not a Booking.com hotel id, despite the `properties` segment. (The hotel-id surface is `/v1/channels/booking/availability`.) The mapping is read from wherever the Connect flow recorded it — `listings_booking_rooms` for anything mapped through `POST /v1/connect/booking/map-rooms`, which is essentially every live mapping.  An ARRAY, because one listing can be published under several Booking.com properties at once; `mappedVia` says which record carries each mapping. A listing with no Booking.com mapping returns 404, and the message says which id space the path takes.  Returns `403 listing_inactive` when the listing is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
+    # @param id [Integer] Repull listing id — NOT a Booking.com hotel id.
     # @param [Hash] opts the optional parameters
     # @return [nil]
     def get_booking_property(id, opts = {})
@@ -570,8 +573,8 @@ module Repull
     end
 
     # Get Booking.com connection for a listing
-    # Return the Booking.com connection record(s) for a Vanio listing — the linked Booking hotel id, sync flags, markup, sync category, and suspension state. Scoped to the authenticated workspace; a listing with no Booking.com connection returns 404.  Returns &#x60;403 listing_inactive&#x60; when the listing is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
-    # @param id [Integer] Vanio listing ID.
+    # Return the Booking.com connection record(s) for a Repull listing — the linked Booking hotel id, sync flags, markup, sync category, suspension state, and the Booking room the mapping runs through.  &#x60;id&#x60; is a **Repull listing id**, not a Booking.com hotel id, despite the &#x60;properties&#x60; segment. (The hotel-id surface is &#x60;/v1/channels/booking/availability&#x60;.) The mapping is read from wherever the Connect flow recorded it — &#x60;listings_booking_rooms&#x60; for anything mapped through &#x60;POST /v1/connect/booking/map-rooms&#x60;, which is essentially every live mapping.  An ARRAY, because one listing can be published under several Booking.com properties at once; &#x60;mappedVia&#x60; says which record carries each mapping. A listing with no Booking.com mapping returns 404, and the message says which id space the path takes.  Returns &#x60;403 listing_inactive&#x60; when the listing is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
+    # @param id [Integer] Repull listing id — NOT a Booking.com hotel id.
     # @param [Hash] opts the optional parameters
     # @return [Array<(nil, Integer, Hash)>] nil, response status code and response headers
     def get_booking_property_with_http_info(id, opts = {})
@@ -680,7 +683,7 @@ module Repull
     end
 
     # List Booking.com properties
-    # List Booking.com hotels claimed by this workspace. Each row includes the Booking-side hotel id and the connected room types.  Inactive listings are left out; they keep syncing and reappear once activated. Use `GET /v1/listings?status=inactive` to find them.
+    # List every Booking.com property this workspace holds. Each property is returned ONCE, with the Repull listings mapped under it.  A Booking.com property is a building; its rooms are what guests book, and each room is mapped to one Repull listing — so one property routinely carries many listings. `listings[].roomBookingId` is the Booking.com room id an ARI write takes.  A property whose rooms are not mapped yet is still listed, with `mappingStatus: \"unmapped\"` and an empty `listings` array. That is a real mid-onboarding state, not an error: finish `POST /v1/connect/booking/map-rooms` and the listings appear. Such a property used to be dropped silently, which made a mapped-but-unreadable workspace indistinguishable from one with no Booking connection at all.  Inactive listings are left out of `listings`; they keep syncing and reappear once activated. Use `GET /v1/listings?status=inactive` to find them.
     # @param [Hash] opts the optional parameters
     # @return [Array<BookingProperty>]
     def list_booking_properties(opts = {})
@@ -689,7 +692,7 @@ module Repull
     end
 
     # List Booking.com properties
-    # List Booking.com hotels claimed by this workspace. Each row includes the Booking-side hotel id and the connected room types.  Inactive listings are left out; they keep syncing and reappear once activated. Use &#x60;GET /v1/listings?status&#x3D;inactive&#x60; to find them.
+    # List every Booking.com property this workspace holds. Each property is returned ONCE, with the Repull listings mapped under it.  A Booking.com property is a building; its rooms are what guests book, and each room is mapped to one Repull listing — so one property routinely carries many listings. &#x60;listings[].roomBookingId&#x60; is the Booking.com room id an ARI write takes.  A property whose rooms are not mapped yet is still listed, with &#x60;mappingStatus: \&quot;unmapped\&quot;&#x60; and an empty &#x60;listings&#x60; array. That is a real mid-onboarding state, not an error: finish &#x60;POST /v1/connect/booking/map-rooms&#x60; and the listings appear. Such a property used to be dropped silently, which made a mapped-but-unreadable workspace indistinguishable from one with no Booking connection at all.  Inactive listings are left out of &#x60;listings&#x60;; they keep syncing and reappear once activated. Use &#x60;GET /v1/listings?status&#x3D;inactive&#x60; to find them.
     # @param [Hash] opts the optional parameters
     # @return [Array<(Array<BookingProperty>, Integer, Hash)>] Array<BookingProperty> data, response status code and response headers
     def list_booking_properties_with_http_info(opts = {})
@@ -737,9 +740,10 @@ module Repull
     end
 
     # List Booking.com rooms + rate-plan ids for a listing
-    # Return every Booking.com room and its rate plans for a listing, each with the `roomId` / `rateId` needed to assemble a restriction write via `PUT /v1/channels/booking/availability`.  `id` is a Vanio listing id — resolved to the Booking `hotel_id` via the workspace mapping (a listing with no active Booking.com mapping returns 404). Sourced from Booking's B.XML roomrates feed, which returns rooms and rate plans together (the rooms-unit feed alone omits rate-plan ids). This is the API-key surface for the room/rate ids that were previously only reachable inside the hosted Connect room-mapping flow.  Returns `403 listing_inactive` when the listing is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
-    # @param id [Integer] Vanio listing id — resolved to a Booking.com hotel id via the workspace mapping.
+    # Return every Booking.com room and its rate plans for a listing, each with the `roomId` / `rateId` needed to assemble a restriction write via `PUT /v1/channels/booking/availability`.  `id` is a **Repull listing id**, not a Booking.com hotel id, despite the `properties` segment — resolved to the Booking `hotel_id` through the workspace mapping, read from wherever the Connect flow recorded it (`listings_booking_rooms` for anything mapped through `POST /v1/connect/booking/map-rooms`). A listing with no active Booking.com mapping returns 404, and the message says which id space the path takes. When the listing is published under several properties the oldest is used, the rest come back in `otherHotelIds`, and `?hotel_id=` names a different one. Sourced from Booking's B.XML roomrates feed, which returns rooms and rate plans together (the rooms-unit feed alone omits rate-plan ids). This is the API-key surface for the room/rate ids that were previously only reachable inside the hosted Connect room-mapping flow.  `source` says where the answer came from. `booking` means it was read live just now. If Booking.com returns nothing usable for the property, the rooms and rate plans recorded at the last import are served instead, `source` is `mirror`, and `mirrorReason` names what went wrong live — the ids are Booking.com's own and can be written against, but they can be stale, and `maxPersons`, `policy`, `policyId`, `pricingType` and `isChildRate` come back `null` because only the live feed states them. `rooms` is empty only when Booking.com and the last import both have nothing; a read that failed is an error, never an empty list.  Each rate plan carries `maxPersons` — the party size that rate plan prices, which is the `occupancy` a rate amount must be written at. Each room carries `maxAdults`, Booking.com's capacity for the room, which is what a rate write falls back to when the rate plan states no `maxPersons`.  Returns `403 listing_inactive` when the listing is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
+    # @param id [Integer] Repull listing id — NOT a Booking.com hotel id. Resolved to a Booking.com hotel id via the workspace mapping.
     # @param [Hash] opts the optional parameters
+    # @option opts [String] :hotel_id Booking.com hotel id, when this listing is published under more than one property. Omit it and a read uses the oldest mapping (reporting the rest in &#x60;otherHotelIds&#x60;), while a write is refused with &#x60;409 ambiguous_booking_mapping&#x60; rather than guess. &#x60;GET /v1/channels/booking/properties&#x60; lists the valid ids.
     # @return [BookingRoomsRatesResponse]
     def list_booking_property_rooms(id, opts = {})
       data, _status_code, _headers = list_booking_property_rooms_with_http_info(id, opts)
@@ -747,9 +751,10 @@ module Repull
     end
 
     # List Booking.com rooms + rate-plan ids for a listing
-    # Return every Booking.com room and its rate plans for a listing, each with the &#x60;roomId&#x60; / &#x60;rateId&#x60; needed to assemble a restriction write via &#x60;PUT /v1/channels/booking/availability&#x60;.  &#x60;id&#x60; is a Vanio listing id — resolved to the Booking &#x60;hotel_id&#x60; via the workspace mapping (a listing with no active Booking.com mapping returns 404). Sourced from Booking&#39;s B.XML roomrates feed, which returns rooms and rate plans together (the rooms-unit feed alone omits rate-plan ids). This is the API-key surface for the room/rate ids that were previously only reachable inside the hosted Connect room-mapping flow.  Returns &#x60;403 listing_inactive&#x60; when the listing is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
-    # @param id [Integer] Vanio listing id — resolved to a Booking.com hotel id via the workspace mapping.
+    # Return every Booking.com room and its rate plans for a listing, each with the &#x60;roomId&#x60; / &#x60;rateId&#x60; needed to assemble a restriction write via &#x60;PUT /v1/channels/booking/availability&#x60;.  &#x60;id&#x60; is a **Repull listing id**, not a Booking.com hotel id, despite the &#x60;properties&#x60; segment — resolved to the Booking &#x60;hotel_id&#x60; through the workspace mapping, read from wherever the Connect flow recorded it (&#x60;listings_booking_rooms&#x60; for anything mapped through &#x60;POST /v1/connect/booking/map-rooms&#x60;). A listing with no active Booking.com mapping returns 404, and the message says which id space the path takes. When the listing is published under several properties the oldest is used, the rest come back in &#x60;otherHotelIds&#x60;, and &#x60;?hotel_id&#x3D;&#x60; names a different one. Sourced from Booking&#39;s B.XML roomrates feed, which returns rooms and rate plans together (the rooms-unit feed alone omits rate-plan ids). This is the API-key surface for the room/rate ids that were previously only reachable inside the hosted Connect room-mapping flow.  &#x60;source&#x60; says where the answer came from. &#x60;booking&#x60; means it was read live just now. If Booking.com returns nothing usable for the property, the rooms and rate plans recorded at the last import are served instead, &#x60;source&#x60; is &#x60;mirror&#x60;, and &#x60;mirrorReason&#x60; names what went wrong live — the ids are Booking.com&#39;s own and can be written against, but they can be stale, and &#x60;maxPersons&#x60;, &#x60;policy&#x60;, &#x60;policyId&#x60;, &#x60;pricingType&#x60; and &#x60;isChildRate&#x60; come back &#x60;null&#x60; because only the live feed states them. &#x60;rooms&#x60; is empty only when Booking.com and the last import both have nothing; a read that failed is an error, never an empty list.  Each rate plan carries &#x60;maxPersons&#x60; — the party size that rate plan prices, which is the &#x60;occupancy&#x60; a rate amount must be written at. Each room carries &#x60;maxAdults&#x60;, Booking.com&#39;s capacity for the room, which is what a rate write falls back to when the rate plan states no &#x60;maxPersons&#x60;.  Returns &#x60;403 listing_inactive&#x60; when the listing is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
+    # @param id [Integer] Repull listing id — NOT a Booking.com hotel id. Resolved to a Booking.com hotel id via the workspace mapping.
     # @param [Hash] opts the optional parameters
+    # @option opts [String] :hotel_id Booking.com hotel id, when this listing is published under more than one property. Omit it and a read uses the oldest mapping (reporting the rest in &#x60;otherHotelIds&#x60;), while a write is refused with &#x60;409 ambiguous_booking_mapping&#x60; rather than guess. &#x60;GET /v1/channels/booking/properties&#x60; lists the valid ids.
     # @return [Array<(BookingRoomsRatesResponse, Integer, Hash)>] BookingRoomsRatesResponse data, response status code and response headers
     def list_booking_property_rooms_with_http_info(id, opts = {})
       if @api_client.config.debugging
@@ -764,6 +769,7 @@ module Repull
 
       # query parameters
       query_params = opts[:query_params] || {}
+      query_params[:'hotel_id'] = opts[:'hotel_id'] if !opts[:'hotel_id'].nil?
 
       # header parameters
       header_params = opts[:header_params] || {}
@@ -1059,7 +1065,7 @@ module Repull
     end
 
     # Send Booking.com message
-    # Send a message in a Booking.com conversation as the host. Booking enforces content rules similar to Airbnb.  `property_id` must be a Booking.com property connected to this workspace (`GET /v1/channels/booking/properties` lists them). Any other id — including one connected to a different workspace — returns `404 not_found`, the same answer as an id that does not exist.  Returns `403 listing_inactive` when any listing mapped to the Booking.com property is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
+    # Send a text message in a Booking.com conversation as the host. Booking enforces content rules similar to Airbnb.  **Text only.** To send photos, use `POST /v1/conversations/{id}/messages` with `attachments` (JPEG or PNG, up to 10 MB each, with message text) — it uploads the files to Booking.com and records them in the conversation. Passing `attachments`, `attachment_ids` or `mediaUrl` here returns `422 attachments_not_supported` and sends nothing.  `property_id` must be a Booking.com property connected to this workspace (`GET /v1/channels/booking/properties` lists them). Any other id — including one connected to a different workspace — returns `404 not_found`, the same answer as an id that does not exist.  Returns `403 listing_inactive` when any listing mapped to the Booking.com property is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
     # @param send_booking_message_request [SendBookingMessageRequest] 
     # @param [Hash] opts the optional parameters
     # @return [nil]
@@ -1069,7 +1075,7 @@ module Repull
     end
 
     # Send Booking.com message
-    # Send a message in a Booking.com conversation as the host. Booking enforces content rules similar to Airbnb.  &#x60;property_id&#x60; must be a Booking.com property connected to this workspace (&#x60;GET /v1/channels/booking/properties&#x60; lists them). Any other id — including one connected to a different workspace — returns &#x60;404 not_found&#x60;, the same answer as an id that does not exist.  Returns &#x60;403 listing_inactive&#x60; when any listing mapped to the Booking.com property is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
+    # Send a text message in a Booking.com conversation as the host. Booking enforces content rules similar to Airbnb.  **Text only.** To send photos, use &#x60;POST /v1/conversations/{id}/messages&#x60; with &#x60;attachments&#x60; (JPEG or PNG, up to 10 MB each, with message text) — it uploads the files to Booking.com and records them in the conversation. Passing &#x60;attachments&#x60;, &#x60;attachment_ids&#x60; or &#x60;mediaUrl&#x60; here returns &#x60;422 attachments_not_supported&#x60; and sends nothing.  &#x60;property_id&#x60; must be a Booking.com property connected to this workspace (&#x60;GET /v1/channels/booking/properties&#x60; lists them). Any other id — including one connected to a different workspace — returns &#x60;404 not_found&#x60;, the same answer as an id that does not exist.  Returns &#x60;403 listing_inactive&#x60; when any listing mapped to the Booking.com property is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
     # @param send_booking_message_request [SendBookingMessageRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(nil, Integer, Hash)>] nil, response status code and response headers
@@ -1127,20 +1133,20 @@ module Repull
     end
 
     # Update Booking.com rates/availability
-    # Push availability, rates, and the full restriction set to Booking.com. `type` selects the write path:  - `rates` — nightly price + length-of-stay / arrival restrictions (min/max stay, closed-to-arrival, closed-to-departure, advance-reservation window). - `availability` — inventory (`availableRooms`), the dedicated stop-sell flag (`closed`), and the same restriction set. - `derived-pricing` — occupancy-derived pricing rules.  Restrictions never leak across channels — this endpoint writes only to Booking.com. Errors from upstream surface as `booking_error`.  `property_id` must be a Booking.com property connected to this workspace (`GET /v1/channels/booking/properties` lists them). Any other id — including one connected to a different workspace — returns `404 not_found`, the same answer as an id that does not exist.  Returns `403 listing_inactive` when any listing mapped to the Booking.com property is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
+    # Write rates, availability and restrictions to a Booking.com property. `type` selects the write:  - `rates` — nightly prices, plus any length-of-stay / arrival restrictions sent with them. - `availability` — inventory (`availableRooms`), the stop-sell flag (`closed`), and restrictions. Omit `availableRooms` and `closed` for a restriction-only write. - `derived-pricing` — occupancy-derived pricing rules.  **Dates are inclusive at both ends.** `{ \"start\": \"2026-11-04\", \"end\": \"2026-11-04\" }` is exactly one night.  **A rate amount needs an occupancy.** Booking.com stores the amount against the party size the rate plan prices: sent above that number it declines the price in silence, sent below it it answers 400. Send `occupancy`, or omit it and Repull resolves it from Booking.com's own data and echoes the value and its `source` back in `occupancy[]`. If it cannot be resolved the write is refused with `422` naming `updates[N].occupancy`.  **Restrictions are sent in the same call, on their own wire.** A price and a minimum stay are two writes on Booking.com's side. Send them together and the response reports each separately: `price` and `restrictions` carry their own state, their own read-back, and — when refused — Booking.com's own reason. The top-level `applied` is `partial` when they disagree, so a price that landed is never reported as a failure. `minStay`, `maxStay`, `minStayArrival`, `maxStayArrival`, `closedToArrival` and `closedToDeparture` are written; `exactStayArrival`, `minAdvanceRes` and `maxAdvanceRes` are refused with `422 restriction_not_supported` because Booking.com's notification has no element for them — set those on the rate plan in the Extranet. Nothing you send is ever silently ignored.  **Inventory is not part of a rate update.** `roomsToSell` on a `rates` update returns `422 inventory_not_in_rate_update`; send it as `type: \"availability\"` instead.  **The response says what is known.** Booking.com acknowledges a write with no per-date status, so the nights are read back — prices and restrictions out of the same read: `applied` is `verified`, `mismatch`, `partial`, `rejected` or `unverified` (send `verify: false` to skip the read-back). A bare acknowledgement is never reported as \"all updates applied\". Booking.com stores a 1-night minimum as no minimum, so `minStay: 1` reads back as `0` and still counts as applied.  Restrictions never leak across channels — this endpoint writes only to Booking.com. When Booking.com refuses a write outright, their own reason comes back as `422 booking_rejected` with `booking_ruid`; a genuine outage on their side is `502 booking_error`.  `property_id` must be a Booking.com property connected to this workspace (`GET /v1/channels/booking/properties` lists them). Any other id — including one connected to a different workspace — returns `404 not_found`, the same answer as an id that does not exist.  Returns `403 listing_inactive` when any listing mapped to the Booking.com property is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
     # @param booking_availability_update_request [BookingAvailabilityUpdateRequest] 
     # @param [Hash] opts the optional parameters
-    # @return [nil]
+    # @return [BookingPricingUpdateResponse]
     def update_booking_availability(booking_availability_update_request, opts = {})
-      update_booking_availability_with_http_info(booking_availability_update_request, opts)
-      nil
+      data, _status_code, _headers = update_booking_availability_with_http_info(booking_availability_update_request, opts)
+      data
     end
 
     # Update Booking.com rates/availability
-    # Push availability, rates, and the full restriction set to Booking.com. &#x60;type&#x60; selects the write path:  - &#x60;rates&#x60; — nightly price + length-of-stay / arrival restrictions (min/max stay, closed-to-arrival, closed-to-departure, advance-reservation window). - &#x60;availability&#x60; — inventory (&#x60;availableRooms&#x60;), the dedicated stop-sell flag (&#x60;closed&#x60;), and the same restriction set. - &#x60;derived-pricing&#x60; — occupancy-derived pricing rules.  Restrictions never leak across channels — this endpoint writes only to Booking.com. Errors from upstream surface as &#x60;booking_error&#x60;.  &#x60;property_id&#x60; must be a Booking.com property connected to this workspace (&#x60;GET /v1/channels/booking/properties&#x60; lists them). Any other id — including one connected to a different workspace — returns &#x60;404 not_found&#x60;, the same answer as an id that does not exist.  Returns &#x60;403 listing_inactive&#x60; when any listing mapped to the Booking.com property is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
+    # Write rates, availability and restrictions to a Booking.com property. &#x60;type&#x60; selects the write:  - &#x60;rates&#x60; — nightly prices, plus any length-of-stay / arrival restrictions sent with them. - &#x60;availability&#x60; — inventory (&#x60;availableRooms&#x60;), the stop-sell flag (&#x60;closed&#x60;), and restrictions. Omit &#x60;availableRooms&#x60; and &#x60;closed&#x60; for a restriction-only write. - &#x60;derived-pricing&#x60; — occupancy-derived pricing rules.  **Dates are inclusive at both ends.** &#x60;{ \&quot;start\&quot;: \&quot;2026-11-04\&quot;, \&quot;end\&quot;: \&quot;2026-11-04\&quot; }&#x60; is exactly one night.  **A rate amount needs an occupancy.** Booking.com stores the amount against the party size the rate plan prices: sent above that number it declines the price in silence, sent below it it answers 400. Send &#x60;occupancy&#x60;, or omit it and Repull resolves it from Booking.com&#39;s own data and echoes the value and its &#x60;source&#x60; back in &#x60;occupancy[]&#x60;. If it cannot be resolved the write is refused with &#x60;422&#x60; naming &#x60;updates[N].occupancy&#x60;.  **Restrictions are sent in the same call, on their own wire.** A price and a minimum stay are two writes on Booking.com&#39;s side. Send them together and the response reports each separately: &#x60;price&#x60; and &#x60;restrictions&#x60; carry their own state, their own read-back, and — when refused — Booking.com&#39;s own reason. The top-level &#x60;applied&#x60; is &#x60;partial&#x60; when they disagree, so a price that landed is never reported as a failure. &#x60;minStay&#x60;, &#x60;maxStay&#x60;, &#x60;minStayArrival&#x60;, &#x60;maxStayArrival&#x60;, &#x60;closedToArrival&#x60; and &#x60;closedToDeparture&#x60; are written; &#x60;exactStayArrival&#x60;, &#x60;minAdvanceRes&#x60; and &#x60;maxAdvanceRes&#x60; are refused with &#x60;422 restriction_not_supported&#x60; because Booking.com&#39;s notification has no element for them — set those on the rate plan in the Extranet. Nothing you send is ever silently ignored.  **Inventory is not part of a rate update.** &#x60;roomsToSell&#x60; on a &#x60;rates&#x60; update returns &#x60;422 inventory_not_in_rate_update&#x60;; send it as &#x60;type: \&quot;availability\&quot;&#x60; instead.  **The response says what is known.** Booking.com acknowledges a write with no per-date status, so the nights are read back — prices and restrictions out of the same read: &#x60;applied&#x60; is &#x60;verified&#x60;, &#x60;mismatch&#x60;, &#x60;partial&#x60;, &#x60;rejected&#x60; or &#x60;unverified&#x60; (send &#x60;verify: false&#x60; to skip the read-back). A bare acknowledgement is never reported as \&quot;all updates applied\&quot;. Booking.com stores a 1-night minimum as no minimum, so &#x60;minStay: 1&#x60; reads back as &#x60;0&#x60; and still counts as applied.  Restrictions never leak across channels — this endpoint writes only to Booking.com. When Booking.com refuses a write outright, their own reason comes back as &#x60;422 booking_rejected&#x60; with &#x60;booking_ruid&#x60;; a genuine outage on their side is &#x60;502 booking_error&#x60;.  &#x60;property_id&#x60; must be a Booking.com property connected to this workspace (&#x60;GET /v1/channels/booking/properties&#x60; lists them). Any other id — including one connected to a different workspace — returns &#x60;404 not_found&#x60;, the same answer as an id that does not exist.  Returns &#x60;403 listing_inactive&#x60; when any listing mapped to the Booking.com property is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
     # @param booking_availability_update_request [BookingAvailabilityUpdateRequest] 
     # @param [Hash] opts the optional parameters
-    # @return [Array<(nil, Integer, Hash)>] nil, response status code and response headers
+    # @return [Array<(BookingPricingUpdateResponse, Integer, Hash)>] BookingPricingUpdateResponse data, response status code and response headers
     def update_booking_availability_with_http_info(booking_availability_update_request, opts = {})
       if @api_client.config.debugging
         @api_client.config.logger.debug 'Calling API: BookingComApi.update_booking_availability ...'
@@ -1172,7 +1178,7 @@ module Repull
       post_body = opts[:debug_body] || @api_client.object_to_http_body(booking_availability_update_request)
 
       # return_type
-      return_type = opts[:debug_return_type]
+      return_type = opts[:debug_return_type] || 'BookingPricingUpdateResponse'
 
       # auth_names
       auth_names = opts[:debug_auth_names] || ['bearerAuth']
@@ -1320,10 +1326,11 @@ module Repull
     end
 
     # Update Booking.com pricing for a listing
-    # Pushes one or more rate updates to Booking.com via `updateRates`. Each update needs `roomId` + `rateId` + `dateRange` + `price` + `currency`. Field-level validation runs up front so callers don't have to parse Booking's XML error envelope to discover a missing `roomId`.  Returns `403 listing_inactive` when the listing is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
-    # @param id [Integer] 
+    # Writes nightly prices for a listing's Booking.com room + rate plan. Each update needs `roomId` + `rateId` + `dateRange` + `price` + `currency`; `dateRange` is inclusive at both ends, so `start` equal to `end` writes exactly one night.  **Occupancy.** Booking.com stores a rate amount against the party size the rate plan prices. Send `occupancy` and that is what is used; omit it and it is resolved from Booking.com's own data for that (room, rate plan) and echoed back in `occupancy[]` with its `source`. When it cannot be resolved the write is refused with `422` naming `updates[N].occupancy` — a price is never sent at a guessed party size, because Booking.com declines such an amount without saying so.  **Inventory is a separate write.** `roomsToSell` on a rate update returns `422 inventory_not_in_rate_update`; use `PUT /v1/channels/booking/availability` with `type: \"availability\"`.  **Restrictions ride along, on their own wire.** Send `restrictions` with the price and Booking.com receives two writes; the response reports each separately in `price` and `restrictions`, each with its own state, read-back and — when refused — Booking.com's own reason. `minStay`, `maxStay`, `minStayArrival`, `maxStayArrival`, `closedToArrival` and `closedToDeparture` are written; `exactStayArrival`, `minAdvanceRes` and `maxAdvanceRes` are refused with `422 restriction_not_supported` (Booking.com's notification has no element for them — set those on the rate plan in the Extranet). Nothing you send is silently ignored.  **The response says what is known.** Booking.com acknowledges a write without per-date status, so the affected nights are read back — prices and restrictions out of the same read — and `applied` reports `verified`, `mismatch`, `partial`, `rejected` or `unverified`. `partial` means one half landed and the other did not, which is never reported as a total failure. Send `verify: false` to skip the read-back; `applied` is then `unverified`. Booking.com stores a 1-night minimum as no minimum, so `minStay: 1` reads back as `0` and still counts as applied.  `id` is a Repull listing id. When it is published under several Booking.com properties this returns `409 ambiguous_booking_mapping` and pushes nothing — name the property with `?hotel_id=` instead.  Returns `403 listing_inactive` when the listing is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
+    # @param id [Integer] Repull listing id — NOT a Booking.com hotel id.
     # @param booking_pricing_update_request [BookingPricingUpdateRequest] 
     # @param [Hash] opts the optional parameters
+    # @option opts [String] :hotel_id Booking.com hotel id, when this listing is published under more than one property. Omit it and a read uses the oldest mapping (reporting the rest in &#x60;otherHotelIds&#x60;), while a write is refused with &#x60;409 ambiguous_booking_mapping&#x60; rather than guess. &#x60;GET /v1/channels/booking/properties&#x60; lists the valid ids.
     # @return [BookingPricingUpdateResponse]
     def update_booking_listing_pricing(id, booking_pricing_update_request, opts = {})
       data, _status_code, _headers = update_booking_listing_pricing_with_http_info(id, booking_pricing_update_request, opts)
@@ -1331,10 +1338,11 @@ module Repull
     end
 
     # Update Booking.com pricing for a listing
-    # Pushes one or more rate updates to Booking.com via &#x60;updateRates&#x60;. Each update needs &#x60;roomId&#x60; + &#x60;rateId&#x60; + &#x60;dateRange&#x60; + &#x60;price&#x60; + &#x60;currency&#x60;. Field-level validation runs up front so callers don&#39;t have to parse Booking&#39;s XML error envelope to discover a missing &#x60;roomId&#x60;.  Returns &#x60;403 listing_inactive&#x60; when the listing is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
-    # @param id [Integer] 
+    # Writes nightly prices for a listing&#39;s Booking.com room + rate plan. Each update needs &#x60;roomId&#x60; + &#x60;rateId&#x60; + &#x60;dateRange&#x60; + &#x60;price&#x60; + &#x60;currency&#x60;; &#x60;dateRange&#x60; is inclusive at both ends, so &#x60;start&#x60; equal to &#x60;end&#x60; writes exactly one night.  **Occupancy.** Booking.com stores a rate amount against the party size the rate plan prices. Send &#x60;occupancy&#x60; and that is what is used; omit it and it is resolved from Booking.com&#39;s own data for that (room, rate plan) and echoed back in &#x60;occupancy[]&#x60; with its &#x60;source&#x60;. When it cannot be resolved the write is refused with &#x60;422&#x60; naming &#x60;updates[N].occupancy&#x60; — a price is never sent at a guessed party size, because Booking.com declines such an amount without saying so.  **Inventory is a separate write.** &#x60;roomsToSell&#x60; on a rate update returns &#x60;422 inventory_not_in_rate_update&#x60;; use &#x60;PUT /v1/channels/booking/availability&#x60; with &#x60;type: \&quot;availability\&quot;&#x60;.  **Restrictions ride along, on their own wire.** Send &#x60;restrictions&#x60; with the price and Booking.com receives two writes; the response reports each separately in &#x60;price&#x60; and &#x60;restrictions&#x60;, each with its own state, read-back and — when refused — Booking.com&#39;s own reason. &#x60;minStay&#x60;, &#x60;maxStay&#x60;, &#x60;minStayArrival&#x60;, &#x60;maxStayArrival&#x60;, &#x60;closedToArrival&#x60; and &#x60;closedToDeparture&#x60; are written; &#x60;exactStayArrival&#x60;, &#x60;minAdvanceRes&#x60; and &#x60;maxAdvanceRes&#x60; are refused with &#x60;422 restriction_not_supported&#x60; (Booking.com&#39;s notification has no element for them — set those on the rate plan in the Extranet). Nothing you send is silently ignored.  **The response says what is known.** Booking.com acknowledges a write without per-date status, so the affected nights are read back — prices and restrictions out of the same read — and &#x60;applied&#x60; reports &#x60;verified&#x60;, &#x60;mismatch&#x60;, &#x60;partial&#x60;, &#x60;rejected&#x60; or &#x60;unverified&#x60;. &#x60;partial&#x60; means one half landed and the other did not, which is never reported as a total failure. Send &#x60;verify: false&#x60; to skip the read-back; &#x60;applied&#x60; is then &#x60;unverified&#x60;. Booking.com stores a 1-night minimum as no minimum, so &#x60;minStay: 1&#x60; reads back as &#x60;0&#x60; and still counts as applied.  &#x60;id&#x60; is a Repull listing id. When it is published under several Booking.com properties this returns &#x60;409 ambiguous_booking_mapping&#x60; and pushes nothing — name the property with &#x60;?hotel_id&#x3D;&#x60; instead.  Returns &#x60;403 listing_inactive&#x60; when the listing is inactive. An inactive listing keeps syncing, but cannot be read or changed through the API until it is activated.
+    # @param id [Integer] Repull listing id — NOT a Booking.com hotel id.
     # @param booking_pricing_update_request [BookingPricingUpdateRequest] 
     # @param [Hash] opts the optional parameters
+    # @option opts [String] :hotel_id Booking.com hotel id, when this listing is published under more than one property. Omit it and a read uses the oldest mapping (reporting the rest in &#x60;otherHotelIds&#x60;), while a write is refused with &#x60;409 ambiguous_booking_mapping&#x60; rather than guess. &#x60;GET /v1/channels/booking/properties&#x60; lists the valid ids.
     # @return [Array<(BookingPricingUpdateResponse, Integer, Hash)>] BookingPricingUpdateResponse data, response status code and response headers
     def update_booking_listing_pricing_with_http_info(id, booking_pricing_update_request, opts = {})
       if @api_client.config.debugging
@@ -1353,6 +1361,7 @@ module Repull
 
       # query parameters
       query_params = opts[:query_params] || {}
+      query_params[:'hotel_id'] = opts[:'hotel_id'] if !opts[:'hotel_id'].nil?
 
       # header parameters
       header_params = opts[:header_params] || {}