What your app may change in a PMS

Every PMS connection has a write policy: a set of switches that decide what Repull may change in the PMS on your behalf. Reading from the PMS is never affected. Use it when the PMS is the system of record and you only want some changes to flow back.

The switches

Defaults

• Hotel PMSs (Cloudbeds, Mews): every calendar switch is off — the hotel system owns its room inventory. Bookings are on.
• Guesty and Hostaway: every calendar switch is off — the PMS is the source of its own calendar, so PUT /v1/availability/{propertyId} reaches it only once you turn the switches on. Bookings are on.
• Every other PMS: everything is on.

Calendar writes into the PMS

With a calendar switch on, a deliberate calendar edit — PUT /v1/availability/{propertyId} on a listing the PMS manages — is written to the PMS as well: calendar.availability opens and closes nights, calendar.rates sends the nightly price and calendar.restrictions the minimum stay. A field whose switch is off is left out and the rest still goes through. Bookings never push to the PMS: it blocks its own booked nights. To open Guesty or Hostaway to calendar writes:

curl -X PATCH https://api.repull.dev/v1/connect/guesty/write-policy \
  -H 'Authorization: Bearer sk_live_...' \
  -H 'Content-Type: application/json' \
  -d '{ "calendar": { "availability": true, "rates": true, "restrictions": true } }'

capabilities.pms.calendar.write on GET /v1/connect/{provider} says whether the PMS takes calendar writes at all. See Writing through a PMS.

Read the policy

The policy is also returned as writePolicy on GET /v1/connect/{provider} for PMS connections.

curl https://api.repull.dev/v1/connect/cloudbeds/write-policy \
  -H 'Authorization: Bearer sk_live_...'

# {
#   "provider": "cloudbeds",
#   "writePolicy": {
#     "calendar": { "availability": false, "rates": false, "restrictions": false },
#     "reservations": { "website": true, "dashboard": true, "api": true }
#   },
#   "defaults": { ... }
# }

Change it

Send only the switches you want to change. Every value must be true or false; an unknown switch is rejected with 400 invalid_params, so a typo never leaves a write on. Changes apply to the next write — nothing already sent to the PMS is undone.

curl -X PATCH https://api.repull.dev/v1/connect/cloudbeds/write-policy \
  -H 'Authorization: Bearer sk_live_...' \
  -H 'Content-Type: application/json' \
  -d '{ "calendar": { "rates": true } }'

Set it while connecting

On the hosted Cloudbeds and Mews pages your user sees the switches under the API key field, set to the defaults. When you submit credentials yourself, pass writePolicy with them — it applies before the first sync, so nothing is written under the wrong switches.

curl -X POST https://api.repull.dev/v1/connect/cloudbeds/credentials \
  -H 'Authorization: Bearer sk_live_...' \
  -H 'Content-Type: application/json' \
  -d '{
    "credentials": { "apiKey": "cbat_..." },
    "writePolicy": { "calendar": { "rates": true } }
  }'

When a write is refused

With reservations.api off, creating, changing or cancelling a booking on that PMS through the reservations API returns 409 pms_writes_off. Nothing is sent to the PMS. Make the change in the PMS, or turn the switch on. Calendar writes that are off are skipped silently — the rest of the update still goes through.

{
  "error": {
    "code": "pms_writes_off",
    "message": "Bookings for this property are managed in its PMS, and this connection is set not to change them through the API. Nothing was sent to the PMS.",
    "fix": "Turn on `reservations.api` with `PATCH /v1/connect/{provider}/write-policy`, or make the change in the PMS."
  }
}

See also Connect (multi-channel) and the PMS guide.