repull 0.2.14 → 0.2.16

data/lib/repull/api/availability_api.rb

@@ -88,7 +88,7 @@ module Repull
     end
 
     # Get property availability
-    # Channel-agnostic day-by-day availability calendar for a property over a date window. Returns a thin per-date shape — `{ date, available, price, minNights }` — projected from the property calendar.  The `from` and `to` query params are **required** (ISO `YYYY-MM-DD`, inclusive) — omitting or malforming either returns 422. The window is capped at 366 days; longer ranges are truncated to the first 366 days.  **`days` contains only the dates we actually hold calendar data for.** Requested dates with no calendar row are listed in `coverage.missingDates` — their availability is unknown. Never treat a missing date as bookable: this endpoint deliberately does not synthesise availability, because a fabricated open date can be double-booked. A property with no calendar still returns a real 200 (`days: []`, every date in `coverage.missingDates`), never a 404 — 404 means the property id does not exist or belongs to a different workspace.  This endpoint is read-only, and the projected per-date shape carries **availability, price, and min-nights only** — it does NOT expose max-stay, closed-to-arrival (CTA), closed-to-departure (CTD), or the dedicated stop-sell flag. To read or write that full restriction set on Booking.com use the channel routes: `GET`/`PUT /v1/channels/booking/availability` (with the room + rate ids from `GET /v1/channels/booking/properties/{id}/rooms`). Availability **writes** always stay per-channel: `PUT /v1/channels/airbnb/listings/{id}/availability` (Airbnb) or `PUT /v1/channels/booking/availability` (Booking.com).  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.
+    # Channel-agnostic day-by-day availability calendar for a property over a date window. Returns a thin per-date shape — `{ date, available, price, minNights }` — projected from the property calendar.  The `from` and `to` query params are **required** (ISO `YYYY-MM-DD`, inclusive) — omitting or malforming either returns 422. The window is capped at 366 days; longer ranges are truncated to the first 366 days.  **`days` contains only the dates we actually hold calendar data for.** Requested dates with no calendar row are listed in `coverage.missingDates` — their availability is unknown. Never treat a missing date as bookable: this endpoint deliberately does not synthesise availability, because a fabricated open date can be double-booked. A property with no calendar still returns a real 200 (`days: []`, every date in `coverage.missingDates`), never a 404 — 404 means the property id does not exist or belongs to a different workspace.  This endpoint is read-only, and the projected per-date shape carries **availability, price, and min-nights only** — it does NOT expose max-stay, closed-to-arrival (CTA), closed-to-departure (CTD), or the dedicated stop-sell flag. To read or write that full restriction set on Booking.com use the channel routes: `GET`/`PUT /v1/channels/booking/availability` (with the room + rate ids from `GET /v1/channels/booking/properties/{id}/rooms`). To **write** calendar values use `PUT /v1/availability/{propertyId}` (or `PATCH /v1/availability/batch`), which updates the property calendar and pushes to its connected channels; channel-only settings stay on the channel routes.  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 property_id [Integer] Repull property id (equal to `listings.id`; the same integer used as `propertyId` on availability and `listingId` on reservations).
     # @param from [Date] Start of the window (inclusive), ISO `YYYY-MM-DD`. Required — missing/malformed returns 422. `startDate` is accepted as an alias.
     # @param to [Date] End of the window (inclusive), ISO `YYYY-MM-DD`. Required — missing/malformed returns 422. `endDate` is accepted as an alias.
@@ -100,7 +100,7 @@ module Repull
     end
 
     # Get property availability
-    # Channel-agnostic day-by-day availability calendar for a property over a date window. Returns a thin per-date shape — `{ date, available, price, minNights }` — projected from the property calendar.  The `from` and `to` query params are **required** (ISO `YYYY-MM-DD`, inclusive) — omitting or malforming either returns 422. The window is capped at 366 days; longer ranges are truncated to the first 366 days.  **`days` contains only the dates we actually hold calendar data for.** Requested dates with no calendar row are listed in `coverage.missingDates` — their availability is unknown. Never treat a missing date as bookable: this endpoint deliberately does not synthesise availability, because a fabricated open date can be double-booked. A property with no calendar still returns a real 200 (`days: []`, every date in `coverage.missingDates`), never a 404 — 404 means the property id does not exist or belongs to a different workspace.  This endpoint is read-only, and the projected per-date shape carries **availability, price, and min-nights only** — it does NOT expose max-stay, closed-to-arrival (CTA), closed-to-departure (CTD), or the dedicated stop-sell flag. To read or write that full restriction set on Booking.com use the channel routes: `GET`/`PUT /v1/channels/booking/availability` (with the room + rate ids from `GET /v1/channels/booking/properties/{id}/rooms`). Availability **writes** always stay per-channel: `PUT /v1/channels/airbnb/listings/{id}/availability` (Airbnb) or `PUT /v1/channels/booking/availability` (Booking.com).  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.
+    # Channel-agnostic day-by-day availability calendar for a property over a date window. Returns a thin per-date shape — `{ date, available, price, minNights }` — projected from the property calendar.  The `from` and `to` query params are **required** (ISO `YYYY-MM-DD`, inclusive) — omitting or malforming either returns 422. The window is capped at 366 days; longer ranges are truncated to the first 366 days.  **`days` contains only the dates we actually hold calendar data for.** Requested dates with no calendar row are listed in `coverage.missingDates` — their availability is unknown. Never treat a missing date as bookable: this endpoint deliberately does not synthesise availability, because a fabricated open date can be double-booked. A property with no calendar still returns a real 200 (`days: []`, every date in `coverage.missingDates`), never a 404 — 404 means the property id does not exist or belongs to a different workspace.  This endpoint is read-only, and the projected per-date shape carries **availability, price, and min-nights only** — it does NOT expose max-stay, closed-to-arrival (CTA), closed-to-departure (CTD), or the dedicated stop-sell flag. To read or write that full restriction set on Booking.com use the channel routes: `GET`/`PUT /v1/channels/booking/availability` (with the room + rate ids from `GET /v1/channels/booking/properties/{id}/rooms`). To **write** calendar values use `PUT /v1/availability/{propertyId}` (or `PATCH /v1/availability/batch`), which updates the property calendar and pushes to its connected channels; channel-only settings stay on the channel routes.  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 property_id [Integer] Repull property id (equal to `listings.id`; the same integer used as `propertyId` on availability and `listingId` on reservations).
     # @param from [Date] Start of the window (inclusive), ISO `YYYY-MM-DD`. Required — missing/malformed returns 422. `startDate` is accepted as an alias.
     # @param to [Date] End of the window (inclusive), ISO `YYYY-MM-DD`. Required — missing/malformed returns 422. `endDate` is accepted as an alias.

data/lib/repull/api/billing_api.rb

@@ -187,7 +187,7 @@ module Repull
     end
 
     # Get usage summary
-    # Aggregated usage over the requested `range` — tier + plan limits, quota used/remaining, next reset, a per-operation breakdown (request/error counts, error rate, avg latency), a daily timeline, status-class distribution, and range totals.
+    # Aggregated usage over the requested `range` — tier + plan limits, quota used/remaining, next reset, a per-operation breakdown (request/error counts, error rate, avg latency), a daily timeline, status-class distribution, and range totals. Two request quotas are reported and they reset at different times: `dailyRequests` is the daily circuit breaker that stops runaway client loops (resets at `dailyResetsAt`, the next UTC midnight) and `monthlyRequests` is the billing quota (resets at `resetsAt`). `null` limits mean unlimited on that dimension.
     # @param [Hash] opts the optional parameters
     # @option opts [String] :range Aggregation window ending now. (default to '30d')
     # @return [GetUsageSummary200Response]
@@ -197,7 +197,7 @@ module Repull
     end
 
     # Get usage summary
-    # Aggregated usage over the requested `range` — tier + plan limits, quota used/remaining, next reset, a per-operation breakdown (request/error counts, error rate, avg latency), a daily timeline, status-class distribution, and range totals.
+    # Aggregated usage over the requested `range` — tier + plan limits, quota used/remaining, next reset, a per-operation breakdown (request/error counts, error rate, avg latency), a daily timeline, status-class distribution, and range totals. Two request quotas are reported and they reset at different times: `dailyRequests` is the daily circuit breaker that stops runaway client loops (resets at `dailyResetsAt`, the next UTC midnight) and `monthlyRequests` is the billing quota (resets at `resetsAt`). `null` limits mean unlimited on that dimension.
     # @param [Hash] opts the optional parameters
     # @option opts [String] :range Aggregation window ending now. (default to '30d')
     # @return [Array<(GetUsageSummary200Response, Integer, Hash)>] GetUsageSummary200Response data, response status code and response headers
@@ -251,7 +251,7 @@ module Repull
     end
 
     # Get tier and quota
-    # Lightweight current-tier snapshot for status badges and quota meters — plan limits (monthly requests, daily AI requests, dynamic-pricing listings), the amount used, the amount remaining, and the next reset. `null` limits mean unlimited on that dimension.
+    # Lightweight current-tier snapshot for status badges and quota meters — plan limits (daily requests, monthly requests, daily AI requests, dynamic-pricing listings), the amount used, the amount remaining, and the next reset. Two request quotas are reported and they reset at different times: `dailyRequests` is the daily circuit breaker that stops runaway client loops (resets at `dailyResetsAt`, the next UTC midnight) and `monthlyRequests` is the billing quota (resets at `resetsAt`). Exceeding the daily cap returns 429 `daily_limit_exceeded`; exceeding the monthly one returns 429 `rate_limit_exceeded`. `null` limits mean unlimited on that dimension.
     # @param [Hash] opts the optional parameters
     # @return [GetUsageTier200Response]
     def get_usage_tier(opts = {})
@@ -260,7 +260,7 @@ module Repull
     end
 
     # Get tier and quota
-    # Lightweight current-tier snapshot for status badges and quota meters — plan limits (monthly requests, daily AI requests, dynamic-pricing listings), the amount used, the amount remaining, and the next reset. &#x60;null&#x60; limits mean unlimited on that dimension.
+    # Lightweight current-tier snapshot for status badges and quota meters — plan limits (daily requests, monthly requests, daily AI requests, dynamic-pricing listings), the amount used, the amount remaining, and the next reset. Two request quotas are reported and they reset at different times: &#x60;dailyRequests&#x60; is the daily circuit breaker that stops runaway client loops (resets at &#x60;dailyResetsAt&#x60;, the next UTC midnight) and &#x60;monthlyRequests&#x60; is the billing quota (resets at &#x60;resetsAt&#x60;). Exceeding the daily cap returns 429 &#x60;daily_limit_exceeded&#x60;; exceeding the monthly one returns 429 &#x60;rate_limit_exceeded&#x60;. &#x60;null&#x60; limits mean unlimited on that dimension.
     # @param [Hash] opts the optional parameters
     # @return [Array<(GetUsageTier200Response, Integer, Hash)>] GetUsageTier200Response data, response status code and response headers
     def get_usage_tier_with_http_info(opts = {})

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] || {}

data/lib/repull/api/connect_api.rb

@@ -226,7 +226,7 @@ module Repull
     end
 
     # Disconnect provider
-    # Disconnect ONE connected account of a provider from this workspace. Supported for `airbnb` and `booking`.  **Which account.** Pass `accountId` — for Airbnb the host id (`accounts[].externalAccountId` from `GET /v1/connect/airbnb`), for Booking.com the hotel id. It is optional only when the workspace has exactly one account for the provider. With several and no `accountId`, the call returns `422` with the account ids in `valid_values` instead of guessing. An `accountId` that is not connected to this workspace returns `404`. Disconnecting one account leaves the others connected.  **What happens.** The account's stored authorization is removed and it stops syncing. Its listings are **deactivated**, not deleted: they stop counting toward your plan's listing limit, their data is kept, and they are returned in `listingsDeactivated`. A listing that is still connected through another account or channel stays active. Reconnect the account, then activate the listings with `POST /v1/listings/status`.  The change is all or nothing. For Airbnb, the host can also revoke access on Airbnb's side (Account → Privacy & sharing → Connected apps); that alone does not update this workspace, so call this endpoint as well.  Other providers return `501 not_implemented` with instructions for disconnecting on the provider's side.
+    # Disconnect ONE connected account of a provider from this workspace. Supported for `airbnb` and `booking`.  **Which account.** Pass `accountId` — for Airbnb the host id (`accounts[].externalAccountId` from `GET /v1/connect/airbnb`), for Booking.com the hotel id. It is optional only when the workspace has exactly one account for the provider. With several and no `accountId`, the call returns `422` with the account ids in `valid_values` instead of guessing. An `accountId` that is not connected to this workspace returns `404`. Disconnecting one account leaves the others connected.  **What happens.** The account's stored authorization is removed and it stops syncing. Its listings are **deactivated**, not deleted: they stop counting toward your plan's listing limit, their data is kept, and they are returned in `listingsDeactivated`. A listing that is still connected through another account or channel stays active. Reconnect the account, then activate the listings with `POST /v1/listings/status`.  The change is all or nothing. For Airbnb, the host can also revoke access on Airbnb's side (Account → Privacy & sharing → Connected apps); that alone does not update this workspace, so call this endpoint as well.  Other providers return `501 not_implemented` with instructions for disconnecting on the provider's side. That answer depends only on the provider, not on your workspace: an unsupported provider returns `501` whether or not you have a connection to it. `404 not_found` on a supported provider means this workspace has no connection to it (or, with `accountId`, that the account is not connected here).
     # @param provider [String] PMS provider slug (e.g., hostaway, guesty, ownerrez)
     # @param [Hash] opts the optional parameters
     # @option opts [String] :account_id The account to disconnect: the Airbnb host id (`accounts[].externalAccountId` on `GET /v1/connect/airbnb`) or the Booking.com hotel id. Required when the workspace has more than one connected account for the provider. Not the same as the `X-Account-Id` header.
@@ -237,7 +237,7 @@ module Repull
     end
 
     # Disconnect provider
-    # Disconnect ONE connected account of a provider from this workspace. Supported for `airbnb` and `booking`.  **Which account.** Pass `accountId` — for Airbnb the host id (`accounts[].externalAccountId` from `GET /v1/connect/airbnb`), for Booking.com the hotel id. It is optional only when the workspace has exactly one account for the provider. With several and no `accountId`, the call returns `422` with the account ids in `valid_values` instead of guessing. An `accountId` that is not connected to this workspace returns `404`. Disconnecting one account leaves the others connected.  **What happens.** The account's stored authorization is removed and it stops syncing. Its listings are **deactivated**, not deleted: they stop counting toward your plan's listing limit, their data is kept, and they are returned in `listingsDeactivated`. A listing that is still connected through another account or channel stays active. Reconnect the account, then activate the listings with `POST /v1/listings/status`.  The change is all or nothing. For Airbnb, the host can also revoke access on Airbnb's side (Account → Privacy & sharing → Connected apps); that alone does not update this workspace, so call this endpoint as well.  Other providers return `501 not_implemented` with instructions for disconnecting on the provider's side.
+    # Disconnect ONE connected account of a provider from this workspace. Supported for `airbnb` and `booking`.  **Which account.** Pass `accountId` — for Airbnb the host id (`accounts[].externalAccountId` from `GET /v1/connect/airbnb`), for Booking.com the hotel id. It is optional only when the workspace has exactly one account for the provider. With several and no `accountId`, the call returns `422` with the account ids in `valid_values` instead of guessing. An `accountId` that is not connected to this workspace returns `404`. Disconnecting one account leaves the others connected.  **What happens.** The account's stored authorization is removed and it stops syncing. Its listings are **deactivated**, not deleted: they stop counting toward your plan's listing limit, their data is kept, and they are returned in `listingsDeactivated`. A listing that is still connected through another account or channel stays active. Reconnect the account, then activate the listings with `POST /v1/listings/status`.  The change is all or nothing. For Airbnb, the host can also revoke access on Airbnb's side (Account → Privacy & sharing → Connected apps); that alone does not update this workspace, so call this endpoint as well.  Other providers return `501 not_implemented` with instructions for disconnecting on the provider's side. That answer depends only on the provider, not on your workspace: an unsupported provider returns `501` whether or not you have a connection to it. `404 not_found` on a supported provider means this workspace has no connection to it (or, with `accountId`, that the account is not connected here).
     # @param provider [String] PMS provider slug (e.g., hostaway, guesty, ownerrez)
     # @param [Hash] opts the optional parameters
     # @option opts [String] :account_id The account to disconnect: the Airbnb host id (`accounts[].externalAccountId` on `GET /v1/connect/airbnb`) or the Booking.com hotel id. Required when the workspace has more than one connected account for the provider. Not the same as the `X-Account-Id` header.
@@ -601,7 +601,7 @@ module Repull
     end
 
     # Bind a picker session to a provider
-    # Called by the hosted picker page once the user clicks a channel card. Validates the provider exists and is permitted by the session's `allowed_providers` whitelist (if any), then returns the next-step URL the picker should navigate to.  No API key required — the session ID is the capability token. The session must still be pending and unexpired.
+    # Called by the hosted picker page once the user clicks a channel card. Validates the provider exists and is permitted by the session's `allowedProviders` whitelist (if any), then returns the next-step URL the picker should navigate to.  No API key required — the session ID is the capability token. The session must still be pending and unexpired.
     # @param session_id [String] The picker session ID returned by `createConnectSession`.
     # @param select_connect_provider_request [SelectConnectProviderRequest] 
     # @param [Hash] opts the optional parameters
@@ -612,7 +612,7 @@ module Repull
     end
 
     # Bind a picker session to a provider
-    # Called by the hosted picker page once the user clicks a channel card. Validates the provider exists and is permitted by the session's `allowed_providers` whitelist (if any), then returns the next-step URL the picker should navigate to.  No API key required — the session ID is the capability token. The session must still be pending and unexpired.
+    # Called by the hosted picker page once the user clicks a channel card. Validates the provider exists and is permitted by the session's `allowedProviders` whitelist (if any), then returns the next-step URL the picker should navigate to.  No API key required — the session ID is the capability token. The session must still be pending and unexpired.
     # @param session_id [String] The picker session ID returned by `createConnectSession`.
     # @param select_connect_provider_request [SelectConnectProviderRequest] 
     # @param [Hash] opts the optional parameters