repull 0.2.27 → 0.2.29

data/openapi/v1.json

@@ -3,7 +3,7 @@
   "info": {
     "title": "Repull API",
     "version": "1.0.0",
-    "description": "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.\n\n## Designed for AI agents\nEvery 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:\n- `error.code` \u2014 stable string identifier (e.g. `invalid_params`, `rate_limit_exceeded`)\n- `error.message` \u2014 human-readable cause\n- `error.fix` \u2014 exact recovery steps (e.g. \"Pass `check_in_after` as ISO 8601: `?check_in_after=2026-01-15`\")\n- `error.docs_url` \u2014 link to the canonical write-up at `https://repull.dev/docs/errors/{code}`\n- `error.request_id` \u2014 id to correlate with server-side logs\n- `error.field` / `error.value_received` / `error.valid_values` / `error.did_you_mean` \u2014 when the error is parameter-specific\n- `error.retry_after` \u2014 seconds to wait before retrying (rate-limit + transient upstream)\n\n`Access-Control-Expose-Headers` lists `x-request-id` and the `X-RateLimit-*` family so browsers can read them on cross-origin responses.\n\n## Quick Start\n1. Get an API key at https://repull.dev/dashboard\n2. Connect a PMS: `POST /v1/connect/{provider}`\n3. List properties: `GET /v1/properties`\n4. Get reservations: `GET /v1/reservations`\n\n## Authentication\nAll requests require a Bearer token:\n```\nAuthorization: Bearer sk_live_YOUR_API_KEY\n```\n\n## Request Correlation (X-Request-ID)\nEvery response carries an `X-Request-ID` header, e.g. `X-Request-ID: req_01HXY...`. Include this id in support tickets and bug reports \u2014 we can trace the full request lifecycle (auth, rate limit, handler, downstream calls, log row) from a single id.\n\nYou 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}$`.\n\nThe 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.\n\n## Rate Limits\nThe public API enforces a per-API-key sliding-window rate limit on top of the per-tier monthly + daily-AI quotas.\n\n**Default policy:** 600 requests per 60 seconds, per API key. Sliding window \u2014 there is no fixed-minute boundary you can burst across.\n\nEvery response includes:\n\n| Header | Meaning |\n|---|---|\n| `X-RateLimit-Limit` | Requests permitted in the current window. |\n| `X-RateLimit-Remaining` | Requests left in the current window after this call. |\n| `X-RateLimit-Reset` | Unix epoch (seconds) when the next slot opens. |\n| `X-RateLimit-Policy` | Machine-readable policy descriptor, e.g. `600;w=60`. |\n| `Retry-After` | Seconds to wait before retrying. **Only present on 429 responses.** |\n\n**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 \u2014 never a tight loop.\n\nRecommended backoff:\n```\nsleep_ms = (Retry-After * 1000) + random(0..250)\n```\n\nMonthly + daily-AI tier quotas (`free`, `starter`, `custom`) are enforced separately and also surface as 429s; they include `tier`, `scope`, and `resetsAt` fields.\n\n## Plan Limits (402 \u2014 `listings_limit_exceeded`)\nThe Repull API also enforces a per-tier cap on **active listings**:\n\n| Tier | Active listings cap |\n|---|---|\n| `free` | 3 |\n| `starter` | 50 |\n| `custom` | unlimited |\n\nWhen 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:\n\n- `/v1/health` \u2014 uptime probes are never gated.\n- `/v1/usage/*` \u2014 so dashboards can render the over-cap state.\n- Any `DELETE` \u2014 so the customer can trim listings to get back under the cap without paying.\n\nUnlike 429, 402 is NOT a \"wait and retry\" condition \u2014 `Retry-After` is not set. The only paths back to 200 are:\n  1. `DELETE` enough listings to come back under the cap, or\n  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.\n\nThe envelope mirrors `rate_limit_exceeded` for SDK ergonomics: `tier`, `limit`, `active_listings`, `upgrade_url`, plus the standard `code` / `message` / `fix` / `docs_url` / `request_id`.",
+    "description": "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.\n\n## Designed for AI agents\nEvery 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:\n- `error.code` \u2014 stable string identifier (e.g. `invalid_params`, `rate_limit_exceeded`)\n- `error.message` \u2014 human-readable cause\n- `error.fix` \u2014 exact recovery steps (e.g. \"Pass `check_in_after` as ISO 8601: `?check_in_after=2026-01-15`\")\n- `error.docs_url` \u2014 link to the canonical write-up at `https://repull.dev/docs/errors/{code}`\n- `error.request_id` \u2014 id to correlate with server-side logs\n- `error.field` / `error.value_received` / `error.valid_values` / `error.did_you_mean` \u2014 when the error is parameter-specific\n- `error.retry_after` \u2014 seconds to wait before retrying (rate-limit + transient upstream)\n\n`Access-Control-Expose-Headers` lists `x-request-id` and the `X-RateLimit-*` family so browsers can read them on cross-origin responses.\n\n## Quick Start\n1. Get an API key at https://repull.dev/dashboard\n2. Connect a PMS: `POST /v1/connect/{provider}`\n3. List properties: `GET /v1/properties`\n4. Get reservations: `GET /v1/reservations`\n\n## Authentication\nAll requests require a Bearer token:\n```\nAuthorization: Bearer sk_live_YOUR_API_KEY\n```\n\n## Request Correlation (X-Request-ID)\nEvery response carries an `X-Request-ID` header, e.g. `X-Request-ID: req_01HXY...`. Include this id in support tickets and bug reports \u2014 we can trace the full request lifecycle (auth, rate limit, handler, downstream calls, log row) from a single id.\n\nYou 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}$`.\n\nThe 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.\n\n## Rate Limits\nThe public API enforces a per-API-key sliding-window rate limit on top of the per-tier monthly + daily-AI quotas.\n\n**Default policy:** 600 requests per 60 seconds, per API key. Sliding window \u2014 there is no fixed-minute boundary you can burst across.\n\nEvery response includes:\n\n| Header | Meaning |\n|---|---|\n| `X-RateLimit-Limit` | Requests permitted in the current window. |\n| `X-RateLimit-Remaining` | Requests left in the current window after this call. |\n| `X-RateLimit-Reset` | Unix epoch (seconds) when the next slot opens. |\n| `X-RateLimit-Policy` | Machine-readable policy descriptor, e.g. `600;w=60`. |\n| `Retry-After` | Seconds to wait before retrying. **Only present on 429 responses.** |\n\n**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 \u2014 never a tight loop.\n\nRecommended backoff:\n```\nsleep_ms = (Retry-After * 1000) + random(0..250)\n```\n\nMonthly + daily-AI tier quotas (`free`, `starter`, `custom`) are enforced separately and also surface as 429s; they include `tier`, `scope`, and `resetsAt` fields.\n\n## Plan Limits (402 \u2014 `listings_limit_exceeded`)\nThe Repull API also enforces a per-tier cap on **active listings**:\n\n| Tier | Active listings cap |\n|---|---|\n| `free` | 3 |\n| `starter` | unlimited (10 included, then billed per listing) |\n| `custom` | unlimited |\n\nWhen 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:\n\n- `/v1/health` \u2014 uptime probes are never gated.\n- `/v1/usage/*` \u2014 so dashboards can render the over-cap state.\n- Any `DELETE` \u2014 so the customer can trim listings to get back under the cap without paying.\n\nUnlike 429, 402 is NOT a \"wait and retry\" condition \u2014 `Retry-After` is not set. The only paths back to 200 are:\n  1. `DELETE` enough listings to come back under the cap, or\n  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.\n\nThe envelope mirrors `rate_limit_exceeded` for SDK ergonomics: `tier`, `limit`, `active_listings`, `upgrade_url`, plus the standard `code` / `message` / `fix` / `docs_url` / `request_id`.",
     "contact": {
       "url": "https://repull.dev"
     },
@@ -1368,6 +1368,12 @@
             "type": "string",
             "nullable": true
           },
+          "pms": {
+            "type": "string",
+            "nullable": true,
+            "example": "guesty",
+            "description": "The PMS this review was read from (`guesty`, `hostaway`, \u2026) when it came through one \u2014 `platform` is still the channel the guest wrote it on. A reply (`POST /v1/reviews/{id}/reply`) goes through this PMS; `GET /v1/connect/{provider}` \u2192 `capabilities.pms.reviews.reply` says whether it can. `null` for a review from a directly connected channel."
+          },
           "listingId": {
             "type": "string",
             "nullable": true,
@@ -2171,10 +2177,13 @@
           },
           "capabilities": {
             "type": "object",
-            "description": "PMS providers only. `reservations`: which reservation writes the API performs on this connection's listings \u2014 the connector's support combined with `writePolicy`. When `connected` is false, what the connector supports once connected.",
+            "description": "PMS providers only. `reservations`: which reservation writes the API performs on this connection's listings \u2014 the connector's support combined with `writePolicy`. `pms`: everything else the API does through this PMS (review replies, request answers, listing content, guests, message channel/attachments, calendar). When `connected` is false, what the connector supports once connected.",
             "properties": {
               "reservations": {
                 "$ref": "#/components/schemas/ReservationCapabilities"
+              },
+              "pms": {
+                "$ref": "#/components/schemas/PmsCapabilities"
               }
             }
           },
@@ -8061,7 +8070,51 @@
             "items": {
               "type": "string"
             },
-            "description": "Provided-but-not-applied fields \u2014 e.g. \"photos\" when a non-empty photos array carried no valid http(s) URL."
+            "description": "Provided-but-not-applied fields \u2014 e.g. \"photos\" when a non-empty photos array carried no valid http(s) URL. On a listing a PMS manages, also the content sections the PMS refused (`title`, `descriptions`, `times`, `capacity`, `amenities`, `houseRules`, `address`, `photos`), which are then not written here either."
+          },
+          "pms": {
+            "type": "object",
+            "nullable": true,
+            "description": "Present when the listing is managed in a PMS: the PMS-owned fields were written there first, and this is its per-section outcome.",
+            "properties": {
+              "provider": {
+                "type": "string",
+                "example": "guesty"
+              },
+              "applied": {
+                "type": "array",
+                "items": {
+                  "type": "string"
+                },
+                "description": "Sections the PMS applied."
+              },
+              "errors": {
+                "type": "array",
+                "items": {
+                  "type": "object",
+                  "properties": {
+                    "section": {
+                      "type": "string"
+                    },
+                    "code": {
+                      "type": "string",
+                      "enum": [
+                        "rejected",
+                        "unavailable",
+                        "unsupported",
+                        "not_found",
+                        "reauth_required",
+                        "duplicate"
+                      ]
+                    },
+                    "message": {
+                      "type": "string"
+                    }
+                  }
+                },
+                "description": "Sections the PMS refused, with its reason."
+              }
+            }
           }
         }
       },
@@ -8748,10 +8801,13 @@
         "properties": {
           "capabilities": {
             "type": "object",
-            "description": "`GET /v1/listings/{id}` only. What the API can do with this listing.",
+            "description": "`GET /v1/listings/{id}` only. What the API can do with this listing. `pms` is present when a connected PMS manages it.",
             "properties": {
               "reservations": {
                 "$ref": "#/components/schemas/ReservationCapabilities"
+              },
+              "pms": {
+                "$ref": "#/components/schemas/PmsCapabilities"
               }
             }
           },
@@ -11725,6 +11781,150 @@
           }
         }
       },
+      "PmsCapabilities": {
+        "type": "object",
+        "description": "What the API does through a connected PMS beyond reservation writes, read from the same connector table the router uses \u2014 a `false` flag is a `422 pms_write_unsupported` naming the PMS.",
+        "properties": {
+          "provider": {
+            "type": "string",
+            "example": "guesty"
+          },
+          "connected": {
+            "type": "boolean",
+            "description": "`false`: what the connector supports once connected (on a listing: a dead link \u2014 every write answers `409 no_connection`)."
+          },
+          "reservations": {
+            "type": "object",
+            "properties": {
+              "respond": {
+                "type": "boolean",
+                "description": "`POST /v1/reservations/{id}/accept|decline` on requests this PMS relays."
+              },
+              "preapprove": {
+                "type": "boolean",
+                "description": "`POST /v1/conversations/{id}/pre-approval` on inquiries this PMS relays."
+              }
+            }
+          },
+          "reviews": {
+            "type": "object",
+            "properties": {
+              "read": {
+                "type": "boolean",
+                "description": "Its reviews appear in `GET /v1/reviews` (with `pms` set)."
+              },
+              "reply": {
+                "type": "boolean",
+                "description": "`POST /v1/reviews/{id}/reply`."
+              }
+            }
+          },
+          "listings": {
+            "type": "object",
+            "description": "Sections `PUT /v1/listings/{id}/content` writes to the PMS.",
+            "properties": {
+              "title": {
+                "type": "boolean"
+              },
+              "descriptions": {
+                "type": "boolean"
+              },
+              "times": {
+                "type": "boolean"
+              },
+              "capacity": {
+                "type": "boolean"
+              },
+              "amenities": {
+                "type": "boolean"
+              },
+              "houseRules": {
+                "type": "boolean"
+              },
+              "address": {
+                "type": "boolean"
+              },
+              "photosAdd": {
+                "type": "boolean"
+              },
+              "photosDelete": {
+                "type": "boolean"
+              },
+              "photosReorder": {
+                "type": "boolean"
+              },
+              "photoCaptions": {
+                "type": "boolean"
+              }
+            }
+          },
+          "guests": {
+            "type": "object",
+            "properties": {
+              "create": {
+                "type": "boolean",
+                "description": "`POST /v1/guests` with `provider`."
+              },
+              "update": {
+                "type": "boolean",
+                "description": "`PATCH /v1/guests/{id}` on a guest linked to this PMS."
+              }
+            }
+          },
+          "conversations": {
+            "type": "object",
+            "properties": {
+              "send": {
+                "type": "boolean"
+              },
+              "attachments": {
+                "type": "boolean",
+                "description": "`attachments` on `POST /v1/conversations/{id}/messages`."
+              },
+              "channelSelect": {
+                "type": "boolean",
+                "description": "`channel` on `POST /v1/conversations/{id}/messages`."
+              }
+            }
+          },
+          "calendar": {
+            "type": "object",
+            "properties": {
+              "write": {
+                "type": "boolean",
+                "description": "`PUT /v1/availability/{propertyId}` reaches the PMS."
+              }
+            }
+          },
+          "payments": {
+            "type": "object",
+            "properties": {
+              "read": {
+                "type": "boolean",
+                "description": "Payments recorded in the PMS are imported onto the reservation."
+              }
+            }
+          },
+          "tasks": {
+            "type": "object",
+            "properties": {
+              "read": {
+                "type": "boolean"
+              },
+              "write": {
+                "type": "boolean"
+              }
+            }
+          },
+          "notes": {
+            "type": "object",
+            "additionalProperties": {
+              "type": "string"
+            },
+            "description": "The connector's own notes per family (limits, required access)."
+          }
+        }
+      },
       "GuestCreateRequest": {
         "type": "object",
         "required": [
@@ -11763,6 +11963,100 @@
           "isBusinessTraveler": {
             "type": "boolean",
             "default": false
+          },
+          "provider": {
+            "type": "string",
+            "example": "guesty",
+            "description": "A connected PMS to create the guest in as well. The guest is created there FIRST; a PMS that cannot create guest profiles returns `422 pms_write_unsupported` and nothing is created. The PMS's guest id comes back as `pms.externalId`, and later `PATCH /v1/guests/{id}` changes reach it."
+          }
+        }
+      },
+      "GuestUpdateRequest": {
+        "type": "object",
+        "minProperties": 1,
+        "properties": {
+          "firstName": {
+            "type": "string",
+            "minLength": 1
+          },
+          "lastName": {
+            "type": "string"
+          },
+          "email": {
+            "type": "string",
+            "format": "email",
+            "description": "Added as the guest's newest email; earlier ones are kept."
+          },
+          "phone": {
+            "type": "string",
+            "description": "E.164 preferred. Added as the guest's newest phone; earlier ones are kept."
+          },
+          "language": {
+            "type": "string",
+            "description": "BCP-47 tag."
+          }
+        }
+      },
+      "GuestUpdateResponse": {
+        "type": "object",
+        "properties": {
+          "id": {
+            "type": "integer"
+          },
+          "firstName": {
+            "type": "string"
+          },
+          "lastName": {
+            "type": "string",
+            "nullable": true
+          },
+          "language": {
+            "type": "string",
+            "nullable": true
+          },
+          "contacts": {
+            "type": "array",
+            "items": {
+              "type": "object",
+              "properties": {
+                "type": {
+                  "type": "string",
+                  "enum": [
+                    "email",
+                    "phone"
+                  ]
+                },
+                "value": {
+                  "type": "string"
+                },
+                "isPrimary": {
+                  "type": "boolean"
+                }
+              }
+            }
+          },
+          "updatedAt": {
+            "type": "string",
+            "format": "date-time",
+            "nullable": true
+          },
+          "pms": {
+            "type": "array",
+            "description": "Each PMS the change was written to first (the guest's linked PMSs), with the sections it applied.",
+            "items": {
+              "type": "object",
+              "properties": {
+                "provider": {
+                  "type": "string"
+                },
+                "applied": {
+                  "type": "array",
+                  "items": {
+                    "type": "string"
+                  }
+                }
+              }
+            }
           }
         }
       },
@@ -11821,6 +12115,20 @@
           "createdAt": {
             "type": "string",
             "format": "date-time"
+          },
+          "pms": {
+            "type": "object",
+            "nullable": true,
+            "description": "Set when `provider` was sent: the PMS the guest was also created in, and its id there.",
+            "properties": {
+              "provider": {
+                "type": "string"
+              },
+              "externalId": {
+                "type": "string",
+                "nullable": true
+              }
+            }
           }
         }
       },
@@ -11865,7 +12173,8 @@
           },
           "channel": {
             "type": "string",
-            "description": "Force a channel. Omit to send on whichever channel the conversation already uses, which is the right default."
+            "example": "email",
+            "description": "Force a channel. Omit to send on whichever channel the conversation already uses, which is the right default. One of `airbnb`, `booking`, `vrbo`, `sms`, `email`, `website` \u2014 except on a conversation a connected PMS relays (Guesty, Hostaway, \u2026), where the message is sent through the PMS and `channel` is passed to it: the PMS's own channel/module name (Guesty `airbnb2`, `bookingCom`, `email`, `sms`, \u2026) or one of Repull's names, which the PMS maps. A PMS that cannot choose a channel returns `422 pms_write_unsupported`; `GET /v1/connect/{provider}` \u2192 `capabilities.pms.conversations.channelSelect` says so beforehand."
           },
           "attachments": {
             "type": "array",
@@ -11874,7 +12183,7 @@
             "items": {
               "$ref": "#/components/schemas/SendMessageAttachment"
             },
-            "description": "Files to send. See the per-channel table above."
+            "description": "Files to send. See the per-channel table above. On a conversation a connected PMS relays, files go through the PMS \u2014 `422 pms_write_unsupported` when its API cannot send them (`capabilities.pms.conversations.attachments` on `GET /v1/connect/{provider}`)."
           }
         }
       },
@@ -14603,7 +14912,7 @@
       "post": {
         "operationId": "create_reservation",
         "summary": "Create a reservation",
-        "description": "Creates a reservation \u2014 in the listing's PMS when it has one, otherwise as a direct booking in Repull.\n\n### Where the booking is made\n\n- **A listing managed in a connected PMS** (Mews, Cloudbeds, Hostaway, Guesty, Beds24, BookingSync, Lodgify, Smoobu, Hospitable, iGMS, OwnerRez): the booking is created **in the PMS first**, then recorded in Repull from the PMS's own record, so the next sync lands on the same confirmation code and nothing is duplicated. A booking is **never** created only in Repull for such a listing \u2014 the PMS would keep selling the dates. What the PMS cannot do is refused (`422 pms_write_unsupported`), never faked. The PMS checks availability: taken dates answer `409 pms_unavailable`.\n- **Any other listing**: a direct booking made in Repull, with everything that hangs off one \u2014 the guest, the conversation, the calendar block and the `reservation.created` fan-out that issues the door code and starts the messaging automations. Priced by the listing's own rates; **availability is NOT checked** (call `GET /v1/availability/{propertyId}` first if that matters).\n\n`GET /v1/listings/{id}` \u2192 `capabilities.reservations` says which applies to a listing and exactly what it supports (`create`, `modify`, `cancel`, `quote`, `customPrice`, plus `notes`).\n\n### Fields by listing kind\n\n| Field | PMS listing | Direct-booking listing |\n|---|---|---|\n| `listingId`, `checkIn`, `checkOut`, `guest`, `guestCount`, `adults`, `children` | \u2713 | \u2713 |\n| `status` | `confirmed` (default) or `tentative` | \u2713 |\n| `totalPrice` | \u2713 where `capabilities.reservations.customPrice`; otherwise the PMS prices the stay | `422 unsupported_field` (priced from the listing's rates) |\n| `notes`, `unitId`, `sendConfirmationEmail` | \u2713 | `422 unsupported_field` |\n| `checkInTime`, `checkOutTime`, `currency`, `guestId` | `422 unsupported_field` (the PMS's own settings apply) | \u2713 |\n| `platform` | `direct` or `website` (`owner` \u2192 `422 pms_write_unsupported`; block owner stays in the PMS) | `direct`, `website` or `owner` |\n\nA field a listing cannot take is refused by name, never silently dropped. `platform` never accepts `airbnb` / `booking` / `vrbo`: those reservations are owned by the channel and arrive through sync.\n\n### Per-PMS limits\n\n| PMS | create | change | cancel | quote | `totalPrice` | Limits |\n|---|---|---|---|---|---|---|\n| Mews | \u2713 | \u2713 | \u2713 | \u2013 | \u2713 | \u2014 |\n| Cloudbeds | \u2713 | \u2713 | \u2713 | \u2013 | \u2013 | Books at the rate plan's price; group bookings supported. |\n| Hostaway | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Direct-channel bookings only; a specific unit is refused; a date change keeps the booked total. |\n| Guesty | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Cancels direct and Vrbo bookings; other channel bookings are cancelled on the channel. |\n| Beds24 | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Needs the `write:bookings` scope; a multi-room property needs `unitId`. |\n| BookingSync | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Needs `bookings_write`; fees and taxes are not itemized; no guest email. |\n| Lodgify | \u2713 | \u2713 | \u2713 (declines) | \u2713 | \u2713 | Cancel declines the booking; single-room bookings. |\n| Smoobu | \u2713 | \u2713 (no dates) | \u2713 | \u2713 | \u2713 | Dates cannot be changed through Smoobu's API \u2014 cancel and rebook, or change them in Smoobu. |\n| Hospitable | \u2713 | \u2713 | \u2713 | \u2713 (Direct plan) | \u2713 | Manual reservations only; needs `reservation:write`; adds no fees or taxes. |\n| iGMS | \u2713 | \u2713 | \u2713 | \u2013 | \u2713 (required) | iGMS direct bookings only; a price is required; no tentative holds. |\n| OwnerRez | \u2713 | \u2713 | \u2013 | \u2713 | \u2013 | No cancel through OwnerRez's API; priced by the property's own rates; needs the `full` scope. |\n\nEvery PMS except Cloudbeds refuses group bookings, and every vacation-rental PMS refuses to change or cancel a booking that came from a channel (Airbnb, Booking.com, Vrbo\u2026) \u2014 that is done on the channel.\n\n**Verification.** Mews and Cloudbeds were run end to end on their vendors' sandboxes. Every other PMS is **verified against the vendor's API documentation only** \u2014 no live account has been written to yet. `capabilities.reservations.verifiedAgainst` says which.\n\n### Idempotency\n\n**Send `Idempotency-Key`.** A network timeout here is exactly the case it exists for. The key is also sent to the PMS as the booking's reference, so even a retry that reaches the PMS again finds the booking instead of making a second one (`409 pms_duplicate` with `existing`, or the existing booking returned). A completed answer is replayed with `Idempotency-Status: cached` and the PMS is not called again. `502 pms_error` (the PMS could not be reached) is NOT stored \u2014 retry with the same key. `502 reservation_created_in_pms_only` IS stored, unlike every other 5xx: the booking exists in the PMS and arrives with the next sync, so a retry replays that answer rather than booking twice.\n\n### Partial success\n\nWhen the PMS created the booking but a follow-up step did not apply (for example the notes, or a tentative state), the response is still `201`, with `pms.partial: true` and the steps in `pms.failedSections`. The booking exists \u2014 do not create it again.\n\n`X-Account-Id` restricts the listing to one connected account. Returns `403 listing_inactive` when the listing is inactive.",
+        "description": "Creates a reservation \u2014 in the listing's PMS when it has one, otherwise as a direct booking in Repull.\n\n### Where the booking is made\n\n- **A listing managed in a connected PMS** (Mews, Cloudbeds, Hostaway, Guesty, Beds24, BookingSync, Lodgify, Smoobu, Hospitable, iGMS, OwnerRez, Track): the booking is created **in the PMS first**, then recorded in Repull from the PMS's own record, so the next sync lands on the same confirmation code and nothing is duplicated. A booking is **never** created only in Repull for such a listing \u2014 the PMS would keep selling the dates. What the PMS cannot do is refused (`422 pms_write_unsupported`), never faked. The PMS checks availability: taken dates answer `409 pms_unavailable`.\n- **Any other listing**: a direct booking made in Repull, with everything that hangs off one \u2014 the guest, the conversation, the calendar block and the `reservation.created` fan-out that issues the door code and starts the messaging automations. Priced by the listing's own rates; **availability is NOT checked** (call `GET /v1/availability/{propertyId}` first if that matters).\n\n`GET /v1/listings/{id}` \u2192 `capabilities.reservations` says which applies to a listing and exactly what it supports (`create`, `modify`, `cancel`, `quote`, `customPrice`, plus `notes`).\n\n### Fields by listing kind\n\n| Field | PMS listing | Direct-booking listing |\n|---|---|---|\n| `listingId`, `checkIn`, `checkOut`, `guest`, `guestCount`, `adults`, `children` | \u2713 | \u2713 |\n| `status` | `confirmed` (default) or `tentative` | \u2713 |\n| `totalPrice` | \u2713 where `capabilities.reservations.customPrice`; otherwise the PMS prices the stay | `422 unsupported_field` (priced from the listing's rates) |\n| `notes`, `unitId`, `sendConfirmationEmail` | \u2713 | `422 unsupported_field` |\n| `checkInTime`, `checkOutTime`, `currency`, `guestId` | `422 unsupported_field` (the PMS's own settings apply) | \u2713 |\n| `platform` | `direct` or `website` (`owner` \u2192 `422 pms_write_unsupported`; block owner stays in the PMS) | `direct`, `website` or `owner` |\n\nA field a listing cannot take is refused by name, never silently dropped. `platform` never accepts `airbnb` / `booking` / `vrbo`: those reservations are owned by the channel and arrive through sync.\n\n### Per-PMS limits\n\n| PMS | create | change | cancel | quote | `totalPrice` | Limits |\n|---|---|---|---|---|---|---|\n| Mews | \u2713 | \u2713 | \u2713 | \u2013 | \u2713 | \u2014 |\n| Cloudbeds | \u2713 | \u2713 | \u2713 | \u2013 | \u2013 | Books at the rate plan's price; group bookings supported. |\n| Hostaway | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Direct-channel bookings only; a specific unit is refused; a date change keeps the booked total. |\n| Guesty | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Cancels direct and Vrbo bookings; other channel bookings are cancelled on the channel. |\n| Beds24 | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Needs the `write:bookings` scope; a multi-room property needs `unitId`. |\n| BookingSync | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Needs `bookings_write`; fees and taxes are not itemized; no guest email. |\n| Lodgify | \u2713 | \u2713 | \u2713 (declines) | \u2713 | \u2713 | Cancel declines the booking; single-room bookings. |\n| Smoobu | \u2713 | \u2713 (no dates) | \u2713 | \u2713 | \u2713 | Dates cannot be changed through Smoobu's API \u2014 cancel and rebook, or change them in Smoobu. |\n| Hospitable | \u2713 | \u2713 | \u2713 | \u2713 (Direct plan) | \u2713 | Manual reservations only; needs `reservation:write`; adds no fees or taxes. |\n| iGMS | \u2713 | \u2713 | \u2713 | \u2013 | \u2713 (required) | iGMS direct bookings only; a price is required; no tentative holds. |\n| OwnerRez | \u2713 | \u2713 | \u2013 | \u2713 | \u2013 | No cancel through OwnerRez's API; priced by the property's own rates; needs the `full` scope. |\n| Track | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Track decides Hold vs Confirmed from the property's channel mode; a set price on a Channel Key needs \"Allow Custom Pricing\"; a unit change needs `moveReasonId` on the connection; a date change re-prices at Track's current rates. |\n\nEvery PMS except Cloudbeds refuses group bookings, and every vacation-rental PMS refuses to change or cancel a booking that came from a channel (Airbnb, Booking.com, Vrbo\u2026) \u2014 that is done on the channel.\n\n**Verification.** Mews and Cloudbeds were run end to end on their vendors' sandboxes. Every other PMS is **verified against the vendor's API documentation only** \u2014 no live account has been written to yet. `capabilities.reservations.verifiedAgainst` says which.\n\n### Idempotency\n\n**Send `Idempotency-Key`.** A network timeout here is exactly the case it exists for. The key is also sent to the PMS as the booking's reference, so even a retry that reaches the PMS again finds the booking instead of making a second one (`409 pms_duplicate` with `existing`, or the existing booking returned). A completed answer is replayed with `Idempotency-Status: cached` and the PMS is not called again. `502 pms_error` (the PMS could not be reached) is NOT stored \u2014 retry with the same key. `502 reservation_created_in_pms_only` IS stored, unlike every other 5xx: the booking exists in the PMS and arrives with the next sync, so a retry replays that answer rather than booking twice.\n\n### Partial success\n\nWhen the PMS created the booking but a follow-up step did not apply (for example the notes, or a tentative state), the response is still `201`, with `pms.partial: true` and the steps in `pms.failedSections`. The booking exists \u2014 do not create it again.\n\n`X-Account-Id` restricts the listing to one connected account. Returns `403 listing_inactive` when the listing is inactive.",
         "tags": [
           "Reservations"
         ],
@@ -15524,7 +15833,7 @@
       "post": {
         "operationId": "createGuest",
         "summary": "Create a guest",
-        "description": "Creates a guest in the workspace, with contact normalisation applied (phone digits, email lowercased) and each contact stored as its own record.\n\n**This is find-or-create, and the response tells you which happened.** A guest already on file matching on email \u2014 then phone \u2014 AND name is returned instead of a duplicate being created. Read the `created` flag rather than inferring from the status: `201` with `created: true` means a new record was written, `200` with `created: false` means an existing guest matched. Quietly handing back an existing record as though it were new is exactly the ambiguity this flag removes.\n\nField names are camelCase, and an unrecognised field is rejected by name rather than silently dropped.\n\nSend `Idempotency-Key` to make a retry safe.",
+        "description": "Creates a guest in the workspace, with contact normalisation applied (phone digits, email lowercased) and each contact stored as its own record.\n\n**This is find-or-create, and the response tells you which happened.** A guest already on file matching on email \u2014 then phone \u2014 AND name is returned instead of a duplicate being created. Read the `created` flag rather than inferring from the status: `201` with `created: true` means a new record was written, `200` with `created: false` means an existing guest matched. Quietly handing back an existing record as though it were new is exactly the ambiguity this flag removes.\n\nField names are camelCase, and an unrecognised field is rejected by name rather than silently dropped.\n\n**Creating the guest in a connected PMS too:** send `provider` (e.g. `guesty`). The guest is created in the PMS first and its id there comes back as `pms.externalId`; a PMS whose API cannot create guest profiles returns `422 pms_write_unsupported` naming it (Hostaway today) and nothing is created. `GET /v1/connect/{provider}` \u2192 `capabilities.pms.guests.create` says so beforehand.\n\nSend `Idempotency-Key` to make a retry safe.",
         "tags": [
           "Guests"
         ],
@@ -15648,6 +15957,61 @@
             "$ref": "#/components/responses/InternalError"
           }
         }
+      },
+      "patch": {
+        "operationId": "updateGuest",
+        "summary": "Update a guest",
+        "description": "Change a guest's name, email, phone or language. Email and phone are added as the guest's newest contact; earlier ones are kept.\n\n**Guests linked to a connected PMS** (created with `provider`, or imported from one) are changed in that PMS first. A PMS whose API cannot change guest profiles returns `422 pms_write_unsupported` naming it (Hostaway today) and nothing is written; `GET /v1/connect/{provider}` \u2192 `capabilities.pms.guests.update` says so beforehand. A revoked PMS connection is `403 connection_reauth_required`.\n\nSend `Idempotency-Key` to make a retry safe.",
+        "tags": [
+          "Guests"
+        ],
+        "parameters": [
+          {
+            "name": "id",
+            "in": "path",
+            "required": true,
+            "schema": {
+              "type": "integer"
+            }
+          },
+          {
+            "$ref": "#/components/parameters/IdempotencyKey"
+          }
+        ],
+        "requestBody": {
+          "required": true,
+          "content": {
+            "application/json": {
+              "schema": {
+                "$ref": "#/components/schemas/GuestUpdateRequest"
+              }
+            }
+          }
+        },
+        "responses": {
+          "200": {
+            "description": "Guest updated (and in its PMS, when linked to one).",
+            "content": {
+              "application/json": {
+                "schema": {
+                  "$ref": "#/components/schemas/GuestUpdateResponse"
+                }
+              }
+            }
+          },
+          "401": {
+            "$ref": "#/components/responses/Unauthorized"
+          },
+          "403": {
+            "$ref": "#/components/responses/ListingInactive"
+          },
+          "404": {
+            "$ref": "#/components/responses/NotFound"
+          },
+          "422": {
+            "$ref": "#/components/responses/UnprocessableEntity"
+          }
+        }
       }
     },
     "/v1/conversations": {
@@ -17956,7 +18320,7 @@
       "post": {
         "operationId": "replyToReview",
         "summary": "Reply to a review on any channel",
-        "description": "Resolves the review, reads its channel and dispatches the reply. Channel-neutral: you do not need to know where the review came from.\n\nReplies work on Airbnb, Booking.com and VRBO. Each channel accepts one reply per review (VRBO: a second is `409 already_replied`; a review VRBO no longer takes a response to is `409 reply_not_allowed`). On VRBO the response is signed with a name \u2014 the connected account's host name, or `name` if you send it. A review from a channel without a reply API returns `422 unsupported_channel` naming the channels that do work.\n\nTo review a guest (Airbnb only), use `POST /v1/reviews/{id}/guest-review`.\n\n**Inactive listings:** a review of an inactive listing returns `403 listing_inactive` and no reply reaches the channel. Activate the listing first.",
+        "description": "Resolves the review, reads its channel and dispatches the reply. Channel-neutral: you do not need to know where the review came from.\n\nReplies work on Airbnb, Booking.com and VRBO. Each channel accepts one reply per review (VRBO: a second is `409 already_replied`; a review VRBO no longer takes a response to is `409 reply_not_allowed`). On VRBO the response is signed with a name \u2014 the connected account's host name, or `name` if you send it. A review from a channel without a reply API returns `422 unsupported_channel` naming the channels that do work.\n\n**Reviews read from a PMS** (`pms` set on the review \u2014 Guesty, Hostaway, \u2026) are answered through that PMS. A PMS whose API has no reply returns `422 pms_write_unsupported` naming it (Hostaway today); `GET /v1/connect/{provider}` \u2192 `capabilities.pms.reviews.reply` says so beforehand. A revoked PMS connection is `403 connection_reauth_required`.\n\nTo review a guest (Airbnb only), use `POST /v1/reviews/{id}/guest-review`.\n\n**Inactive listings:** a review of an inactive listing returns `403 listing_inactive` and no reply reaches the channel. Activate the listing first.",
         "tags": [
           "Reviews"
         ],
@@ -18009,6 +18373,11 @@
                     "platform": {
                       "type": "string"
                     },
+                    "pms": {
+                      "type": "string",
+                      "nullable": true,
+                      "description": "The PMS the reply went through, when the review came from one."
+                    },
                     "response": {
                       "type": "string"
                     }
@@ -23697,7 +24066,7 @@
       "put": {
         "operationId": "updateListingContent",
         "summary": "Update canonical listing content",
-        "description": "Write your PMS's canonical listing content \u2014 title, description, amenities, address, occupancy, and policies \u2014 into a Repull listing, making it the source of truth. This is the flagship \"the PMS owns listing content, Repull distributes it\" enabler.\n\n**Partial update:** every field is optional. Only the fields you send are written; absent fields are left untouched. `amenities` is a FULL replacement of the amenity set (omit to leave untouched, send `[]` to clear).\n\n**Multilingual:** send `locale` to say which language this copy is in (`it`, `pt-BR`, \u2026). Canonical content is stored per locale, so each language keeps its own row instead of overwriting the English one. Omit it for English.\n\n**Local write only \u2014 NOT a channel publish.** This mutates Repull's own copy of the content. It does NOT push to Airbnb / Booking.com; it marks the channels dirty so a later publish knows what changed. Distribution stays a separate explicit step.\n\n**Photos are deferred:** a provided `photos` array is echoed back in the `deferred` field and NOT persisted (media ingestion is a follow-up).\n\nCross-tenant access (a listing that belongs to a different workspace) returns 404 \u2014 never 403. This endpoint is served even when the account is over the plan-listings cap, since editing content on a listing you already own never grows the portfolio.\n\nReturns `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.",
+        "description": "Write your PMS's canonical listing content \u2014 title, description, amenities, address, occupancy, and policies \u2014 into a Repull listing, making it the source of truth. This is the flagship \"the PMS owns listing content, Repull distributes it\" enabler.\n\n**Listings managed in a connected PMS** (Guesty, Hostaway, \u2026): the PMS owns their content, so title, descriptions, check-in/out times, capacity, amenities, house rules, address and added photos are written to the PMS first; Repull keeps only what it accepted (refused sections are in `deferred`, its per-section outcome in `pms`). A section that PMS cannot write returns `422 pms_write_unsupported` naming it when nothing was applied (or is listed in `deferred` when other sections were); `GET /v1/listings/{id}` \u2192 `capabilities.pms.listings` says which sections it takes. A PMS whose connector writes no listing content at all (Mews, Cloudbeds, Lodgify, \u2026) keeps today's behaviour: the content is written to Repull only. Send photos with `photosMode: \"append\"` \u2014 replacing a PMS listing's photo set needs the PMS's own photo ids. A revoked PMS connection is `403 connection_reauth_required`.\n\n**Partial update:** every field is optional. Only the fields you send are written; absent fields are left untouched. `amenities` is a FULL replacement of the amenity set (omit to leave untouched, send `[]` to clear).\n\n**Multilingual:** send `locale` to say which language this copy is in (`it`, `pt-BR`, \u2026). Canonical content is stored per locale, so each language keeps its own row instead of overwriting the English one. Omit it for English.\n\n**Local write only \u2014 NOT a channel publish.** This mutates Repull's own copy of the content. It does NOT push to Airbnb / Booking.com; it marks the channels dirty so a later publish knows what changed. Distribution stays a separate explicit step.\n\n**Photos are deferred:** a provided `photos` array is echoed back in the `deferred` field and NOT persisted (media ingestion is a follow-up).\n\nCross-tenant access (a listing that belongs to a different workspace) returns 404 \u2014 never 403. This endpoint is served even when the account is over the plan-listings cap, since editing content on a listing you already own never grows the portfolio.\n\nReturns `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.",
         "tags": [
           "Listings"
         ],
@@ -29194,7 +29563,7 @@
       "post": {
         "operationId": "preapprove_conversation",
         "summary": "Pre-approve an inquiry (Airbnb, VRBO)",
-        "description": "Pre-approve the inquiry on this conversation: the guest who asked about dates may now book them at the listed price, without waiting on you. To change the dates, guests or price, send a special offer instead (`POST /v1/conversations/{id}/special-offers`).\n\nFind inquiries that need an answer with `GET /v1/inquiries` (default `status=open`); each carries the `conversationId` to use here.\n\nOne endpoint for every channel with pre-approvals: **Airbnb** (listings connected directly) and **VRBO**. A Booking.com or direct-booking conversation, or an Airbnb one relayed through a PMS (Hostaway, Guesty), returns `422 channel_not_supported` and nothing is sent \u2014 `GET /v1/conversations/{id}` \u2192 `capabilities.canPreApprove` says where it works.\n\n`blockInstantBooking` is Airbnb only (VRBO has no such switch: `422 invalid_params`). `message` is sent to the guest with a VRBO pre-approval (a friendly default otherwise).\n\nThe inquiry is marked `pre_approved` everywhere, the same as pre-approving on the channel. Withdraw it with `DELETE /v1/conversations/{id}/pre-approval` (VRBO).\n\nA channel\u2019s refusal is never reported as a success: an inquiry that already moved on is `409 inquiry_no_longer_open`, an expired one `409 inquiry_expired`, a conversation that already has a booking `409 conversation_already_booked`.\n\nSend `Idempotency-Key`: a repeat with the same key replays the first response instead of acting twice (a `409 idempotency_key_in_use` while the first is still running). A 5xx, a `429 airbnb_rate_limited` or a `403 connection_reauth_required` is not stored \u2014 nothing was done \u2014 so retrying with the same key reaches Airbnb again.",
+        "description": "Pre-approve the inquiry on this conversation: the guest who asked about dates may now book them at the listed price, without waiting on you. To change the dates, guests or price, send a special offer instead (`POST /v1/conversations/{id}/special-offers`).\n\nFind inquiries that need an answer with `GET /v1/inquiries` (default `status=open`); each carries the `conversationId` to use here.\n\nOne endpoint for every channel with pre-approvals: **Airbnb** (listings connected directly) and **VRBO**. A Booking.com or direct-booking conversation returns `422 channel_not_supported` and nothing is sent \u2014 `GET /v1/conversations/{id}` \u2192 `capabilities.canPreApprove` says where it works.\n\n**An inquiry relayed by a PMS** (Guesty, Hostaway, \u2026) is pre-approved in that PMS. A PMS whose API cannot returns `422 pms_write_unsupported` naming it (Hostaway today); `GET /v1/connect/{provider}` \u2192 `capabilities.pms.reservations.preapprove` says so beforehand. The response then carries `pms`.\n\n`blockInstantBooking` is Airbnb only (VRBO has no such switch: `422 invalid_params`). `message` is sent to the guest with a VRBO pre-approval (a friendly default otherwise).\n\nThe inquiry is marked `pre_approved` everywhere, the same as pre-approving on the channel. Withdraw it with `DELETE /v1/conversations/{id}/pre-approval` (VRBO).\n\nA channel\u2019s refusal is never reported as a success: an inquiry that already moved on is `409 inquiry_no_longer_open`, an expired one `409 inquiry_expired`, a conversation that already has a booking `409 conversation_already_booked`.\n\nSend `Idempotency-Key`: a repeat with the same key replays the first response instead of acting twice (a `409 idempotency_key_in_use` while the first is still running). A 5xx, a `429 airbnb_rate_limited` or a `403 connection_reauth_required` is not stored \u2014 nothing was done \u2014 so retrying with the same key reaches Airbnb again.",
         "tags": [
           "Conversations"
         ],
@@ -29450,7 +29819,7 @@
                       "error": {
                         "code": "channel_not_supported",
                         "message": "Reservation 233530 came from Booking.com. Booking requests can only be accepted or declined on Airbnb \u2014 other channels confirm instantly or have no request step.",
-                        "fix": "Pre-approvals and special offers work on Airbnb (connected directly, not through a PMS such as Hostaway or Guesty) and VRBO; accepting/declining booking requests on Airbnb. `GET /v1/conversations/{id}` \u2192 `capabilities` says what works on a conversation. Booking.com and direct bookings confirm without a request step.",
+                        "fix": "Pre-approvals and special offers work on Airbnb (connected directly) and VRBO; accepting/declining booking requests on Airbnb. Requests and inquiries relayed by a PMS are answered in that PMS (`pms_write_unsupported` when its API cannot). `GET /v1/conversations/{id}` \u2192 `capabilities` says what works on a conversation. Booking.com and direct bookings confirm without a request step.",
                         "docs_url": "https://repull.dev/docs/channels/airbnb/inquiries-and-requests",
                         "request_id": "req_01J5X7Y8Z9ABCDEF12345678",
                         "channel": "booking"
@@ -29694,7 +30063,7 @@
                       "error": {
                         "code": "channel_not_supported",
                         "message": "Reservation 233530 came from Booking.com. Booking requests can only be accepted or declined on Airbnb \u2014 other channels confirm instantly or have no request step.",
-                        "fix": "Pre-approvals and special offers work on Airbnb (connected directly, not through a PMS such as Hostaway or Guesty) and VRBO; accepting/declining booking requests on Airbnb. `GET /v1/conversations/{id}` \u2192 `capabilities` says what works on a conversation. Booking.com and direct bookings confirm without a request step.",
+                        "fix": "Pre-approvals and special offers work on Airbnb (connected directly) and VRBO; accepting/declining booking requests on Airbnb. Requests and inquiries relayed by a PMS are answered in that PMS (`pms_write_unsupported` when its API cannot). `GET /v1/conversations/{id}` \u2192 `capabilities` says what works on a conversation. Booking.com and direct bookings confirm without a request step.",
                         "docs_url": "https://repull.dev/docs/channels/airbnb/inquiries-and-requests",
                         "request_id": "req_01J5X7Y8Z9ABCDEF12345678",
                         "channel": "booking"
@@ -30403,7 +30772,7 @@
                       "error": {
                         "code": "channel_not_supported",
                         "message": "Reservation 233530 came from Booking.com. Booking requests can only be accepted or declined on Airbnb \u2014 other channels confirm instantly or have no request step.",
-                        "fix": "Pre-approvals and special offers work on Airbnb (connected directly, not through a PMS such as Hostaway or Guesty) and VRBO; accepting/declining booking requests on Airbnb. `GET /v1/conversations/{id}` \u2192 `capabilities` says what works on a conversation. Booking.com and direct bookings confirm without a request step.",
+                        "fix": "Pre-approvals and special offers work on Airbnb (connected directly) and VRBO; accepting/declining booking requests on Airbnb. Requests and inquiries relayed by a PMS are answered in that PMS (`pms_write_unsupported` when its API cannot). `GET /v1/conversations/{id}` \u2192 `capabilities` says what works on a conversation. Booking.com and direct bookings confirm without a request step.",
                         "docs_url": "https://repull.dev/docs/channels/airbnb/inquiries-and-requests",
                         "request_id": "req_01J5X7Y8Z9ABCDEF12345678",
                         "channel": "booking"
@@ -30829,7 +31198,7 @@
                       "error": {
                         "code": "channel_not_supported",
                         "message": "Reservation 233530 came from Booking.com. Booking requests can only be accepted or declined on Airbnb \u2014 other channels confirm instantly or have no request step.",
-                        "fix": "Pre-approvals and special offers work on Airbnb (connected directly, not through a PMS such as Hostaway or Guesty) and VRBO; accepting/declining booking requests on Airbnb. `GET /v1/conversations/{id}` \u2192 `capabilities` says what works on a conversation. Booking.com and direct bookings confirm without a request step.",
+                        "fix": "Pre-approvals and special offers work on Airbnb (connected directly) and VRBO; accepting/declining booking requests on Airbnb. Requests and inquiries relayed by a PMS are answered in that PMS (`pms_write_unsupported` when its API cannot). `GET /v1/conversations/{id}` \u2192 `capabilities` says what works on a conversation. Booking.com and direct bookings confirm without a request step.",
                         "docs_url": "https://repull.dev/docs/channels/airbnb/inquiries-and-requests",
                         "request_id": "req_01J5X7Y8Z9ABCDEF12345678",
                         "channel": "booking"
@@ -31114,7 +31483,7 @@
                       "error": {
                         "code": "channel_not_supported",
                         "message": "Reservation 233530 came from Booking.com. Booking requests can only be accepted or declined on Airbnb \u2014 other channels confirm instantly or have no request step.",
-                        "fix": "Pre-approvals and special offers work on Airbnb (connected directly, not through a PMS such as Hostaway or Guesty) and VRBO; accepting/declining booking requests on Airbnb. `GET /v1/conversations/{id}` \u2192 `capabilities` says what works on a conversation. Booking.com and direct bookings confirm without a request step.",
+                        "fix": "Pre-approvals and special offers work on Airbnb (connected directly) and VRBO; accepting/declining booking requests on Airbnb. Requests and inquiries relayed by a PMS are answered in that PMS (`pms_write_unsupported` when its API cannot). `GET /v1/conversations/{id}` \u2192 `capabilities` says what works on a conversation. Booking.com and direct bookings confirm without a request step.",
                         "docs_url": "https://repull.dev/docs/channels/airbnb/inquiries-and-requests",
                         "request_id": "req_01J5X7Y8Z9ABCDEF12345678",
                         "channel": "booking"
@@ -31453,7 +31822,7 @@
       "post": {
         "operationId": "accept_reservation_request",
         "summary": "Accept a booking request",
-        "description": "Accept a pending Airbnb booking request \u2014 a reservation with status `pending`, made on a listing without Instant Book. Find them with `GET /v1/reservations?status=pending`. Airbnb expires a request the host has not answered within 24 hours.\n\nAirbnb confirms asynchronously: the reservation\u2019s status moves to confirmed, and a `reservation.updated` webhook fires, when Airbnb\u2019s notification lands (usually within seconds). The response reports what Airbnb was asked to do.\n\n**Airbnb only**, and only for listings connected to Airbnb directly: other channels have no request step (`422 channel_not_supported`). A reservation that is not pending is refused before Airbnb is contacted (`409 reservation_not_pending`); one Airbnb says already moved on is `409 request_no_longer_pending`. Neither is worth retrying.\n\nTakes no body.\n\nSend `Idempotency-Key`: a repeat with the same key replays the first response instead of acting twice (a `409 idempotency_key_in_use` while the first is still running). A 5xx, a `429 airbnb_rate_limited` or a `403 connection_reauth_required` is not stored \u2014 nothing was done \u2014 so retrying with the same key reaches Airbnb again.",
+        "description": "Accept a pending Airbnb booking request \u2014 a reservation with status `pending`, made on a listing without Instant Book. Find them with `GET /v1/reservations?status=pending`. Airbnb expires a request the host has not answered within 24 hours.\n\nAirbnb confirms asynchronously: the reservation\u2019s status moves to confirmed, and a `reservation.updated` webhook fires, when Airbnb\u2019s notification lands (usually within seconds). The response reports what Airbnb was asked to do.\n\n**Airbnb**, for listings connected to Airbnb directly; other channels have no request step (`422 channel_not_supported`). **A request relayed by a PMS** (Guesty, Hostaway, \u2026) is answered in that PMS, whatever channel it came from; a PMS whose API cannot answer requests returns `422 pms_write_unsupported` naming it (Hostaway today), and `GET /v1/connect/{provider}` \u2192 `capabilities.pms.reservations.respond` says so beforehand. The response then carries `pms`. A reservation that is not pending is refused before Airbnb is contacted (`409 reservation_not_pending`); one Airbnb says already moved on is `409 request_no_longer_pending`. Neither is worth retrying.\n\nTakes no body.\n\nSend `Idempotency-Key`: a repeat with the same key replays the first response instead of acting twice (a `409 idempotency_key_in_use` while the first is still running). A 5xx, a `429 airbnb_rate_limited` or a `403 connection_reauth_required` is not stored \u2014 nothing was done \u2014 so retrying with the same key reaches Airbnb again.",
         "tags": [
           "Reservations"
         ],
@@ -31684,7 +32053,7 @@
                       "error": {
                         "code": "channel_not_supported",
                         "message": "Reservation 233530 came from Booking.com. Booking requests can only be accepted or declined on Airbnb \u2014 other channels confirm instantly or have no request step.",
-                        "fix": "Pre-approvals and special offers work on Airbnb (connected directly, not through a PMS such as Hostaway or Guesty) and VRBO; accepting/declining booking requests on Airbnb. `GET /v1/conversations/{id}` \u2192 `capabilities` says what works on a conversation. Booking.com and direct bookings confirm without a request step.",
+                        "fix": "Pre-approvals and special offers work on Airbnb (connected directly) and VRBO; accepting/declining booking requests on Airbnb. Requests and inquiries relayed by a PMS are answered in that PMS (`pms_write_unsupported` when its API cannot). `GET /v1/conversations/{id}` \u2192 `capabilities` says what works on a conversation. Booking.com and direct bookings confirm without a request step.",
                         "docs_url": "https://repull.dev/docs/channels/airbnb/inquiries-and-requests",
                         "request_id": "req_01J5X7Y8Z9ABCDEF12345678",
                         "channel": "booking"
@@ -31692,16 +32061,15 @@
                     }
                   },
                   "viaPms": {
-                    "summary": "An Airbnb booking relayed through a PMS",
+                    "summary": "A booking relayed by a PMS whose API cannot answer requests",
                     "value": {
                       "error": {
-                        "code": "channel_not_supported",
-                        "message": "Reservation 233530 reaches Airbnb through guesty, not a direct Airbnb connection. Accept it in guesty.",
-                        "fix": "Pre-approvals, special offers and accepting/declining requests exist only on Airbnb, and only for listings connected to Airbnb directly (not through a PMS such as Hostaway or Guesty).",
+                        "code": "pms_write_unsupported",
+                        "message": "Hostaway's API cannot accept or decline booking requests.",
+                        "fix": "Do it in Hostaway; the change reaches Repull with the next sync. `GET /v1/connect/hostaway` \u2192 `capabilities.pms` lists what Hostaway supports.",
                         "docs_url": "https://repull.dev/docs/channels/airbnb/inquiries-and-requests",
                         "request_id": "req_01J5X7Y8Z9ABCDEF12345678",
-                        "channel": "airbnb",
-                        "pms": "guesty"
+                        "provider": "hostaway"
                       }
                     }
                   },
@@ -32120,7 +32488,7 @@
                       "error": {
                         "code": "channel_not_supported",
                         "message": "Reservation 233530 came from Booking.com. Booking requests can only be accepted or declined on Airbnb \u2014 other channels confirm instantly or have no request step.",
-                        "fix": "Pre-approvals and special offers work on Airbnb (connected directly, not through a PMS such as Hostaway or Guesty) and VRBO; accepting/declining booking requests on Airbnb. `GET /v1/conversations/{id}` \u2192 `capabilities` says what works on a conversation. Booking.com and direct bookings confirm without a request step.",
+                        "fix": "Pre-approvals and special offers work on Airbnb (connected directly) and VRBO; accepting/declining booking requests on Airbnb. Requests and inquiries relayed by a PMS are answered in that PMS (`pms_write_unsupported` when its API cannot). `GET /v1/conversations/{id}` \u2192 `capabilities` says what works on a conversation. Booking.com and direct bookings confirm without a request step.",
                         "docs_url": "https://repull.dev/docs/channels/airbnb/inquiries-and-requests",
                         "request_id": "req_01J5X7Y8Z9ABCDEF12345678",
                         "channel": "booking"
@@ -34308,7 +34676,7 @@
                       "error": {
                         "code": "channel_not_supported",
                         "message": "Reservation 233530 came from Booking.com. Booking requests can only be accepted or declined on Airbnb \u2014 other channels confirm instantly or have no request step.",
-                        "fix": "Pre-approvals and special offers work on Airbnb (connected directly, not through a PMS such as Hostaway or Guesty) and VRBO; accepting/declining booking requests on Airbnb. `GET /v1/conversations/{id}` \u2192 `capabilities` says what works on a conversation. Booking.com and direct bookings confirm without a request step.",
+                        "fix": "Pre-approvals and special offers work on Airbnb (connected directly) and VRBO; accepting/declining booking requests on Airbnb. Requests and inquiries relayed by a PMS are answered in that PMS (`pms_write_unsupported` when its API cannot). `GET /v1/conversations/{id}` \u2192 `capabilities` says what works on a conversation. Booking.com and direct bookings confirm without a request step.",
                         "docs_url": "https://repull.dev/docs/channels/airbnb/inquiries-and-requests",
                         "request_id": "req_01J5X7Y8Z9ABCDEF12345678",
                         "channel": "booking"
@@ -35656,7 +36024,7 @@
       "post": {
         "operationId": "quote_reservation",
         "summary": "Quote a reservation in the PMS",
-        "description": "Prices a stay and checks its availability **in the PMS that manages the listing**, without booking anything. It is the same check `POST /v1/reservations` makes before booking when no `totalPrice` is sent, so `available: true` with a `total` is what that create would be priced at (dates can still be taken in between).\n\n`available: false` is an answer, not an error: the PMS's reasons are in `restrictions` (minimum stay, closed to arrival, taken dates\u2026).\n\n- A listing **not managed in a PMS** answers `422 pms_not_linked`. Book it directly with `POST /v1/reservations`, or price it with `GET /v1/quotes`.\n- A PMS **without a quote API** (Mews, Cloudbeds, iGMS) answers `422 pms_write_unsupported`. You can still create the booking; on iGMS a `totalPrice` is required.\n\n`GET /v1/listings/{id}` \u2192 `capabilities.reservations.quote` says whether a listing can be quoted.\n\n### Per-PMS limits\n\n| PMS | create | change | cancel | quote | `totalPrice` | Limits |\n|---|---|---|---|---|---|---|\n| Mews | \u2713 | \u2713 | \u2713 | \u2013 | \u2713 | \u2014 |\n| Cloudbeds | \u2713 | \u2713 | \u2713 | \u2013 | \u2013 | Books at the rate plan's price; group bookings supported. |\n| Hostaway | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Direct-channel bookings only; a specific unit is refused; a date change keeps the booked total. |\n| Guesty | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Cancels direct and Vrbo bookings; other channel bookings are cancelled on the channel. |\n| Beds24 | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Needs the `write:bookings` scope; a multi-room property needs `unitId`. |\n| BookingSync | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Needs `bookings_write`; fees and taxes are not itemized; no guest email. |\n| Lodgify | \u2713 | \u2713 | \u2713 (declines) | \u2713 | \u2713 | Cancel declines the booking; single-room bookings. |\n| Smoobu | \u2713 | \u2713 (no dates) | \u2713 | \u2713 | \u2713 | Dates cannot be changed through Smoobu's API \u2014 cancel and rebook, or change them in Smoobu. |\n| Hospitable | \u2713 | \u2713 | \u2713 | \u2713 (Direct plan) | \u2713 | Manual reservations only; needs `reservation:write`; adds no fees or taxes. |\n| iGMS | \u2713 | \u2713 | \u2713 | \u2013 | \u2713 (required) | iGMS direct bookings only; a price is required; no tentative holds. |\n| OwnerRez | \u2713 | \u2713 | \u2013 | \u2713 | \u2013 | No cancel through OwnerRez's API; priced by the property's own rates; needs the `full` scope. |\n\nEvery PMS except Cloudbeds refuses group bookings, and every vacation-rental PMS refuses to change or cancel a booking that came from a channel (Airbnb, Booking.com, Vrbo\u2026) \u2014 that is done on the channel.\n\n**Verification.** Mews and Cloudbeds were run end to end on their vendors' sandboxes. Every other PMS is **verified against the vendor's API documentation only** \u2014 no live account has been written to yet. `capabilities.reservations.verifiedAgainst` says which.\n\n`X-Account-Id` restricts the listing to one connected account. Returns `403 listing_inactive` when the listing is inactive.",
+        "description": "Prices a stay and checks its availability **in the PMS that manages the listing**, without booking anything. It is the same check `POST /v1/reservations` makes before booking when no `totalPrice` is sent, so `available: true` with a `total` is what that create would be priced at (dates can still be taken in between).\n\n`available: false` is an answer, not an error: the PMS's reasons are in `restrictions` (minimum stay, closed to arrival, taken dates\u2026).\n\n- A listing **not managed in a PMS** answers `422 pms_not_linked`. Book it directly with `POST /v1/reservations`, or price it with `GET /v1/quotes`.\n- A PMS **without a quote API** (Mews, Cloudbeds, iGMS) answers `422 pms_write_unsupported`. You can still create the booking; on iGMS a `totalPrice` is required.\n\n`GET /v1/listings/{id}` \u2192 `capabilities.reservations.quote` says whether a listing can be quoted.\n\n### Per-PMS limits\n\n| PMS | create | change | cancel | quote | `totalPrice` | Limits |\n|---|---|---|---|---|---|---|\n| Mews | \u2713 | \u2713 | \u2713 | \u2013 | \u2713 | \u2014 |\n| Cloudbeds | \u2713 | \u2713 | \u2713 | \u2013 | \u2013 | Books at the rate plan's price; group bookings supported. |\n| Hostaway | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Direct-channel bookings only; a specific unit is refused; a date change keeps the booked total. |\n| Guesty | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Cancels direct and Vrbo bookings; other channel bookings are cancelled on the channel. |\n| Beds24 | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Needs the `write:bookings` scope; a multi-room property needs `unitId`. |\n| BookingSync | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Needs `bookings_write`; fees and taxes are not itemized; no guest email. |\n| Lodgify | \u2713 | \u2713 | \u2713 (declines) | \u2713 | \u2713 | Cancel declines the booking; single-room bookings. |\n| Smoobu | \u2713 | \u2713 (no dates) | \u2713 | \u2713 | \u2713 | Dates cannot be changed through Smoobu's API \u2014 cancel and rebook, or change them in Smoobu. |\n| Hospitable | \u2713 | \u2713 | \u2713 | \u2713 (Direct plan) | \u2713 | Manual reservations only; needs `reservation:write`; adds no fees or taxes. |\n| iGMS | \u2713 | \u2713 | \u2713 | \u2013 | \u2713 (required) | iGMS direct bookings only; a price is required; no tentative holds. |\n| OwnerRez | \u2713 | \u2713 | \u2013 | \u2713 | \u2013 | No cancel through OwnerRez's API; priced by the property's own rates; needs the `full` scope. |\n| Track | \u2713 | \u2713 | \u2713 | \u2713 | \u2713 | Track decides Hold vs Confirmed from the property's channel mode; a set price on a Channel Key needs \"Allow Custom Pricing\"; a unit change needs `moveReasonId` on the connection; a date change re-prices at Track's current rates. |\n\nEvery PMS except Cloudbeds refuses group bookings, and every vacation-rental PMS refuses to change or cancel a booking that came from a channel (Airbnb, Booking.com, Vrbo\u2026) \u2014 that is done on the channel.\n\n**Verification.** Mews and Cloudbeds were run end to end on their vendors' sandboxes. Every other PMS is **verified against the vendor's API documentation only** \u2014 no live account has been written to yet. `capabilities.reservations.verifiedAgainst` says which.\n\n`X-Account-Id` restricts the listing to one connected account. Returns `403 listing_inactive` when the listing is inactive.",
         "tags": [
           "Reservations"
         ],
@@ -35940,6 +36308,380 @@
           }
         }
       }
+    },
+    "/v1/connect/booking-extranet-login/recheck": {
+      "post": {
+        "operationId": "recheckBookingExtranetLogin",
+        "summary": "Re-check Booking.com direct-login permissions",
+        "description": "Re-runs the account import for a Booking.com direct-login connection after the host has granted the invited user full access in the Booking.com extranet (the `needs_permissions` state). Permissions are probed again and, once full access is in place, the connection continues to property details and room mapping \u2014 no new invitation is sent. Poll `GET /v1/connect/booking-extranet-login/status` for the result.\n\nCalled by the hosted Connect page. No API key \u2014 the session ID is the capability token.",
+        "tags": [
+          "Connect"
+        ],
+        "security": [],
+        "requestBody": {
+          "required": true,
+          "content": {
+            "application/json": {
+              "schema": {
+                "type": "object",
+                "properties": {
+                  "sessionId": {
+                    "type": "string",
+                    "description": "The Connect session ID (capability token)."
+                  },
+                  "accountId": {
+                    "type": "integer",
+                    "description": "The Booking.com direct-login connection id returned when the sign-in started."
+                  }
+                },
+                "required": [
+                  "sessionId",
+                  "accountId"
+                ]
+              }
+            }
+          }
+        },
+        "responses": {
+          "200": {
+            "description": "Re-check queued",
+            "content": {
+              "application/json": {
+                "schema": {
+                  "type": "object",
+                  "properties": {
+                    "ok": {
+                      "type": "boolean",
+                      "description": "Whether the re-check was queued."
+                    },
+                    "jobId": {
+                      "type": "string",
+                      "nullable": true,
+                      "description": "Id of the queued import job, when one was queued."
+                    }
+                  },
+                  "required": [
+                    "ok",
+                    "jobId"
+                  ]
+                }
+              }
+            }
+          },
+          "400": {
+            "$ref": "#/components/responses/BadRequest"
+          },
+          "404": {
+            "$ref": "#/components/responses/NotFound"
+          },
+          "409": {
+            "$ref": "#/components/responses/Conflict"
+          },
+          "410": {
+            "description": "The Connect session has expired (`session_expired`). Start a new session.",
+            "content": {
+              "application/json": {
+                "schema": {
+                  "$ref": "#/components/schemas/Error"
+                }
+              }
+            }
+          },
+          "500": {
+            "$ref": "#/components/responses/InternalError"
+          }
+        }
+      }
+    },
+    "/v1/connect/resume": {
+      "get": {
+        "operationId": "resumeConnect",
+        "summary": "Open a connection's fix link",
+        "description": "The target of a connection's `fixUrl`. Open it in the host's browser to send them back into Connect for an EXISTING connection \u2014 for example to grant the Booking.com extranet user full access after a `needs_permissions` state, or to reconnect a Smoobu account that still uses a legacy single API key with an API key + secret.\n\nEach open starts a fresh, short-lived Connect session bound to that connection and redirects (302) to the hosted Connect page, which shows the connection's current state. The link itself does not expire on its own schedule \u2014 store `fixUrl` and open it whenever the connection needs attention.\n\nNo API key \u2014 the signed `t` token is the capability. Supported for Booking.com extranet login and Smoobu connections.",
+        "tags": [
+          "Connect"
+        ],
+        "security": [],
+        "parameters": [
+          {
+            "name": "t",
+            "in": "query",
+            "required": true,
+            "schema": {
+              "type": "string"
+            },
+            "description": "The signed resume token, exactly as it appears in the connection's `fixUrl`."
+          }
+        ],
+        "responses": {
+          "302": {
+            "description": "Redirect to the hosted Connect page for a fresh session bound to the connection.",
+            "headers": {
+              "Location": {
+                "description": "Hosted Connect page URL for the new session.",
+                "schema": {
+                  "type": "string",
+                  "format": "uri"
+                }
+              }
+            }
+          },
+          "400": {
+            "description": "The link cannot be used: the token is missing, malformed or its signature does not verify (`invalid_resume_token`), the connection's channel has no hosted fix flow (`unsupported_channel`), or the connection id in the token is not valid (`bad_account`).",
+            "content": {
+              "application/json": {
+                "schema": {
+                  "type": "object",
+                  "properties": {
+                    "error": {
+                      "type": "string",
+                      "enum": [
+                        "invalid_resume_token",
+                        "unsupported_channel",
+                        "bad_account"
+                      ]
+                    },
+                    "reason": {
+                      "type": "string",
+                      "description": "Why the token was rejected (only with `invalid_resume_token`)."
+                    },
+                    "channel": {
+                      "type": "string",
+                      "description": "The token's channel (only with `unsupported_channel`)."
+                    }
+                  },
+                  "required": [
+                    "error"
+                  ]
+                }
+              }
+            }
+          },
+          "500": {
+            "description": "The Connect session could not be started. Open the link again.",
+            "content": {
+              "application/json": {
+                "schema": {
+                  "type": "object",
+                  "properties": {
+                    "error": {
+                      "type": "string",
+                      "enum": [
+                        "internal_error"
+                      ]
+                    }
+                  },
+                  "required": [
+                    "error"
+                  ]
+                }
+              }
+            }
+          }
+        }
+      }
+    },
+    "/v1/connect/track/credentials": {
+      "post": {
+        "operationId": "submitTrackCredentials",
+        "summary": "Submit Track credentials for a Connect session",
+        "description": "Completes a credentials-pattern connection for Track (TRACK Hospitality Software) with the property manager's Track domain and an API key + secret.\n\n**What syncs.** Units become listings; reservations (with their fee and tax breakdown) and guest message threads are imported, then polled for changes. Bookings can be created, quoted, changed and cancelled in Track \u2014 see `capabilities.reservations` on `GET /v1/connect/track`.\n\n**Which key.** A **Server Key** \u2014 created in Track under Configuration \u2192 Company Setup \u2192 API Keys \u2014 has full access and is recommended. A **Channel Key** \u2014 under Configuration \u2192 PMS Setup \u2192 Distribution Channels \u2014 only allows booking. `keyType` defaults to `server`.\n\nThe key is validated against Track before anything is stored, so an invalid key returns `invalid_credentials` rather than creating a dead connection. On success only the credential fields below are stored, and the first sync of listings and reservations is queued.\n\nTrack has no webhooks: after the first sync, reservation and message changes are picked up by polling about once a minute.\n\nReconnecting replaces the stored credentials on the workspace's existing Track connection \u2014 the `pmsConnectionId` stays the same.\n\nNo API key required when called with a `sessionId` \u2014 the session is the capability token.",
+        "tags": [
+          "Connect"
+        ],
+        "requestBody": {
+          "required": true,
+          "content": {
+            "application/json": {
+              "schema": {
+                "type": "object",
+                "properties": {
+                  "sessionId": {
+                    "type": "string",
+                    "description": "Connect session id from `POST /v1/connect/track`. Omit when calling with your API key."
+                  },
+                  "writePolicy": {
+                    "type": "object",
+                    "description": "Optional: what the app may change in Track, set before the first sync. Same shape as `PATCH /v1/connect/{provider}/write-policy`; switches you leave out keep the provider default (everything on).",
+                    "example": {
+                      "reservations": {
+                        "api": false
+                      }
+                    }
+                  },
+                  "credentials": {
+                    "type": "object",
+                    "description": "The Track domain and an API key + secret.",
+                    "properties": {
+                      "domain": {
+                        "type": "string",
+                        "description": "Your Track domain: `acme.trackhs.com`, or just the subdomain `acme`. A full URL is accepted; only the host is kept.",
+                        "example": "acme.trackhs.com"
+                      },
+                      "apiKey": {
+                        "type": "string",
+                        "description": "Track API key."
+                      },
+                      "apiSecret": {
+                        "type": "string",
+                        "description": "Track API secret, shown next to the key in Track."
+                      },
+                      "keyType": {
+                        "type": "string",
+                        "enum": [
+                          "server",
+                          "channel"
+                        ],
+                        "default": "server",
+                        "description": "`server` \u2014 a Server Key (Company Setup \u2192 API Keys), full access, recommended. `channel` \u2014 a Channel Key (PMS Setup \u2192 Distribution Channels), booking only."
+                      },
+                      "authMode": {
+                        "type": "string",
+                        "enum": [
+                          "hmac",
+                          "basic"
+                        ],
+                        "default": "hmac",
+                        "description": "How requests to Track are signed. Leave the default unless Track support told you otherwise."
+                      },
+                      "hmacRealm": {
+                        "type": "string",
+                        "description": "HMAC realm. Defaults to `Acquia`, the realm Track's HMAC signing uses."
+                      },
+                      "secretIsBase64": {
+                        "type": "boolean",
+                        "default": true,
+                        "description": "Whether `apiSecret` is base64-encoded, as Track issues it. Set false to sign with the secret's raw text."
+                      },
+                      "paymentTypeId": {
+                        "type": "integer",
+                        "description": "The Track payment type that payments recorded through this connection are posted to."
+                      },
+                      "moveReasonId": {
+                        "type": "integer",
+                        "description": "The Track move reason used when a reservation is moved to another unit. Without it, unit changes are refused."
+                      }
+                    },
+                    "required": [
+                      "domain",
+                      "apiKey",
+                      "apiSecret"
+                    ]
+                  }
+                },
+                "required": [
+                  "credentials"
+                ]
+              },
+              "example": {
+                "credentials": {
+                  "domain": "acme.trackhs.com",
+                  "apiKey": "trk_live_\u2026",
+                  "apiSecret": "\u2026"
+                }
+              }
+            }
+          }
+        },
+        "responses": {
+          "200": {
+            "description": "Credentials accepted, the connection stored and its first sync queued",
+            "content": {
+              "application/json": {
+                "schema": {
+                  "type": "object",
+                  "properties": {
+                    "provider": {
+                      "type": "string",
+                      "example": "track"
+                    },
+                    "connected": {
+                      "type": "boolean"
+                    },
+                    "pmsConnectionId": {
+                      "type": "string",
+                      "description": "Id of the stored connection."
+                    },
+                    "created": {
+                      "type": "boolean",
+                      "description": "False when an existing connection was updated."
+                    },
+                    "sessionId": {
+                      "type": "string",
+                      "nullable": true
+                    },
+                    "accountInfo": {
+                      "type": "object",
+                      "properties": {
+                        "domain": {
+                          "type": "string",
+                          "description": "The Track host the connection calls.",
+                          "example": "acme.trackhs.com"
+                        },
+                        "keyType": {
+                          "type": "string",
+                          "enum": [
+                            "server",
+                            "channel"
+                          ]
+                        },
+                        "authMode": {
+                          "type": "string",
+                          "enum": [
+                            "hmac",
+                            "basic"
+                          ]
+                        },
+                        "accountName": {
+                          "type": "string",
+                          "nullable": true
+                        }
+                      }
+                    },
+                    "firstSync": {
+                      "type": "object",
+                      "description": "Whether the first import of listings and reservations was queued. When it was not, the connection still stands and polling syncs it.",
+                      "properties": {
+                        "queued": {
+                          "type": "boolean"
+                        },
+                        "error": {
+                          "type": "string"
+                        }
+                      }
+                    },
+                    "writePolicy": {
+                      "$ref": "#/components/schemas/PmsWritePolicy"
+                    }
+                  }
+                }
+              }
+            }
+          },
+          "400": {
+            "$ref": "#/components/responses/BadRequest"
+          },
+          "401": {
+            "$ref": "#/components/responses/Unauthorized"
+          },
+          "404": {
+            "$ref": "#/components/responses/NotFound"
+          },
+          "422": {
+            "$ref": "#/components/responses/UnprocessableEntity"
+          },
+          "502": {
+            "description": "Track could not be reached (`network_error`). Nothing was stored.",
+            "content": {
+              "application/json": {
+                "schema": {
+                  "$ref": "#/components/schemas/Error"
+                }
+              }
+            }
+          }
+        }
+      }
     }
   }
 }