repull 0.2.15 → 0.2.17

data/lib/repull/api/booking_com_api.rb

@@ -87,8 +87,92 @@ module Repull
       return data, status_code, headers
     end
 
+    # Take a property off sale / put it back (unlist/relist)
+    # Stop this listing's Booking.com property being sold, or start it again. `id` is a **Repull listing id**, not a Booking.com hotel id, as on the GET.  **Booking.com has no unlist, so this is an availability write.** Airbnb has a real deactivate; Booking.com does not. `unlist` closes the mapped room across the whole forward window, so the property stops selling. `relist` is not its mirror image: it re-syncs the true calendar, so dates that are genuinely blocked (a reservation, an owner stay) stay blocked and only the closure `unlist` wrote lifts. Re-opening everything would sell dates that are not for sale.  **Which property gets closed.** A listing can be mapped to more than one Booking.com property — the same unit re-listed under a new property keeps its old mapping, and workspaces routinely sit on five or six. With exactly one, send nothing. With several, name one with `hotelId` (or `?hotel_id=`); omit it and the request is refused with **`409 ambiguous_booking_mapping`** listing the candidates, and nothing is written. That refusal matters more here than on a publish: writing content into the wrong property is recoverable, closing the wrong property's availability takes real inventory off sale while the property you meant keeps selling. Naming a property this listing is not mapped to is a `404` that names the ones it is.  **This does not change the listing in Repull.** `active` — what Repull bills and serves — is untouched by both actions and is deliberately not echoed in the response, so the two ideas can never be read as one field. To take a listing off the market on every channel at once, use `POST /v1/listings/{id}/offline`.  Any other action returns a structured `422` naming the ones that are supported. To push content use `POST /v1/listings/{id}/publish/booking`; to map rooms use `POST /v1/connect/booking/map-rooms`.  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_property_action_request [BookingPropertyActionRequest] 
+    # @param [Hash] opts the optional parameters
+    # @option opts [String] :hotel_id Booking.com property to act on, for a listing mapped to more than one. The query-string spelling of the body's `hotelId`; the body wins when both are sent.
+    # @option opts [String] :idempotency_key Makes a retry of this request safe. Send a unique string (a UUID generated at the point you build the request) and the response is stored for 24 hours: a repeat with the SAME key replays that stored response — tagged `Idempotency-Status: cached` — without running the operation again, so no duplicate reservation, guest or guest message is created.  - Same key while the first request is still in flight → `409 idempotency_key_in_use`. - Same key with a DIFFERENT payload → `422 idempotency_key_reused`. Generate a new key per distinct request; reuse one only when retrying that exact request. - Retryable outcomes are deliberately not stored, so a retry with the same key runs for real: any status >= 500, `408`, `425` and `429`, and the refusals that happen before anything is done and tell you to fix something outside the request first — `connection_reauth_required`, `listing_inactive`, and the rate/daily limits. Every other answer, including a final refusal such as `422 airbnb_rejected`, is stored and replayed.
+    # @return [BookingPropertyActionResponse]
+    def booking_property_action(id, booking_property_action_request, opts = {})
+      data, _status_code, _headers = booking_property_action_with_http_info(id, booking_property_action_request, opts)
+      data
+    end
+
+    # Take a property off sale / put it back (unlist/relist)
+    # Stop this listing's Booking.com property being sold, or start it again. `id` is a **Repull listing id**, not a Booking.com hotel id, as on the GET.  **Booking.com has no unlist, so this is an availability write.** Airbnb has a real deactivate; Booking.com does not. `unlist` closes the mapped room across the whole forward window, so the property stops selling. `relist` is not its mirror image: it re-syncs the true calendar, so dates that are genuinely blocked (a reservation, an owner stay) stay blocked and only the closure `unlist` wrote lifts. Re-opening everything would sell dates that are not for sale.  **Which property gets closed.** A listing can be mapped to more than one Booking.com property — the same unit re-listed under a new property keeps its old mapping, and workspaces routinely sit on five or six. With exactly one, send nothing. With several, name one with `hotelId` (or `?hotel_id=`); omit it and the request is refused with **`409 ambiguous_booking_mapping`** listing the candidates, and nothing is written. That refusal matters more here than on a publish: writing content into the wrong property is recoverable, closing the wrong property's availability takes real inventory off sale while the property you meant keeps selling. Naming a property this listing is not mapped to is a `404` that names the ones it is.  **This does not change the listing in Repull.** `active` — what Repull bills and serves — is untouched by both actions and is deliberately not echoed in the response, so the two ideas can never be read as one field. To take a listing off the market on every channel at once, use `POST /v1/listings/{id}/offline`.  Any other action returns a structured `422` naming the ones that are supported. To push content use `POST /v1/listings/{id}/publish/booking`; to map rooms use `POST /v1/connect/booking/map-rooms`.  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_property_action_request [BookingPropertyActionRequest] 
+    # @param [Hash] opts the optional parameters
+    # @option opts [String] :hotel_id Booking.com property to act on, for a listing mapped to more than one. The query-string spelling of the body's `hotelId`; the body wins when both are sent.
+    # @option opts [String] :idempotency_key Makes a retry of this request safe. Send a unique string (a UUID generated at the point you build the request) and the response is stored for 24 hours: a repeat with the SAME key replays that stored response — tagged `Idempotency-Status: cached` — without running the operation again, so no duplicate reservation, guest or guest message is created.  - Same key while the first request is still in flight → `409 idempotency_key_in_use`. - Same key with a DIFFERENT payload → `422 idempotency_key_reused`. Generate a new key per distinct request; reuse one only when retrying that exact request. - Retryable outcomes are deliberately not stored, so a retry with the same key runs for real: any status >= 500, `408`, `425` and `429`, and the refusals that happen before anything is done and tell you to fix something outside the request first — `connection_reauth_required`, `listing_inactive`, and the rate/daily limits. Every other answer, including a final refusal such as `422 airbnb_rejected`, is stored and replayed.
+    # @return [Array<(BookingPropertyActionResponse, Integer, Hash)>] BookingPropertyActionResponse data, response status code and response headers
+    def booking_property_action_with_http_info(id, booking_property_action_request, opts = {})
+      if @api_client.config.debugging
+        @api_client.config.logger.debug 'Calling API: BookingComApi.booking_property_action ...'
+      end
+      # verify the required parameter 'id' is set
+      if @api_client.config.client_side_validation && id.nil?
+        fail ArgumentError, "Missing the required parameter 'id' when calling BookingComApi.booking_property_action"
+      end
+      # verify the required parameter 'booking_property_action_request' is set
+      if @api_client.config.client_side_validation && booking_property_action_request.nil?
+        fail ArgumentError, "Missing the required parameter 'booking_property_action_request' when calling BookingComApi.booking_property_action"
+      end
+      if @api_client.config.client_side_validation && !opts[:'idempotency_key'].nil? && opts[:'idempotency_key'].to_s.length > 255
+        fail ArgumentError, 'invalid value for "opts[:"idempotency_key"]" when calling BookingComApi.booking_property_action, the character length must be smaller than or equal to 255.'
+      end
+
+      # resource path
+      local_var_path = '/v1/channels/booking/properties/{id}'.sub('{id}', CGI.escape(id.to_s))
+
+      # 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] || {}
+      # HTTP header 'Accept' (if needed)
+      header_params['Accept'] = @api_client.select_header_accept(['application/json']) unless header_params['Accept']
+      # HTTP header 'Content-Type'
+      content_type = @api_client.select_header_content_type(['application/json'])
+      if !content_type.nil?
+          header_params['Content-Type'] = content_type
+      end
+      header_params[:'Idempotency-Key'] = opts[:'idempotency_key'] if !opts[:'idempotency_key'].nil?
+
+      # form parameters
+      form_params = opts[:form_params] || {}
+
+      # http body (model)
+      post_body = opts[:debug_body] || @api_client.object_to_http_body(booking_property_action_request)
+
+      # return_type
+      return_type = opts[:debug_return_type] || 'BookingPropertyActionResponse'
+
+      # auth_names
+      auth_names = opts[:debug_auth_names] || ['bearerAuth']
+
+      new_options = opts.merge(
+        :operation => :"BookingComApi.booking_property_action",
+        :header_params => header_params,
+        :query_params => query_params,
+        :form_params => form_params,
+        :body => post_body,
+        :auth_names => auth_names,
+        :return_type => return_type
+      )
+
+      data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
+      if @api_client.config.debugging
+        @api_client.config.logger.debug "API called: BookingComApi#booking_property_action\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
+      end
+      return data, status_code, headers
+    end
+
     # Booking.com property setup actions
-    # Action-router for onboarding a property onto Booking.com. Select the step with `action`:  - `create-legal-entity` — register the legal entity (returns 201). - `check-legal-status` — poll legal-entity status by `leid`. - `check-readiness` — check whether a property is ready to open (`property_id`). - `open-property` — open the property for sale (`property_id`). - `set-contacts` — set property contacts (`property_id`, `contacts`). - `set-policies` — set property policies (`property_id`, plus policy fields).  Missing required fields per action return a validation error; upstream failures surface as `booking_error`.  Every action that takes a `property_id` requires a property connected to this workspace; any other id returns `404 not_found`.  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.
+    # Action-router for putting a property onto Booking.com — including building one from nothing. Select the step with `action`.  ## Opening a property  - `create-property` — create a NEW Booking.com property for a Repull listing (`listing_id`). Creates the property, its first room, a rate plan and the room-rate product that makes the room sellable, seeds availability and rates, syncs the calendar, then sends the notification that starts Booking's validation. Returns 201. - `add-room` — add another room type (and its sellable product) to a property (`listing_id`, `property_id`). Returns 201. - `add-unit` — raise the number of identical units on an existing room (`listing_id`, `property_id`, `room_id`). - `advance` — re-send the summary notification for a property (`property_id`) to move it out of the \"XML: Being built\" stage.  ## Account and policy steps  - `create-legal-entity` — register a legal entity directly (returns 201). Not normally needed: see the legal-entity rules below. - `check-legal-status` — always `404`. A legal entity's details are readable for any id on the connectivity-provider credentials every workspace shares, and nothing records which workspace registered which entity, so no entity can be shown to be yours. `create-property` resolves it for you. - `check-readiness` — check whether a property is ready to open (`property_id`). - `open-property` — open the property for sale (`property_id`). - `set-contacts` — set property contacts (`property_id`, `contacts`). - `set-policies` — set property policies (`property_id`, plus policy fields).  ## Three things about Booking.com that cost real money  **A newly created property is NOT sellable.** Booking holds it at \"XML: Being built\" until it validates the summary notification. `create-property` sends that notification, but it can fail on its own after everything else succeeded — the response always reports `status: \"being_built\"` and `sellable: false`, never a guess. Use `advance` to re-send it, and check the Extranet for the stage.  **A room with no ACTIVE rate plan is invisible.** Booking only renders rooms that have at least one active product linkage (room × rate plan). A room can be created successfully, return a `roomId`, and never appear on the property page. If `rateId` comes back `null` from `create-property` or `add-room`, that is exactly what happened: activate a rate plan on the property in the Extranet, then add the room again.  **The room name is shown to travellers.** It is taken from the listing's name and appears on the Booking.com property page. Internal nicknames belong on the property's partner reference, not on the room.  ## The legal entity is resolved, not asked for  A property is created against the legal entity Booking.com contracts with, invoices and pays. You do not normally send one:  1. If this workspace already creates properties under a legal entity, that one is reused. A second is never registered. 2. If it has none and the request carries `legal_entity` (`company_name`, `legal_contact_name`, `legal_contact_email`), one is registered and used. Booking.com emails the legal contact a contract; creation only succeeds once it is signed. 3. If it has none and no `legal_entity`, the request is refused with `422 legal_entity_required` naming the fields — a contracted company is never invented.  `legal_entity_id` overrides all of that. An id that already carries another workspace's properties is refused with `403 legal_entity_not_yours` before anything is created.  ## What you do not control  Properties are created against Booking's **production** target only. A test-target property cannot be sold through and there is no route back from one, so `target` is not a parameter — sending it changes nothing.  These are fixed on every created property and are not parameters: property category (Apartment), initial room count (1), and the property contact record (a placeholder name, email and phone). Set the real contacts afterwards with `set-contacts`. Latitude and longitude come from the listing and are adjusted slightly to clear Booking.com's duplicate detection — send the property's true position on the listing and do not pre-adjust it yourself.  The listing's name, check-in/check-out times, currency, capacity and price come from the listing. Its postal code is taken from the listing's own `postalCode`; when the listing has none, it falls back to a connected Airbnb listing. A listing with neither is created without a postal code, so set `postalCode` on the listing first.  ## Guards  Every action that takes a `property_id` requires a property connected to this workspace; any other id returns `404 not_found`. Every action that takes a `listing_id` requires a listing in this workspace; any other id returns `404 not_found`.  `create-property` refuses a listing with no coordinates (`422 missing_coordinates`) before anything is created — creating a Booking.com property cannot be undone.  `create-property` is subject to the same published-listing gate as the dashboard: no plan, or the plan's listing limit reached, returns `403 billing_error` with `used` and `limit`, and nothing is created.  Returns `403 listing_inactive` when the listing — or 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.  If a property is created and a later step fails, the response is `422 booking_create_partial` carrying `property_id`. The property EXISTS. Do not retry `create-property`, which would open a second one — continue with `add-room` and `advance`.
     # @param booking_setup_request [BookingSetupRequest] 
     # @param [Hash] opts the optional parameters
     # @return [nil]
@@ -98,7 +182,7 @@ module Repull
     end
 
     # Booking.com property setup actions
-    # Action-router for onboarding a property onto Booking.com. Select the step with &#x60;action&#x60;:  - &#x60;create-legal-entity&#x60; — register the legal entity (returns 201). - &#x60;check-legal-status&#x60; — poll legal-entity status by &#x60;leid&#x60;. - &#x60;check-readiness&#x60; — check whether a property is ready to open (&#x60;property_id&#x60;). - &#x60;open-property&#x60; — open the property for sale (&#x60;property_id&#x60;). - &#x60;set-contacts&#x60; — set property contacts (&#x60;property_id&#x60;, &#x60;contacts&#x60;). - &#x60;set-policies&#x60; — set property policies (&#x60;property_id&#x60;, plus policy fields).  Missing required fields per action return a validation error; upstream failures surface as &#x60;booking_error&#x60;.  Every action that takes a &#x60;property_id&#x60; requires a property connected to this workspace; any other id returns &#x60;404 not_found&#x60;.  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.
+    # Action-router for putting a property onto Booking.com — including building one from nothing. Select the step with &#x60;action&#x60;.  ## Opening a property  - &#x60;create-property&#x60; — create a NEW Booking.com property for a Repull listing (&#x60;listing_id&#x60;). Creates the property, its first room, a rate plan and the room-rate product that makes the room sellable, seeds availability and rates, syncs the calendar, then sends the notification that starts Booking&#39;s validation. Returns 201. - &#x60;add-room&#x60; — add another room type (and its sellable product) to a property (&#x60;listing_id&#x60;, &#x60;property_id&#x60;). Returns 201. - &#x60;add-unit&#x60; — raise the number of identical units on an existing room (&#x60;listing_id&#x60;, &#x60;property_id&#x60;, &#x60;room_id&#x60;). - &#x60;advance&#x60; — re-send the summary notification for a property (&#x60;property_id&#x60;) to move it out of the \&quot;XML: Being built\&quot; stage.  ## Account and policy steps  - &#x60;create-legal-entity&#x60; — register a legal entity directly (returns 201). Not normally needed: see the legal-entity rules below. - &#x60;check-legal-status&#x60; — always &#x60;404&#x60;. A legal entity&#39;s details are readable for any id on the connectivity-provider credentials every workspace shares, and nothing records which workspace registered which entity, so no entity can be shown to be yours. &#x60;create-property&#x60; resolves it for you. - &#x60;check-readiness&#x60; — check whether a property is ready to open (&#x60;property_id&#x60;). - &#x60;open-property&#x60; — open the property for sale (&#x60;property_id&#x60;). - &#x60;set-contacts&#x60; — set property contacts (&#x60;property_id&#x60;, &#x60;contacts&#x60;). - &#x60;set-policies&#x60; — set property policies (&#x60;property_id&#x60;, plus policy fields).  ## Three things about Booking.com that cost real money  **A newly created property is NOT sellable.** Booking holds it at \&quot;XML: Being built\&quot; until it validates the summary notification. &#x60;create-property&#x60; sends that notification, but it can fail on its own after everything else succeeded — the response always reports &#x60;status: \&quot;being_built\&quot;&#x60; and &#x60;sellable: false&#x60;, never a guess. Use &#x60;advance&#x60; to re-send it, and check the Extranet for the stage.  **A room with no ACTIVE rate plan is invisible.** Booking only renders rooms that have at least one active product linkage (room × rate plan). A room can be created successfully, return a &#x60;roomId&#x60;, and never appear on the property page. If &#x60;rateId&#x60; comes back &#x60;null&#x60; from &#x60;create-property&#x60; or &#x60;add-room&#x60;, that is exactly what happened: activate a rate plan on the property in the Extranet, then add the room again.  **The room name is shown to travellers.** It is taken from the listing&#39;s name and appears on the Booking.com property page. Internal nicknames belong on the property&#39;s partner reference, not on the room.  ## The legal entity is resolved, not asked for  A property is created against the legal entity Booking.com contracts with, invoices and pays. You do not normally send one:  1. If this workspace already creates properties under a legal entity, that one is reused. A second is never registered. 2. If it has none and the request carries &#x60;legal_entity&#x60; (&#x60;company_name&#x60;, &#x60;legal_contact_name&#x60;, &#x60;legal_contact_email&#x60;), one is registered and used. Booking.com emails the legal contact a contract; creation only succeeds once it is signed. 3. If it has none and no &#x60;legal_entity&#x60;, the request is refused with &#x60;422 legal_entity_required&#x60; naming the fields — a contracted company is never invented.  &#x60;legal_entity_id&#x60; overrides all of that. An id that already carries another workspace&#39;s properties is refused with &#x60;403 legal_entity_not_yours&#x60; before anything is created.  ## What you do not control  Properties are created against Booking&#39;s **production** target only. A test-target property cannot be sold through and there is no route back from one, so &#x60;target&#x60; is not a parameter — sending it changes nothing.  These are fixed on every created property and are not parameters: property category (Apartment), initial room count (1), and the property contact record (a placeholder name, email and phone). Set the real contacts afterwards with &#x60;set-contacts&#x60;. Latitude and longitude come from the listing and are adjusted slightly to clear Booking.com&#39;s duplicate detection — send the property&#39;s true position on the listing and do not pre-adjust it yourself.  The listing&#39;s name, check-in/check-out times, currency, capacity and price come from the listing. Its postal code is taken from the listing&#39;s own &#x60;postalCode&#x60;; when the listing has none, it falls back to a connected Airbnb listing. A listing with neither is created without a postal code, so set &#x60;postalCode&#x60; on the listing first.  ## Guards  Every action that takes a &#x60;property_id&#x60; requires a property connected to this workspace; any other id returns &#x60;404 not_found&#x60;. Every action that takes a &#x60;listing_id&#x60; requires a listing in this workspace; any other id returns &#x60;404 not_found&#x60;.  &#x60;create-property&#x60; refuses a listing with no coordinates (&#x60;422 missing_coordinates&#x60;) before anything is created — creating a Booking.com property cannot be undone.  &#x60;create-property&#x60; is subject to the same published-listing gate as the dashboard: no plan, or the plan&#39;s listing limit reached, returns &#x60;403 billing_error&#x60; with &#x60;used&#x60; and &#x60;limit&#x60;, and nothing is created.  Returns &#x60;403 listing_inactive&#x60; when the listing — or 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.  If a property is created and a later step fails, the response is &#x60;422 booking_create_partial&#x60; carrying &#x60;property_id&#x60;. The property EXISTS. Do not retry &#x60;create-property&#x60;, which would open a second one — continue with &#x60;add-room&#x60; and &#x60;advance&#x60;.
     # @param booking_setup_request [BookingSetupRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(nil, Integer, Hash)>] nil, response status code and response headers
@@ -485,13 +569,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 &#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 [BookingPricingResponse]
     def get_booking_listing_pricing(id, opts = {})
       data, _status_code, _headers = get_booking_listing_pricing_with_http_info(id, opts)
@@ -499,13 +584,14 @@ module Repull
     end
 
     # Get Booking.com pricing for a listing
-    # Resolves the Vanio listing ID to its Booking.com &#x60;hotel_id&#x60; (via the &#x60;listings_booking&#x60; mapping owned by the authenticated workspace), then proxies Booking&#39;s &#x60;getRoomRateAvailability&#x60; for the requested window. Pricing on Booking is per-room/per-rate-plan, so &#x60;room_id&#x60; and &#x60;room_level&#x60; flow through query params unchanged.  Mirrors the per-channel &#x60;/listings/{id}/pricing&#x60; shape used by Airbnb so SDK consumers can carry a Vanio listing ID across channels.  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.
+    # Resolves the Repull listing id to its Booking.com &#x60;hotel_id&#x60; (via the room mapping the Connect flow records for the authenticated workspace), then proxies Booking&#39;s &#x60;getRoomRateAvailability&#x60; for the requested window. Pricing on Booking is per-room/per-rate-plan, so &#x60;room_id&#x60; and &#x60;room_level&#x60; flow through query params unchanged.  Mirrors the per-channel &#x60;/listings/{id}/pricing&#x60; shape used by Airbnb so SDK consumers can carry a Repull listing id across channels. &#x60;id&#x60; is a Repull listing id, never a Booking.com hotel id — the hotel-id surface is &#x60;/v1/channels/booking/availability&#x60;.  A listing can be published under several Booking.com properties. GET uses the oldest and reports the rest in &#x60;otherHotelIds&#x60;; PUT refuses with &#x60;409 ambiguous_booking_mapping&#x60; rather than push rates into a property it guessed at. &#x60;?hotel_id&#x3D;&#x60; names the property explicitly for either.  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 [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 &#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<(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 +610,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 +647,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 +657,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 +767,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 +776,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 +824,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 +835,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 +853,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 +1149,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 +1159,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 +1217,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 +1262,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 +1410,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 +1422,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 +1445,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] || {}