pms_write_unsupported

The PMS that owns the record cannot do this through its API (for example cancel on OwnerRez, reply to a review on Hostaway, or send attachments through Guesty). Do it in the PMS; the change arrives with the next sync. `capabilities.pms` says beforehand.

HTTP 422The request was understood but refused as sent. Change it before retrying.

When it fires

The listing is managed in a PMS, and that PMS's API cannot do what you asked. Repull never fakes a write the PMS cannot make, so the request is refused and nothing is sent. Typical cases:

  • Cancelling on OwnerRez — its API has no cancel.
  • Changing the dates of a Smoobu booking — cancel and rebook, or change them in Smoobu.
  • POST /v1/reservations/quote on Mews, Cloudbeds or iGMS, which have no quote API. You can still create the booking; on iGMS a totalPrice is required.
  • platform: "owner" on a PMS listing — block owner stays in the PMS.
  • A specific unitId on Hostaway or iGMS, or a tentative hold on iGMS.
  • A group booking on any PMS except Cloudbeds.
  • Moving a PMS stay to another listing, or changing its check-in/check-out times.

Beyond bookings, writes that go through the PMS that owns the record:

  • Replying to a Hostaway review — Hostaway's review API is read-only.
  • Accepting or declining a booking request, or pre-approving an inquiry, relayed by Hostaway.
  • POST /v1/guests with provider: "hostaway", or PATCH /v1/guests/{id} on a guest linked to Hostaway — Hostaway has no guest records.
  • Listing content sections the PMS cannot store: house-rule switches on Hostaway; bedroom, bathroom and bed counts or non-default-language text on Guesty.
  • attachments on a message sent through Guesty or Hostaway — neither API sends files.
  • blockInstantBooking: true on a Guesty pre-approval.

provider names the PMS and message says where to make the change instead.

Response shape

Every Repull error follows the same envelope. The code is stable and safe to switch on.

{
  "error": {
    "code": "pms_write_unsupported",
    "message": "OwnerRez cannot cancel a booking through its API. Cancel it in OwnerRez.",
    "fix": "Cancel it in OwnerRez; the cancellation reaches Repull with the next sync.",
    "docs_url": "https://repull.dev/docs/errors/pms_write_unsupported",
    "request_id": "req_01J5X7Y8Z9ABCDEF12345678",
    "provider": "ownerrez"
  }
}

How to fix

  1. Do not retry — the same request is refused the same way.
  2. Make the change in the PMS named in `provider`. It reaches Repull with the next sync, and the matching webhook fires.
  3. Before writing, read `GET /v1/listings/{id}` → `capabilities.reservations` (`create`, `modify`, `cancel`, `quote`, `customPrice`, `notes`) and `capabilities.pms` (review replies, request answers, pre-approvals, listing content sections, guests, message channel and attachments, calendar) — or `GET /v1/connect/{provider}` → `capabilities.pms` — to know what the PMS supports.

Common gotchas

  • This is a property of the PMS's API, not of your plan or your connection. Reconnecting does not change it.
  • The per-PMS tables are at PMS reservation support (bookings) and Writing through a PMS (everything else).
  • On PUT /v1/listings/{id}/content the code is returned only when the PMS applied nothing. When it applied some sections, the call succeeds and the refused ones are in deferred and pms.errors.

Examples

curl

# Check first: what can this listing do?
curl https://api.repull.dev/v1/listings/4118 \
  -H "Authorization: Bearer sk_live_YOUR_KEY"
# → "capabilities": { "reservations": { "provider": "ownerrez", "cancel": false, ... } }

curl -X POST https://api.repull.dev/v1/reservations/215708/cancel \
  -H "Authorization: Bearer sk_live_YOUR_KEY"
# → 422 pms_write_unsupported

TypeScript

const res = await fetch('https://api.repull.dev/v1/reservations/215708/cancel', {
  method: 'POST',
  headers: { Authorization: `Bearer ${process.env.REPULL_API_KEY}` },
})
if (res.status === 422) {
  const { error } = await res.json()
  if (error.code === 'pms_write_unsupported') {
    // Not possible through this PMS's API — tell the user to do it in error.provider
    return { doItInPms: error.provider, why: error.message }
  }
}

If you're an AI agent

The PMS's API cannot perform this write. Do not retry. Tell the user to make the change directly in the PMS named in `provider`; it syncs back automatically. Check capabilities.reservations and capabilities.pms on GET /v1/listings/{id} (or capabilities.pms on GET /v1/connect/{provider}) before attempting writes.

Hit an error that isn't covered? Email hello@repull.dev with the request id from the response headers.

AI