Writing through a PMS

When a review, booking request, inquiry, listing, guest or conversation comes from a connected PMS (Guesty, Hostaway, …), the PMS owns it. Writes to it go to the PMS first, through the same endpoints you use for everything else — you do not call a different API. If the PMS's API cannot do something, the call is refused with 422 pms_write_unsupported naming the PMS, and nothing is written anywhere. Repull never fakes a write the PMS did not make.

Know before you call: capabilities.pms

GET /v1/connect/{provider} and GET /v1/listings/{id} (for a listing a PMS manages) carry capabilities.pms. Every false flag is a call that would answer pms_write_unsupported. connected: false means the PMS is not connected — the flags are what it supports once it is, and on a listing every write answers 409 no_connection.

curl https://api.repull.dev/v1/connect/hostaway \
  -H 'Authorization: Bearer sk_live_YOUR_KEY'

• reservations.respond — accept and decline booking requests the PMS relays.
• reservations.preapprove — pre-approve inquiries the PMS relays.
• reviews.read / reviews.reply — its reviews appear in GET /v1/reviews; replies go through it.
• listings.* — the content sections PUT /v1/listings/{id}/content writes to the PMS.
• guests.create / guests.update — POST /v1/guests with provider, PATCH /v1/guests/{id}.
• conversations.send / attachments / channelSelect — sending, files, and choosing the channel.
• calendar.write — PUT /v1/availability/{propertyId} can reach the PMS (still subject to the write policy).
• notes — the limits worth knowing, per family, in plain words.

By PMS

The same flags for every connected PMS. Guesty and Hostaway have the full breakdown — what works, what is refused and why — on their pages: Guesty, Hostaway.

Reviews and replies

Reviews read from a PMS appear in GET /v1/reviews with pms set to the PMS ("guesty", "hostaway"). platform is still the channel the guest wrote the review on. pms is null for a review from a channel you connected directly.

POST /v1/reviews/{id}/reply answers a PMS review through that PMS, and the response names it in pms. Guesty replies on Airbnb and Booking.com reviews. Hostaway's review API is read-only, so a reply to a Hostaway review is 422 pms_write_unsupported.

Booking requests and inquiries

POST /v1/reservations/{id}/accept and /decline answer a request the PMS relays in that PMS, whatever channel it came from. POST /v1/conversations/{id}/pre-approval pre-approves an inquiry the PMS relays. The response carries pms. Guesty answers requests and pre-approves Airbnb inquiries (no message on approve or pre-approve, and no switch to block Instant Book). Hostaway has no API for either — answer them in Hostaway. A reservation that is not a pending request is still 409 reservation_not_pending.

Listing content

On a listing a PMS manages, PUT /v1/listings/{id}/content writes title, descriptions, check-in/out times, capacity, amenities, house rules, address and added photos to the PMS first, section by section, and keeps in Repull only what the PMS accepted. The response says what happened:

{
  "id": "4118",
  "changed": ["title", "amenities"],
  "deferred": ["houseRules"],
  "pms": {
    "provider": "hostaway",
    "applied": ["title", "amenities"],
    "errors": [
      { "section": "houseRules", "code": "unsupported", "message": "Hostaway: house-rule switches (pets, smoking, events, children) are not writable. Change them in Hostaway." }
    ]
  }
}

• A section the PMS refused is listed in deferred and in pms.errors, and is not written in Repull either.
• When the PMS applied nothing, the call is 422 pms_write_unsupported (or pms_rejected when it refused the values).
• Send photos with photosMode: "append" — replacing a PMS listing's photo set needs the PMS's own photo ids.
• A PMS with no content API at all (Mews, Cloudbeds, Lodgify, …) keeps the content in Repull only, as before.

Guests

POST /v1/guests with provider creates the guest in that PMS first; its id there comes back as pms.externalId. PATCH /v1/guests/{id}changes a guest's name, email, phone or language — for a guest linked to a PMS (created with provider, or imported from it) the change is written to the PMS first, and pmslists each PMS it reached. Email and phone are added as the guest's newest contact; earlier ones are kept. Hostaway has no guest records, so both are refused for it.

curl -X PATCH https://api.repull.dev/v1/guests/790 \
  -H 'Authorization: Bearer sk_live_YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: 6f1c2a9e-3b7d-4c55-9a0e-2f8d4b1e7c30' \
  -d '{ "lastName": "Rossi", "email": "marco.rossi@example.com" }'

Messages

On a conversation a PMS relays, POST /v1/conversations/{id}/messages sends through the PMS. Omit channelto send on the conversation's own channel — the right default. Pass it to choose, using the PMS's own names or Repull's, which the PMS maps:

• Guesty: airbnb2, platform (the booking's channel), email, sms, whatsapp, or note for an internal note the guest does not see. airbnb, booking, vrbo and website are mapped.
• Hostaway: channel (the booking's channel), email, sms, whatsapp. airbnb, booking, vrbo and expedia only when the booking is on that channel.

A PMS that cannot choose a channel, or cannot send files, refuses the message with 422 pms_write_unsupported and nothing is sent. Neither Guesty nor Hostaway can send attachments through its API — put a link in the text instead.

Calendar

PUT /v1/availability/{propertyId}on a listing a PMS manages also writes to the PMS — open or closed nights, nightly price, minimum stay — when the connection's write policy allows it. For Guesty and Hostaway those switches start off: the PMS is the source of its own calendar, so you opt in per connection with PATCH /v1/connect/{provider}/write-policy. Bookings never push to the PMS — it blocks its own booked nights.

When a PMS write is refused

Every refusal carries provider, a fix and a docs_url; content writes add the per-section pms outcome.