repull 0.2.18 → 0.2.19

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: db31d9b9fe03869bb22646bfd0c6b8c31e28359e22f601380c94d036d1b060e4
-  data.tar.gz: 95baad96e6eb93f6c759d646cb9140492c47831f991165469e13ddad65ee9444
+  metadata.gz: 15403dd52cdecbf29d07692c41b91b6b3b52f305b42217c3efd4921bd2aaf739
+  data.tar.gz: 3d7f250db469714186c929035e61717ef62e4c53d8b5979f7a05141c135bc6ef
 SHA512:
-  metadata.gz: d7027f2ef9616d8f190542d959b0ca97abb74046618d2eaf801bd74c183c1cb8389304295bd560e0924b2d9709647328200bb255fb2cb34d949965e5fc8b0913
-  data.tar.gz: 902507f20e5e3121e1231ee19c42947e60f756c563d18d24346b618464dc2ae994e454914e8d1ffb41cf15084314e4e0072881ff5c6cfc29d4781e41a790a126
+  metadata.gz: 51b184c8b51787aa6696489f016a8aa01f96e212f4b64530b9717b3f32f5506652240d631d19ba6ad308c92eab7ca3d38d8a9329b94a554b1041b3f7fefb8e58
+  data.tar.gz: dc48f72c12261d1fbf453fd674a39d8f985f46bf9ab0d2b3757056987b4012195cd4d68a8db1d3c3aa56c421dd71ee0f0a2509e573192f6fd60d6e1bf5a7a55e

data/lib/repull/api/booking_com_api.rb

@@ -172,7 +172,7 @@ module Repull
     end
 
     # Booking.com property setup actions
-    # 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`.
+    # 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 with the listing's beds, a rate plan and the room-rate product that makes the room sellable (under the listing's cancellation policy), sets the contact and invoice details and the facilities, seeds availability and rates, syncs the calendar, then runs Booking.com's readiness check and reports what still blocks opening in `warnings`. Send `contact` (`name`, `email`, `phone` in international form); without it the workspace owner is used, and a workspace with no usable contact is refused before anything is created. 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` — run Booking.com's readiness check for a property (`property_id`) and, when it passes, open it. Returns `checked`, `opened`, `sellable` and `blockers` — Booking.com's own reasons it cannot open yet.  ## 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` — whether a property is ready to open (`property_id`): `ready` and `blockers`, without trying to open it. - `open-property` — open the property for sale (`property_id`). Refused with `422 booking_rejected` naming the blockers when it is not ready. - `set-contacts` — set property contacts (`property_id`, `contacts` in Booking.com's Contacts API shape; at most one carries the `general` profile). - `set-policies` — add a cancellation policy (`property_id`, `policyCode`, optional `prepaymentRequired`). House rules, pets, children and the damage deposit are `POST /v1/channels/booking/content` with `type: \"settings\"`.  ## Three things about Booking.com that cost real money  **A newly created property is NOT sellable.** Booking.com opens it only when its readiness check passes, and the check names what is missing — a main photo still processing, no availability, a licence the region requires. The response always reports `status: \"being_built\"` and `sellable: false`, never a guess, with the reasons in `warnings`. Resolve them, then `advance`.  **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.  **Room names are Booking.com's.** Travellers see one of Booking.com's standard names (\"Two-Bedroom Apartment\"), chosen from the listing's bedrooms. The listing's own name is kept as the operator-side reference, never shown to guests.  ## 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.  The property category comes from the listing's property type (Apartment when it has none; Holiday home, Villa or Chalet when it says so). The initial room count is 1. 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]
@@ -182,7 +182,7 @@ module Repull
     end
 
     # Booking.com property setup actions
-    # 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`.
+    # 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 with the listing's beds, a rate plan and the room-rate product that makes the room sellable (under the listing's cancellation policy), sets the contact and invoice details and the facilities, seeds availability and rates, syncs the calendar, then runs Booking.com's readiness check and reports what still blocks opening in `warnings`. Send `contact` (`name`, `email`, `phone` in international form); without it the workspace owner is used, and a workspace with no usable contact is refused before anything is created. 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` — run Booking.com's readiness check for a property (`property_id`) and, when it passes, open it. Returns `checked`, `opened`, `sellable` and `blockers` — Booking.com's own reasons it cannot open yet.  ## 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` — whether a property is ready to open (`property_id`): `ready` and `blockers`, without trying to open it. - `open-property` — open the property for sale (`property_id`). Refused with `422 booking_rejected` naming the blockers when it is not ready. - `set-contacts` — set property contacts (`property_id`, `contacts` in Booking.com's Contacts API shape; at most one carries the `general` profile). - `set-policies` — add a cancellation policy (`property_id`, `policyCode`, optional `prepaymentRequired`). House rules, pets, children and the damage deposit are `POST /v1/channels/booking/content` with `type: \"settings\"`.  ## Three things about Booking.com that cost real money  **A newly created property is NOT sellable.** Booking.com opens it only when its readiness check passes, and the check names what is missing — a main photo still processing, no availability, a licence the region requires. The response always reports `status: \"being_built\"` and `sellable: false`, never a guess, with the reasons in `warnings`. Resolve them, then `advance`.  **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.  **Room names are Booking.com's.** Travellers see one of Booking.com's standard names (\"Two-Bedroom Apartment\"), chosen from the listing's bedrooms. The listing's own name is kept as the operator-side reference, never shown to guests.  ## 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.  The property category comes from the listing's property type (Apartment when it has none; Holiday home, Villa or Chalet when it says so). The initial room count is 1. 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 [Array<(nil, Integer, Hash)>] nil, response status code and response headers
@@ -378,7 +378,7 @@ module Repull
     # @option opts [Date] :start_date Window start (ISO YYYY-MM-DD).
     # @option opts [Integer] :number_of_days Window length in days.
     # @option opts [String] :room_id Restrict to a single Booking.com room id.
-    # @option opts [Boolean] :room_level When true, returns room-level (vs rate-plan-level) state.
+    # @option opts [Boolean] :room_level Defaults to &#x60;true&#x60;: availability per room, which is how Booking.com keeps inventory and how Vanio reads it. Send &#x60;false&#x60; for the per-rate read — its &#x60;roomsToSell&#x60; is often 0 for rooms that are on sale.
     # @return [BookingAvailabilityStateResponse]
     def get_booking_availability(property_id, opts = {})
       data, _status_code, _headers = get_booking_availability_with_http_info(property_id, opts)
@@ -392,7 +392,7 @@ module Repull
     # @option opts [Date] :start_date Window start (ISO YYYY-MM-DD).
     # @option opts [Integer] :number_of_days Window length in days.
     # @option opts [String] :room_id Restrict to a single Booking.com room id.
-    # @option opts [Boolean] :room_level When true, returns room-level (vs rate-plan-level) state.
+    # @option opts [Boolean] :room_level Defaults to &#x60;true&#x60;: availability per room, which is how Booking.com keeps inventory and how Vanio reads it. Send &#x60;false&#x60; for the per-rate read — its &#x60;roomsToSell&#x60; is often 0 for rooms that are on sale.
     # @return [Array<(BookingAvailabilityStateResponse, Integer, Hash)>] BookingAvailabilityStateResponse data, response status code and response headers
     def get_booking_availability_with_http_info(property_id, opts = {})
       if @api_client.config.debugging
@@ -512,27 +512,44 @@ module Repull
     end
 
     # Get Booking.com content
-    # Fetch the current content (descriptions, amenities, photos) for a Booking.com property. Used to round-trip edits through Repull.  `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.
+    # Read one kind of content for a Booking.com property, straight from Booking.com.  | `type` | What it is | |---|---| | `photos` | The property's photos. Add `room_id` to read one room's gallery. | | `facilities` | Property facilities, or a room's with `room_id` (Booking.com's ids — `GET` returns them). | | `description` | The property description. Booking.com rewrites what you send into its own multilingual copy; allow about 3 hours to appear. | | `settings` | House rules, pets, children, damage deposit, invoice recipient, booking model. | | `policies` | Cancellation and prepayment policies. | | `licences` | The region's licence rules and the licence on file. | | `checkin_methods` | How guests get in (holiday homes). | | `contacts` | Who Booking.com contacts about the property. |  `amenities` is accepted as another name for `facilities`, and `descriptions` for `description`.  `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 property_id [String] Booking.com property id.
     # @param [Hash] opts the optional parameters
+    # @option opts [String] :type Which content to read. (default to 'photos')
+    # @option opts [String] :room_id A Booking.com room id, for &#x60;photos&#x60;, &#x60;facilities&#x60; and &#x60;licences&#x60;.
     # @return [nil]
-    def get_booking_content(opts = {})
-      get_booking_content_with_http_info(opts)
+    def get_booking_content(property_id, opts = {})
+      get_booking_content_with_http_info(property_id, opts)
       nil
     end
 
     # Get Booking.com content
-    # Fetch the current content (descriptions, amenities, photos) for a Booking.com property. Used to round-trip edits through Repull.  &#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.
+    # Read one kind of content for a Booking.com property, straight from Booking.com.  | &#x60;type&#x60; | What it is | |---|---| | &#x60;photos&#x60; | The property&#39;s photos. Add &#x60;room_id&#x60; to read one room&#39;s gallery. | | &#x60;facilities&#x60; | Property facilities, or a room&#39;s with &#x60;room_id&#x60; (Booking.com&#39;s ids — &#x60;GET&#x60; returns them). | | &#x60;description&#x60; | The property description. Booking.com rewrites what you send into its own multilingual copy; allow about 3 hours to appear. | | &#x60;settings&#x60; | House rules, pets, children, damage deposit, invoice recipient, booking model. | | &#x60;policies&#x60; | Cancellation and prepayment policies. | | &#x60;licences&#x60; | The region&#39;s licence rules and the licence on file. | | &#x60;checkin_methods&#x60; | How guests get in (holiday homes). | | &#x60;contacts&#x60; | Who Booking.com contacts about the property. |  &#x60;amenities&#x60; is accepted as another name for &#x60;facilities&#x60;, and &#x60;descriptions&#x60; for &#x60;description&#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 property_id [String] Booking.com property id.
     # @param [Hash] opts the optional parameters
+    # @option opts [String] :type Which content to read. (default to 'photos')
+    # @option opts [String] :room_id A Booking.com room id, for &#x60;photos&#x60;, &#x60;facilities&#x60; and &#x60;licences&#x60;.
     # @return [Array<(nil, Integer, Hash)>] nil, response status code and response headers
-    def get_booking_content_with_http_info(opts = {})
+    def get_booking_content_with_http_info(property_id, opts = {})
       if @api_client.config.debugging
         @api_client.config.logger.debug 'Calling API: BookingComApi.get_booking_content ...'
       end
+      # verify the required parameter 'property_id' is set
+      if @api_client.config.client_side_validation && property_id.nil?
+        fail ArgumentError, "Missing the required parameter 'property_id' when calling BookingComApi.get_booking_content"
+      end
+      allowable_values = ["photos", "facilities", "description", "settings", "policies", "licences", "checkin_methods", "contacts"]
+      if @api_client.config.client_side_validation && opts[:'type'] && !allowable_values.include?(opts[:'type'])
+        fail ArgumentError, "invalid value for \"type\", must be one of #{allowable_values}"
+      end
       # resource path
       local_var_path = '/v1/channels/booking/content'
 
       # query parameters
       query_params = opts[:query_params] || {}
+      query_params[:'property_id'] = property_id
+      query_params[:'type'] = opts[:'type'] if !opts[:'type'].nil?
+      query_params[:'room_id'] = opts[:'room_id'] if !opts[:'room_id'].nil?
 
       # header parameters
       header_params = opts[:header_params] || {}
@@ -575,7 +592,7 @@ module Repull
     # @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 [Boolean] :room_level Defaults to &#x60;true&#x60;: availability per room, which is how Booking.com keeps inventory and how Vanio reads it. Send &#x60;false&#x60; for the per-rate read — its &#x60;roomsToSell&#x60; is often 0 for rooms that are on sale.
     # @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 = {})
@@ -590,7 +607,7 @@ module Repull
     # @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 [Boolean] :room_level Defaults to &#x60;true&#x60;: availability per room, which is how Booking.com keeps inventory and how Vanio reads it. Send &#x60;false&#x60; for the per-rate read — its &#x60;roomsToSell&#x60; is often 0 for rooms that are on sale.
     # @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 = {})
@@ -1080,6 +1097,74 @@ module Repull
       return data, status_code, headers
     end
 
+    # Map a Booking.com room to a Repull listing
+    # Link a Booking.com room to a canonical Repull listing — the API-key equivalent of the room mapping the hosted Connect flow performs, and the counterpart of `POST /v1/channels/airbnb/listings/map`.  Discover `roomBookingId` with `GET /v1/channels/booking/properties/{id}/rooms`, which returns every room of a property with the `roomId` this route takes.  Booking.com attaches at the ROOM level: a property is a building and its rooms are what a guest books, so each room maps to one listing. Pass `listingId: null` to unmap a room and remove its channel link.  The room mapping and its channel link are repointed together in one transaction, so a link can never outlive the mapping it describes — a stale link keeps routing that room's reservations to the previous listing. Re-sending a mapping that is already in place writes nothing (`alreadyMapped: true`).  **The property's reservations are pulled as part of the call.** Once the room is mapped, every active reservation Booking.com holds for the property is imported and attached to its listing — `reservationsImported` says how many were processed. One already present is left as it is, so re-sending never duplicates. You do not need a follow-up call: reservations that arrived before the room was mapped are never picked up by the regular sync, so this is the moment they are brought in. It runs on every successful map, including a re-send, so re-sending retries an import that did not run. If the import cannot run, the mapping still stands and `reservationsImported` is `null`. A property with a long booking history can take tens of seconds. Unmapping pulls nothing.  Unlike the Airbnb route, there is no conflict when the target listing already carries another Booking.com room: one listing served by several rooms is a normal arrangement and is not refused.  Scope is enforced on both sides against your workspace — the room's property and the target listing. A room or listing belonging to another workspace returns the same 404 as one that does not exist.  Returns `403 listing_inactive` when the target listing, or the listing the room is mapped to now, is inactive; nothing is changed.
+    # @param map_booking_room_request [MapBookingRoomRequest] 
+    # @param [Hash] opts the optional parameters
+    # @return [MapBookingRoomResponse]
+    def map_booking_room(map_booking_room_request, opts = {})
+      data, _status_code, _headers = map_booking_room_with_http_info(map_booking_room_request, opts)
+      data
+    end
+
+    # Map a Booking.com room to a Repull listing
+    # Link a Booking.com room to a canonical Repull listing — the API-key equivalent of the room mapping the hosted Connect flow performs, and the counterpart of &#x60;POST /v1/channels/airbnb/listings/map&#x60;.  Discover &#x60;roomBookingId&#x60; with &#x60;GET /v1/channels/booking/properties/{id}/rooms&#x60;, which returns every room of a property with the &#x60;roomId&#x60; this route takes.  Booking.com attaches at the ROOM level: a property is a building and its rooms are what a guest books, so each room maps to one listing. Pass &#x60;listingId: null&#x60; to unmap a room and remove its channel link.  The room mapping and its channel link are repointed together in one transaction, so a link can never outlive the mapping it describes — a stale link keeps routing that room&#39;s reservations to the previous listing. Re-sending a mapping that is already in place writes nothing (&#x60;alreadyMapped: true&#x60;).  **The property&#39;s reservations are pulled as part of the call.** Once the room is mapped, every active reservation Booking.com holds for the property is imported and attached to its listing — &#x60;reservationsImported&#x60; says how many were processed. One already present is left as it is, so re-sending never duplicates. You do not need a follow-up call: reservations that arrived before the room was mapped are never picked up by the regular sync, so this is the moment they are brought in. It runs on every successful map, including a re-send, so re-sending retries an import that did not run. If the import cannot run, the mapping still stands and &#x60;reservationsImported&#x60; is &#x60;null&#x60;. A property with a long booking history can take tens of seconds. Unmapping pulls nothing.  Unlike the Airbnb route, there is no conflict when the target listing already carries another Booking.com room: one listing served by several rooms is a normal arrangement and is not refused.  Scope is enforced on both sides against your workspace — the room&#39;s property and the target listing. A room or listing belonging to another workspace returns the same 404 as one that does not exist.  Returns &#x60;403 listing_inactive&#x60; when the target listing, or the listing the room is mapped to now, is inactive; nothing is changed.
+    # @param map_booking_room_request [MapBookingRoomRequest] 
+    # @param [Hash] opts the optional parameters
+    # @return [Array<(MapBookingRoomResponse, Integer, Hash)>] MapBookingRoomResponse data, response status code and response headers
+    def map_booking_room_with_http_info(map_booking_room_request, opts = {})
+      if @api_client.config.debugging
+        @api_client.config.logger.debug 'Calling API: BookingComApi.map_booking_room ...'
+      end
+      # verify the required parameter 'map_booking_room_request' is set
+      if @api_client.config.client_side_validation && map_booking_room_request.nil?
+        fail ArgumentError, "Missing the required parameter 'map_booking_room_request' when calling BookingComApi.map_booking_room"
+      end
+      # resource path
+      local_var_path = '/v1/channels/booking/listings/map'
+
+      # query parameters
+      query_params = opts[:query_params] || {}
+
+      # 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
+
+      # form parameters
+      form_params = opts[:form_params] || {}
+
+      # http body (model)
+      post_body = opts[:debug_body] || @api_client.object_to_http_body(map_booking_room_request)
+
+      # return_type
+      return_type = opts[:debug_return_type] || 'MapBookingRoomResponse'
+
+      # auth_names
+      auth_names = opts[:debug_auth_names] || ['bearerAuth']
+
+      new_options = opts.merge(
+        :operation => :"BookingComApi.map_booking_room",
+        :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#map_booking_room\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
+      end
+      return data, status_code, headers
+    end
+
     # Reply to Booking.com review
     # Post a public host reply to a guest review on Booking.com. Booking allows one host reply per review — repeated POSTs are rejected by upstream.  Booking.com does NOT support host-authored reviews of guests via the API (platform-level limitation), so this endpoint is reply-only.  `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 reply_booking_review_request [ReplyBookingReviewRequest] 
@@ -1353,22 +1438,28 @@ module Repull
     end
 
     # Update Booking.com content
-    # Push content changes (descriptions, amenities, photos) to Booking.com. Booking enforces editorial review on text fields — changes appear after their content moderation queue clears.  `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 one kind of content to a Booking.com property only. Nothing on the canonical listing or on Airbnb changes. To send the listing's own content to every channel instead, use `PUT /v1/listings/{id}/content` and publish.  | `type` | What it is | |---|---| | `photos` | The property's photos. Add `room_id` to read one room's gallery. | | `facilities` | Property facilities, or a room's with `room_id` (Booking.com's ids — `GET` returns them). | | `description` | The property description. Booking.com rewrites what you send into its own multilingual copy; allow about 3 hours to appear. | | `settings` | House rules, pets, children, damage deposit, invoice recipient, booking model. | | `policies` | Cancellation and prepayment policies. | | `licences` | The region's licence rules and the licence on file. | | `checkin_methods` | How guests get in (holiday homes). | | `contacts` | Who Booking.com contacts about the property. |  `amenities` is accepted as another name for `facilities`, and `descriptions` for `description`.  What each `type` takes:  - `description`: `text`, optional `language` (default `en`). - `facilities`: `facilities: [{ facility_id | room_facility_id, state: \"PRESENT\" | \"MISSING\", instances? }]`. Facilities you do not send stay as they are. - `photos`: `photos: [{ url }]`, uploaded in the background. With `room_id`, send `photo_ids` instead to add photos that have finished processing to that room. - `settings`: `settings: { <block>: {…} }`, for example `{ \"pets\": { \"pets_allowed\": \"PETS_ALLOWED\" } }`. Each block is written separately and reported in `results`. - `policies`: `policyCode` (152 = free cancellation at any time, 1 = non-refundable, …), optional `prepaymentRequired`; add `policyId` to change an existing policy. A property holds at most 7 policies and none can be deleted. - `licences`: `variantId` and `contentData: [{ name, value }]`, from the rules `GET ?type=licences` returns; optional `room_id`. - `checkin_methods`: `methods: [{ checkin_method }]`, using a name from `GET ?type=checkin_methods` `available`. - `contacts`: `contacts: [...]` in Booking.com's contact shape.  If Booking.com refuses the write, the response is `422 booking_rejected` with Booking.com's reason, even when Booking.com answered HTTP 200. Resending the same body will be refused again.  `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 update_booking_content_request [UpdateBookingContentRequest] 
     # @param [Hash] opts the optional parameters
     # @return [nil]
-    def update_booking_content(opts = {})
-      update_booking_content_with_http_info(opts)
+    def update_booking_content(update_booking_content_request, opts = {})
+      update_booking_content_with_http_info(update_booking_content_request, opts)
       nil
     end
 
     # Update Booking.com content
-    # Push content changes (descriptions, amenities, photos) to Booking.com. Booking enforces editorial review on text fields — changes appear after their content moderation queue clears.  &#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 one kind of content to a Booking.com property only. Nothing on the canonical listing or on Airbnb changes. To send the listing&#39;s own content to every channel instead, use &#x60;PUT /v1/listings/{id}/content&#x60; and publish.  | &#x60;type&#x60; | What it is | |---|---| | &#x60;photos&#x60; | The property&#39;s photos. Add &#x60;room_id&#x60; to read one room&#39;s gallery. | | &#x60;facilities&#x60; | Property facilities, or a room&#39;s with &#x60;room_id&#x60; (Booking.com&#39;s ids — &#x60;GET&#x60; returns them). | | &#x60;description&#x60; | The property description. Booking.com rewrites what you send into its own multilingual copy; allow about 3 hours to appear. | | &#x60;settings&#x60; | House rules, pets, children, damage deposit, invoice recipient, booking model. | | &#x60;policies&#x60; | Cancellation and prepayment policies. | | &#x60;licences&#x60; | The region&#39;s licence rules and the licence on file. | | &#x60;checkin_methods&#x60; | How guests get in (holiday homes). | | &#x60;contacts&#x60; | Who Booking.com contacts about the property. |  &#x60;amenities&#x60; is accepted as another name for &#x60;facilities&#x60;, and &#x60;descriptions&#x60; for &#x60;description&#x60;.  What each &#x60;type&#x60; takes:  - &#x60;description&#x60;: &#x60;text&#x60;, optional &#x60;language&#x60; (default &#x60;en&#x60;). - &#x60;facilities&#x60;: &#x60;facilities: [{ facility_id | room_facility_id, state: \&quot;PRESENT\&quot; | \&quot;MISSING\&quot;, instances? }]&#x60;. Facilities you do not send stay as they are. - &#x60;photos&#x60;: &#x60;photos: [{ url }]&#x60;, uploaded in the background. With &#x60;room_id&#x60;, send &#x60;photo_ids&#x60; instead to add photos that have finished processing to that room. - &#x60;settings&#x60;: &#x60;settings: { &lt;block&gt;: {…} }&#x60;, for example &#x60;{ \&quot;pets\&quot;: { \&quot;pets_allowed\&quot;: \&quot;PETS_ALLOWED\&quot; } }&#x60;. Each block is written separately and reported in &#x60;results&#x60;. - &#x60;policies&#x60;: &#x60;policyCode&#x60; (152 &#x3D; free cancellation at any time, 1 &#x3D; non-refundable, …), optional &#x60;prepaymentRequired&#x60;; add &#x60;policyId&#x60; to change an existing policy. A property holds at most 7 policies and none can be deleted. - &#x60;licences&#x60;: &#x60;variantId&#x60; and &#x60;contentData: [{ name, value }]&#x60;, from the rules &#x60;GET ?type&#x3D;licences&#x60; returns; optional &#x60;room_id&#x60;. - &#x60;checkin_methods&#x60;: &#x60;methods: [{ checkin_method }]&#x60;, using a name from &#x60;GET ?type&#x3D;checkin_methods&#x60; &#x60;available&#x60;. - &#x60;contacts&#x60;: &#x60;contacts: [...]&#x60; in Booking.com&#39;s contact shape.  If Booking.com refuses the write, the response is &#x60;422 booking_rejected&#x60; with Booking.com&#39;s reason, even when Booking.com answered HTTP 200. Resending the same body will be refused again.  &#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 update_booking_content_request [UpdateBookingContentRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(nil, Integer, Hash)>] nil, response status code and response headers
-    def update_booking_content_with_http_info(opts = {})
+    def update_booking_content_with_http_info(update_booking_content_request, opts = {})
       if @api_client.config.debugging
         @api_client.config.logger.debug 'Calling API: BookingComApi.update_booking_content ...'
       end
+      # verify the required parameter 'update_booking_content_request' is set
+      if @api_client.config.client_side_validation && update_booking_content_request.nil?
+        fail ArgumentError, "Missing the required parameter 'update_booking_content_request' when calling BookingComApi.update_booking_content"
+      end
       # resource path
       local_var_path = '/v1/channels/booking/content'
 
@@ -1379,12 +1470,17 @@ module Repull
       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
 
       # form parameters
       form_params = opts[:form_params] || {}
 
       # http body (model)
-      post_body = opts[:debug_body]
+      post_body = opts[:debug_body] || @api_client.object_to_http_body(update_booking_content_request)
 
       # return_type
       return_type = opts[:debug_return_type]

data/lib/repull/models/listing_content_update_request.rb

@@ -39,6 +39,12 @@ module Repull
 
     attr_accessor :occupancy
 
+    # The listing's rooms and the beds in each — what Airbnb shows as the sleeping arrangements and needs before a listing can go live. FULL replacement: the rooms you send become the whole set. Omit to leave rooms untouched; send `[]` to clear them.  Every entry is checked before anything is written, so a bad entry refuses the whole request with `422 invalid_params` naming it (e.g. `rooms[1].beds[0].quantity`) — a listing is never left with half its rooms.  Values use Airbnb's vocabulary, which Booking.com room mapping also reads. This is a local write; publish to send it to a channel.
+    attr_accessor :rooms
+
+    # What the guest is asked to do before leaving. FULL replacement: omit to leave untouched; send `[]` to clear. An unknown `taskType` refuses the whole request with `422 invalid_params`.  Published to Airbnb, which is the only channel with checkout tasks. Airbnb accepts them only from partner apps it has certified for the feature; until then the publish result reports Airbnb's own refusal for this section and every other section still lands.
+    attr_accessor :checkout_tasks
+
     attr_accessor :pricing
 
     attr_accessor :policies
@@ -61,6 +67,8 @@ module Repull
         :'address' => :'address',
         :'details' => :'details',
         :'occupancy' => :'occupancy',
+        :'rooms' => :'rooms',
+        :'checkout_tasks' => :'checkoutTasks',
         :'pricing' => :'pricing',
         :'policies' => :'policies',
         :'photos' => :'photos',
@@ -90,6 +98,8 @@ module Repull
         :'address' => :'ListingContentUpdateRequestAddress',
         :'details' => :'ListingContentUpdateRequestDetails',
         :'occupancy' => :'ListingContentUpdateRequestOccupancy',
+        :'rooms' => :'Array<ListingContentUpdateRequestRoomsInner>',
+        :'checkout_tasks' => :'Array<ListingContentUpdateRequestCheckoutTasksInner>',
         :'pricing' => :'ListingContentUpdateRequestPricing',
         :'policies' => :'ListingContentUpdateRequestPolicies',
         :'photos' => :'Array<ListingContentUpdateRequestPhotosInner>',
@@ -104,6 +114,8 @@ module Repull
         :'name',
         :'description',
         :'summary',
+        :'rooms',
+        :'checkout_tasks',
       ])
     end
 
@@ -159,6 +171,18 @@ module Repull
         self.occupancy = attributes[:'occupancy']
       end
 
+      if attributes.key?(:'rooms')
+        if (value = attributes[:'rooms']).is_a?(Array)
+          self.rooms = value
+        end
+      end
+
+      if attributes.key?(:'checkout_tasks')
+        if (value = attributes[:'checkout_tasks']).is_a?(Array)
+          self.checkout_tasks = value
+        end
+      end
+
       if attributes.key?(:'pricing')
         self.pricing = attributes[:'pricing']
       end
@@ -209,6 +233,8 @@ module Repull
           address == o.address &&
           details == o.details &&
           occupancy == o.occupancy &&
+          rooms == o.rooms &&
+          checkout_tasks == o.checkout_tasks &&
           pricing == o.pricing &&
           policies == o.policies &&
           photos == o.photos &&
@@ -224,7 +250,7 @@ module Repull
     # Calculates hash code according to all attributes.
     # @return [Integer] Hash code
     def hash
-      [locale, title, name, description, summary, amenities, address, details, occupancy, pricing, policies, photos, photos_mode].hash
+      [locale, title, name, description, summary, amenities, address, details, occupancy, rooms, checkout_tasks, pricing, policies, photos, photos_mode].hash
     end
 
     # Builds the object from hash

data/lib/repull/models/listing_content_update_request_checkout_tasks_inner.rb

@@ -0,0 +1,210 @@
+=begin
+#Repull API
+
+#The unified API for vacation rental tech. Connect to 50+ PMS platforms and 4 OTA channels through one REST API. Built-in AI operations for guest communication, pricing, and listing optimization.  ## Designed for AI agents Every error response on this API includes machine-parseable fields so an LLM (Claude in MCP, Cursor, Cline, GPT, etc.) can self-recover without escalating to a human: - `error.code` — stable string identifier (e.g. `invalid_params`, `rate_limit_exceeded`) - `error.message` — human-readable cause - `error.fix` — exact recovery steps (e.g. \"Pass `check_in_after` as ISO 8601: `?check_in_after=2026-01-15`\") - `error.docs_url` — link to the canonical write-up at `https://repull.dev/docs/errors/{code}` - `error.request_id` — id to correlate with server-side logs - `error.field` / `error.value_received` / `error.valid_values` / `error.did_you_mean` — when the error is parameter-specific - `error.retry_after` — seconds to wait before retrying (rate-limit + transient upstream)  `Access-Control-Expose-Headers` lists `x-request-id` and the `X-RateLimit-*` family so browsers can read them on cross-origin responses.  ## Quick Start 1. Get an API key at https://repull.dev/dashboard 2. Connect a PMS: `POST /v1/connect/{provider}` 3. List properties: `GET /v1/properties` 4. Get reservations: `GET /v1/reservations`  ## Authentication All requests require a Bearer token: ``` Authorization: Bearer sk_live_YOUR_API_KEY ```  ## Request Correlation (X-Request-ID) Every response carries an `X-Request-ID` header, e.g. `X-Request-ID: req_01HXY...`. Include this id in support tickets and bug reports — we can trace the full request lifecycle (auth, rate limit, handler, downstream calls, log row) from a single id.  You may set the header on the inbound request to forward your own trace id; we will echo it back instead of generating a new one. Accepted format: `^[\\\\w.-]{1,128}$`.  The id is also embedded in error envelopes as `request_id` so server-side log diffs work even when the response headers are stripped by an intermediate proxy.  ## Rate Limits The public API enforces a per-API-key sliding-window rate limit on top of the per-tier monthly + daily-AI quotas.  **Default policy:** 600 requests per 60 seconds, per API key. Sliding window — there is no fixed-minute boundary you can burst across.  Every response includes:  | Header | Meaning | |---|---| | `X-RateLimit-Limit` | Requests permitted in the current window. | | `X-RateLimit-Remaining` | Requests left in the current window after this call. | | `X-RateLimit-Reset` | Unix epoch (seconds) when the next slot opens. | | `X-RateLimit-Policy` | Machine-readable policy descriptor, e.g. `600;w=60`. | | `Retry-After` | Seconds to wait before retrying. **Only present on 429 responses.** |  **On 429 (rate_limit_exceeded):** the response body matches the standard error envelope with `code: \"rate_limit_exceeded\"`, plus `limit`, `window_seconds`, `retry_after`, and `request_id` fields. SDKs MUST honor `Retry-After` and use exponential backoff with jitter on subsequent retries — never a tight loop.  Recommended backoff: ``` sleep_ms = (Retry-After * 1000) + random(0..250) ```  Monthly + daily-AI tier quotas (`free`, `starter`, `custom`) are enforced separately and also surface as 429s; they include `tier`, `scope`, and `resetsAt` fields.  ## Plan Limits (402 — `listings_limit_exceeded`) The Repull API also enforces a per-tier cap on **active listings**:  | Tier | Active listings cap | |---|---| | `free` | 3 | | `starter` | 50 | | `custom` | unlimited |  When a customer's active-listing count is above their tier cap, the API returns **`402 Payment Required`** with `error.code = \"listings_limit_exceeded\"` on every route EXCEPT:  - `/v1/health` — uptime probes are never gated. - `/v1/usage/*` — so dashboards can render the over-cap state. - Any `DELETE` — so the customer can trim listings to get back under the cap without paying.  Unlike 429, 402 is NOT a \"wait and retry\" condition — `Retry-After` is not set. The only paths back to 200 are:   1. `DELETE` enough listings to come back under the cap, or   2. Upgrade at `https://repull.dev/dashboard/billing`. The server-side usage cache is 60s, so the first 200 after an upgrade may take up to a minute.  The envelope mirrors `rate_limit_exceeded` for SDK ergonomics: `tier`, `limit`, `active_listings`, `upgrade_url`, plus the standard `code` / `message` / `fix` / `docs_url` / `request_id`.
+
+The version of the OpenAPI document: 1.0.0
+Contact: ivan@vanio.ai
+Generated by: https://openapi-generator.tech
+Generator version: 7.22.0
+
+=end
+
+require 'date'
+require 'time'
+
+module Repull
+  class ListingContentUpdateRequestCheckoutTasksInner < ApiModelBase
+    # Any casing is accepted; stored lowercase.
+    attr_accessor :task_type
+
+    # Detail shown to the guest with the task, e.g. \"Leave the keys on the kitchen counter\".
+    attr_accessor :instructions
+
+    attr_accessor :required
+
+    class EnumAttributeValidator
+      attr_reader :datatype
+      attr_reader :allowable_values
+
+      def initialize(datatype, allowable_values)
+        @allowable_values = allowable_values.map do |value|
+          case datatype.to_s
+          when /Integer/i
+            value.to_i
+          when /Float/i
+            value.to_f
+          else
+            value
+          end
+        end
+      end
+
+      def valid?(value)
+        !value || allowable_values.include?(value)
+      end
+    end
+
+    # Attribute mapping from ruby-style variable name to JSON key.
+    def self.attribute_map
+      {
+        :'task_type' => :'taskType',
+        :'instructions' => :'instructions',
+        :'required' => :'required'
+      }
+    end
+
+    # Returns attribute mapping this model knows about
+    def self.acceptable_attribute_map
+      attribute_map
+    end
+
+    # Returns all the JSON keys this model knows about
+    def self.acceptable_attributes
+      acceptable_attribute_map.values
+    end
+
+    # Attribute type mapping.
+    def self.openapi_types
+      {
+        :'task_type' => :'String',
+        :'instructions' => :'String',
+        :'required' => :'Boolean'
+      }
+    end
+
+    # List of attributes with nullable: true
+    def self.openapi_nullable
+      Set.new([
+        :'instructions',
+        :'required'
+      ])
+    end
+
+    # Initializes the object
+    # @param [Hash] attributes Model attributes in the form of hash
+    def initialize(attributes = {})
+      if (!attributes.is_a?(Hash))
+        fail ArgumentError, "The input argument (attributes) must be a hash in `Repull::ListingContentUpdateRequestCheckoutTasksInner` initialize method"
+      end
+
+      # check to see if the attribute exists and convert string to symbol for hash key
+      acceptable_attribute_map = self.class.acceptable_attribute_map
+      attributes = attributes.each_with_object({}) { |(k, v), h|
+        if (!acceptable_attribute_map.key?(k.to_sym))
+          fail ArgumentError, "`#{k}` is not a valid attribute in `Repull::ListingContentUpdateRequestCheckoutTasksInner`. Please check the name to make sure it's valid. List of attributes: " + acceptable_attribute_map.keys.inspect
+        end
+        h[k.to_sym] = v
+      }
+
+      if attributes.key?(:'task_type')
+        self.task_type = attributes[:'task_type']
+      else
+        self.task_type = nil
+      end
+
+      if attributes.key?(:'instructions')
+        self.instructions = attributes[:'instructions']
+      end
+
+      if attributes.key?(:'required')
+        self.required = attributes[:'required']
+      end
+    end
+
+    # Show invalid properties with the reasons. Usually used together with valid?
+    # @return Array for valid properties with the reasons
+    def list_invalid_properties
+      warn '[DEPRECATED] the `list_invalid_properties` method is obsolete'
+      invalid_properties = Array.new
+      if @task_type.nil?
+        invalid_properties.push('invalid value for "task_type", task_type cannot be nil.')
+      end
+
+      invalid_properties
+    end
+
+    # Check to see if the all the properties in the model are valid
+    # @return true if the model is valid
+    def valid?
+      warn '[DEPRECATED] the `valid?` method is obsolete'
+      return false if @task_type.nil?
+      task_type_validator = EnumAttributeValidator.new('String', ["return_keys", "turn_things_off", "throw_trash", "lock_up", "gather_towels", "additional_requests"])
+      return false unless task_type_validator.valid?(@task_type)
+      true
+    end
+
+    # Custom attribute writer method checking allowed values (enum).
+    # @param [Object] task_type Object to be assigned
+    def task_type=(task_type)
+      validator = EnumAttributeValidator.new('String', ["return_keys", "turn_things_off", "throw_trash", "lock_up", "gather_towels", "additional_requests"])
+      unless validator.valid?(task_type)
+        fail ArgumentError, "invalid value for \"task_type\", must be one of #{validator.allowable_values}."
+      end
+      @task_type = task_type
+    end
+
+    # Checks equality by comparing each attribute.
+    # @param [Object] Object to be compared
+    def ==(o)
+      return true if self.equal?(o)
+      self.class == o.class &&
+          task_type == o.task_type &&
+          instructions == o.instructions &&
+          required == o.required
+    end
+
+    # @see the `==` method
+    # @param [Object] Object to be compared
+    def eql?(o)
+      self == o
+    end
+
+    # Calculates hash code according to all attributes.
+    # @return [Integer] Hash code
+    def hash
+      [task_type, instructions, required].hash
+    end
+
+    # Builds the object from hash
+    # @param [Hash] attributes Model attributes in the form of hash
+    # @return [Object] Returns the model itself
+    def self.build_from_hash(attributes)
+      return nil unless attributes.is_a?(Hash)
+      attributes = attributes.transform_keys(&:to_sym)
+      transformed_hash = {}
+      openapi_types.each_pair do |key, type|
+        if attributes.key?(attribute_map[key]) && attributes[attribute_map[key]].nil?
+          transformed_hash["#{key}"] = nil
+        elsif type =~ /\AArray<(.*)>/i
+          # check to ensure the input is an array given that the attribute
+          # is documented as an array but the input is not
+          if attributes[attribute_map[key]].is_a?(Array)
+            transformed_hash["#{key}"] = attributes[attribute_map[key]].map { |v| _deserialize($1, v) }
+          end
+        elsif !attributes[attribute_map[key]].nil?
+          transformed_hash["#{key}"] = _deserialize(type, attributes[attribute_map[key]])
+        end
+      end
+      new(transformed_hash)
+    end
+
+    # Returns the object in the form of hash
+    # @return [Hash] Returns the object in the form of hash
+    def to_hash
+      hash = {}
+      self.class.attribute_map.each_pair do |attr, param|
+        value = self.send(attr)
+        if value.nil?
+          is_nullable = self.class.openapi_nullable.include?(attr)
+          next if !is_nullable || (is_nullable && !instance_variable_defined?(:"@#{attr}"))
+        end
+
+        hash[param] = _to_hash(value)
+      end
+      hash
+    end
+
+  end
+
+end