Docs/Knowledge Base/PMS Guides

Guesty API

Guesty exposes a REST Open API at open-api.guesty.com covering listings, reservations, calendar, guests, messaging and webhooks, authenticated with OAuth2 client credentials issued from Settings → Integrations → Open API.

Written from running this integration in production. Last checked against the Guesty API on 3 October 2026.

What the Guesty API is

Guesty runs a REST API — the Open API — at https://open-api.guesty.com/v1. It covers most of what the product does: listings, reservations, the availability and pricing calendar, guests, guest messaging and webhooks. You can read bookings, write nightly rates and minimum stays, block dates, and reply to a guest.

Access is not gated. Unlike Airbnb or Booking.com, there is no partner programme to apply to and no review to pass — an account holder creates credentials in the dashboard in about a minute. If your client is on Guesty and will give you access, you can be reading their reservations this afternoon.

So the question is not whether it can do the job. It is what the job turns out to cost, and that is what the rest of this page is about.

How to get Guesty API access

  1. 1.In Guesty, open Settings → Integrations → Open API. You need an account with permission to manage integrations; a staff user usually does not have it.
  2. 2.Create an application. Guesty issues a Client ID and a Client Secret. The secret is shown once — store it before you close the dialog.
  3. 3.Exchange them for an access token at https://open-api.guesty.com/oauth2/token with grant_type=client_credentials and scope=open-api.
  4. 4.Call the API with Authorization: Bearer <token> against https://open-api.guesty.com/v1. Read the next section before you write that code.

There is no consent screen and no redirect flow, which makes Guesty quick to connect and also means the credentials belong to the account holder. If you are building for clients, each client creates their own application and hands you the pair — and you are now storing their secrets.

What will bite you

From running this integration in production, not from their documentation.

The Guesty API token limit: five per key per 24 hours

This is the one that hurts, and it is not in the place you would look. Guesty does not merely rate-limit the token endpoint — it caps you at five tokens per key per rolling day. Fetch a token per request, which is what almost every HTTP client does by default, and you are locked out after five calls for a day, with your integration dark and nothing obviously wrong in your code. Cache the token, persist it somewhere every process and every deploy can reach, and refresh only near expiry. Our connector caches in memory, then in the database, refreshes five minutes before the token dies, and counts issuance against a rolling 24-hour window so it refuses locally rather than spending the fifth one.

The channel is called airbnb2

A reservation that came from Airbnb has source: "airbnb2", not "airbnb". Booking.com is "bookingcom". Anything handling cross-channel bookings branches on this, and matching the obvious string sends every Airbnb reservation quietly down your fallback path. It raises no error, passes code review, and shows up a week later as "why are the Airbnb ones wrong".

The calendar is not where the rest of the API is

Listings, reservations and guests sit at /v1/<resource>. The calendar sits at /availability-pricing/api/calendar/listings/{listingId} — a different base path, a different shape, reading and writing a days array. Any abstraction you build over "Guesty resources" needs a special case for it on day one, which usually means discovering it on day two.

Messages are "posts" inside "conversations"

Messaging lives under /communication/conversations. The messages in a conversation come from /communication/conversations/{id}/posts, and sending is a separate verb-shaped endpoint, /communication/conversations/{id}/send-message, rather than a POST to the collection you just read.

Offset pagination, and filters as stringified JSON

Collections take limit and skip. Deep pagination slows as you go, and a record inserted mid-walk shifts rows under you — so a nightly full sync can skip or double a booking. Filters are passed as a JSON-encoded array inside a query parameter: filters=[{"field":"status","operator":"$eq","value":"confirmed"}].

Ids are Mongo ObjectIds

Every id is _id, a 24-character hex string. Not an integer, not a UUID. If your schema types ids as integers you find out at insert time; if it types them as UUIDs, your validation rejects perfectly good data.

What it costs to keep working

Getting the first reservation out of Guesty is an afternoon. Keeping it working is the part worth costing, because it never goes back to zero.

  • •The token cache is now infrastructure you own. It has to be shared across processes, survive deploys, and never race — five tokens a day leaves no room to be sloppy.
  • •Credentials are per account. Every client creates their own application and hands you a Client ID and Secret, and every pair is a secret you store, rotate, revoke and get asked about in a security review.
  • •Payloads move. Reservation fields and webhook bodies change as Guesty ships; nothing announces it, the shape is simply different one morning.
  • •Channel source values are Guesty’s vocabulary, not the channels’. When Guesty adds an integration, a new string appears in your data before it appears in your code.
  • •None of this is Guesty being difficult — it is the ordinary cost of owning an integration. The point is that it is the same cost again for the next system, and it does not get cheaper with practice.

The same job, both ways

Guesty directly

# Get a token. You get five a day, so this must be cached.
curl -s -X POST 'https://open-api.guesty.com/oauth2/token' \
  -H 'Content-Type: application/json' \
  -d '{
    "grant_type": "client_credentials",
    "scope": "open-api",
    "client_id": "YOUR_CLIENT_ID",
    "client_secret": "YOUR_CLIENT_SECRET"
  }'

# Then read, with offset pagination.
curl -s 'https://open-api.guesty.com/v1/reservations?limit=100&skip=0' \
  -H 'Authorization: Bearer <token>'

# Then write the mapping, the token cache, the airbnb2 special case,
# and the calendar's separate base path. Then do it again for the
# next system your next client uses.

Through Repull

curl -s 'https://api.repull.dev/v1/reservations?limit=100' \
  -H 'Authorization: Bearer sk_live_YOUR_KEY'

# Guesty, Airbnb, Booking.com, Hostaway, Lodgify, OwnerRez, Smoobu,
# Beds24, iGMS and BookingSync come back from this one call.
# `platform` says where each reservation came from.

Why use Repull for Guesty

Your second client will not be on Guesty

If you have one client, they are on Guesty, and they always will be, use the Open API directly — we would be a layer you do not need. Almost nobody stays in that position, and the second client is where the cost lands.

Every system authenticates differently

Guesty is OAuth2 client credentials with a five-token-a-day cap. Hospitable is a personal access token. Lodgify is an API key. Smoobu signs every request with an API key and secret (HMAC), and retires its old single keys on October 31, 2026. OwnerRez is basic auth or OAuth2. Beds24 is a refresh-token exchange. Hostaway is client credentials, and signs its webhooks with optional basic auth rather than an HMAC. Seven models across nine systems, each one a credential to store, refresh, rotate and explain to somebody’s security team.

Every system has its own trap, and you meet them one at a time

The five-token cap is Guesty’s. Lodgify’s messaging API is read-only, so you cannot reply through it at all. OwnerRez has no guest messaging API. None of these are in the documentation — you find them in production, usually on a Friday. We have already found them, which is most of what you are buying.

Some clients have no PMS at all

The next one may run on an Airbnb account and a spreadsheet. No amount of Guesty integration reaches them, and direct channel access cannot be bought — Airbnb approves software companies one product category at a time through a commercial and compliance review, and Booking.com designates connectivity partners. Neither is a signup form and neither is measured in days. Repull already holds that access, so one key covers a Guesty account and a direct Airbnb or Booking.com connection at once.

A PMS is not a route to a channel’s own features

Guesty passes through most of what you need from Airbnb — reservations, calendar, prices, messaging, review replies, booking requests and pre-approvals, listing content and photos. What it cannot pass through is anything that exists only in Airbnb’s protocol: the reservation alteration flow, special offers, reviewing a guest, permits and safety disclosures, the per-listing sync category that decides whether a write is accepted at all. Those are 36 Airbnb-specific endpoints on Repull, alongside the same unified read.

Connect Guesty through Repull

Create a key, connect a Guesty account with its Client ID and Secret, and read reservations in the same shape as every other system you support.

Frequently asked questions

Does Guesty have a public API?

Yes. The Guesty Open API is a REST API at https://open-api.guesty.com/v1 covering listings, reservations, calendar, guests, messaging and webhooks. Any account holder with permission to manage integrations can create credentials from Settings → Integrations → Open API — there is no partner application to submit.

How do I get Guesty API credentials?

In Guesty, go to Settings → Integrations → Open API and create an application. You are issued a Client ID and Client Secret; the secret is shown once. Exchange them at https://open-api.guesty.com/oauth2/token with grant_type=client_credentials and scope=open-api for a bearer token.

Why is my Guesty token request failing?

Most often because you have used your five tokens for the day. Guesty caps token issuance at five per API key per 24 hours. If you request a token per API call rather than caching one, you exhaust the allowance almost immediately and every request after that fails until the window rolls. Cache the token across processes and refresh only near expiry.

What are the Guesty API rate limits?

The limit developers hit first is not on requests but on tokens: five per API key per 24 hours. Request limits apply on top and vary by endpoint and plan. In practice, treat a token as a shared resource rather than something you fetch per call.

Why do my Airbnb reservations not match on source?

Guesty labels Airbnb reservations source: "airbnb2", not "airbnb". Booking.com is "bookingcom". Code that branches on the obvious string sends every Airbnb booking down the fallback path without raising an error.

How long does a Guesty integration take to build?

Reading your first reservation is an afternoon. A production integration is longer: a shared token cache that respects the five-a-day cap, offset pagination that does not skip records mid-sync, the calendar on its separate base path, channel source values like "airbnb2", and webhook handling. Budget days rather than hours, then ongoing maintenance as payloads change.

Can I use Guesty and Repull together?

Yes. Repull connects to the same Open API you would call yourself, so nothing changes inside Guesty. You can read through Repull’s unified schema and still call Guesty directly for anything Guesty-specific.

The other systems Repull connects

What you can do with Guesty through Repull

Verified against vendor documentation Checked against the Guesty API reference on 3 October 2026; not yet run against a live account.

Reading listings, reservations, the calendar and conversations works as on every system. These are the writes that go into Guesty. A refused operation is refused because Guesty's API cannot do it: the call answers 422 pms_write_unsupported naming Guesty, and nothing is sent. Read capabilities.pms on GET /v1/connect/guesty or GET /v1/listings/{id} to know before you call. Bookings are covered in PMS reservation support; how each write is routed is in Writing through a PMS.

WhatCallGuestyNotes
Read reviewsGET /v1/reviewsSupportedAirbnb, Booking.com, Vrbo and custom-channel reviews, with ratings, text and the host reply. Each carries pms: "guesty"; platform is still the channel the guest wrote it on.
Reply to a reviewPOST /v1/reviews/{id}/replySupportedSent through Guesty on Airbnb and Booking.com reviews, one reply per review. Guesty has no reply for Vrbo or custom-channel reviews.
Accept or decline a booking requestPOST /v1/reservations/{id}/accept · /declineSupportedChannel booking requests (Airbnb, Booking.com, …) waiting on the host; a direct reservation is refused. Decline passes your reason and sends message to the guest. Guesty’s approve takes no message — send one on the conversation afterwards. Guesty confirms asynchronously; the reservation updates when it does.
Pre-approve an inquiryPOST /v1/conversations/{id}/pre-approvalSupportedAirbnb inquiries only. Guesty’s pre-approval has no switch to block Instant Book, so blockInstantBooking: true is refused, and it carries no message — send one on the conversation.
Title, descriptions, check-in/out times, guests, addressPUT /v1/listings/{id}/contentSupportedWritten to Guesty first, then kept in Repull. Bedroom, bathroom and bed counts, a separate long-form description and text in a language other than the listing’s default are refused — change those in Guesty.
Amenities and house rulesPUT /v1/listings/{id}/contentSupportedAmenities are a full replacement; an amenity Guesty does not know is refused. House rules: pets, smoking, events and children allowed. Quiet hours and minimum age are left as they are.
PhotosPUT /v1/listings/{id}/contentSupportedAdd by URL (send photosMode: "append"), delete, reorder and caption.
Create a guestPOST /v1/guests with providerSupportedCreated in Guesty first; its Guesty id comes back as pms.externalId. Guesty requires a last name.
Update a guestPATCH /v1/guests/{id}SupportedName, email, phone and language, written to Guesty first for a guest linked to it.
Send a messagePOST /v1/conversations/{id}/messagesSupportedSent through Guesty on the conversation’s own channel: Airbnb threads on Airbnb, Booking.com and Vrbo threads on the booking channel, direct threads by email.
Choose the channelchannel on POST /v1/conversations/{id}/messagesSupportedairbnb2, platform (the booking’s channel), email, sms, whatsapp, or note for an internal note the guest does not see. Repull’s names airbnb, booking, vrbo and website are mapped. airbnb2 on a thread that is not an Airbnb booking is refused.
Send attachmentsattachments on POST /v1/conversations/{id}/messagesRefusedGuesty’s messaging API has no file upload. A message carrying attachments is refused and nothing is sent — send a link in the text instead.
Calendar: open/close nights, nightly price, minimum stayPUT /v1/availability/{propertyId}SupportedOff until you turn it on for the connection with the write policy (calendar.availability, calendar.rates, calendar.restrictions). Guesty has no per-night maximum stay. Bookings never push to Guesty: it blocks its own booked nights.

Reference

Auth Type

OAuth2 Client Credentials

Required Fields

clientIdclientSecret

Supported Operations

✓ listings
✓ reservations
✓ calendar
✓ messages
✓ webhooks
✓ guests

Connection Guide

In Guesty, go to Settings → Integrations → Open API and create an application. Copy the Client ID and Client Secret — the secret is shown once.

Notes

  • • HMAC SHA-256 webhook signature validation
  • • Supports guest profile management
  • • Rich conversation threading
AI