Reference · built on requestConnectorHospitality & property systems

Guesty

Reservations, listings, guests, calendar, inbox messages, and tasks from Guesty's Open API, with webhooks for each object.

Request accessPricing ↗

About

Guesty is a property management platform for short-term and vacation rentals, connected to booking channels such as Airbnb and Booking.com. Its Open API at open-api.guesty.com/v1 covers listings, reservations (v3 endpoints replacing the legacy ones), guests, the guest inbox, calendar availability and pricing, tasks, reviews, owners, and the guest folio. Webhooks deliver events such as reservation.created.v2, listing.calendar.updated, guest.updated, task.created, and reservation.messageReceived.

Through Fibric, an operator reads the reservation or conversation behind each event and proposes a status change, a note, a task, or a reply for your approval, leaving a receipt of what changed and how to undo it.

This is a reference listing. It documents what Fibric would read from Guesty and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Reservations through Search Reservations (filters on status, listingId, source, checkIn, checkOut, createdAt) and Retrieve Reservations by id, with financial breakdown and guest details
  • Reservation statuses confirmed, reserved, awaiting_payment, inquiry, canceled, closed, declined, expired; guest stay status not_set, checked_in, checked_out, no_show
  • Webhooks reservation.created.v2 and reservation.updated.v2 with changedFields; reservation.messageReceived and reservation.messageSent
  • Listings and their daily calendar (availability, price, minimum stay, blocks) through the availability-pricing calendar endpoints; calendar.updated.v2
  • Guests through Get guests list and Get guest by id; guest.created, guest.updated, and guest.deleted events
  • Conversations and posts from the guest inbox; tasks with task.created, task.updated, task.deleted; reviews sorted by last update
  • Payment events such as payments.failed, payments.refunded, and payments.disputes; guest folio balances and invoice items

Proposed actions

  • Target capability: propose a reservation status through /reservations-v3/{reservationId}/status, or a guest stay status of checked_in, checked_out, or no_show
  • Target capability: propose reservation notes, including the key code and special requests fields, through Update Reservation notes
  • Target capability: propose a task with /tasks-open-api/create-single-task, or an update to an existing task
  • Target capability: propose a reply in a conversation through Post msg (Send new msg), or save a post without sending it
  • Target capability: propose a change to a listing's calendar (nightly rate, minimum stay, availability) for a date range

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Turn the unit between stays

    On reservation.created.v2 or a date change, read check-in and check-out per listing, and propose a cleaning task with a due time before the next arrival.

    With Unit Turn, Clean Sequence

  • Answer the guest inside the inbox

    Subscribe to reservation.messageReceived, read the conversation and the reservation, and propose a reply for approval before it is sent.

    With Guest Requests, First Response

  • Reply to every review

    Read new reviews and their listing, draft a response for the host to approve, and record which reviews are answered.

    With Review Reply, Review Response

  • Chase a failed payment

    On payments.failed or payments.overdue, read the folio balance and propose a guest message and a task for the owner's team.

    With Payment Retry, Dunning Cadence

Requirements

  • A Guesty account with Open API credentials; the Client Secret is visible only the first time
  • A webhook URL on HTTPS port 443 with a publicly resolvable hostname, returning 2xx within 15 seconds
  • The webhook secret from GET /webhooks-v2/secret to validate payload signatures
  • New work targets the v3 reservation endpoints and v2 events; the legacy ones are being retired
Authentication
OAuth 2.0 client credentials: a Client ID and Client Secret created in your Guesty account, exchanged at https://open-api.guesty.com/oauth2/token with scope open-api for a bearer token valid 24 hours.

Limits

  • 15 requests per second, 120 per minute, and 5,000 per hour, shared by every token on the account; a 429 carries Retry-After
  • At most five access tokens per clientId per 24 hours; tokens must be stored and reused
  • Guest folio updates do not emit webhooks yet; folio data is polled through the guest-folio endpoints
  • Failed webhook deliveries are retried with backoff for up to 5 days, after which Guesty disables the endpoint

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Guesty ↗

Questions and answers

How many API calls can the connector make against Guesty?
Guesty enforces 15 requests per second, 120 per minute, and 5,000 per hour across all tokens on an account. Responses carry X-RateLimit-Limit and X-RateLimit-Remaining headers per interval, and a 429 tells you how long to wait in Retry-After.
Which reservation webhook should I use?
The v2 events: reservation.created.v2 and reservation.updated.v2. They carry stay details, a publishedAt timestamp, and changedFields; financials, payments, and full guest and listing objects are fetched separately. Guesty plans to phase out reservation.new and reservation.updated by the end of 2026.
How long does a Guesty access token last?
24 hours (86400 seconds). Guesty allows at most five tokens per clientId per 24 hours, so the connector stores each token and reuses it until it expires rather than requesting one per call.
Ask about Guesty

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Guesty through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy