Guesty caps you at five access tokens per client ID per 24 hours, and each token lasts 24 hours. That one limit decides your architecture: anything that mints a token per process start, per agent session, or per serverless invocation exhausts the budget within hours. Guesty also ships an official MCP server in early beta, read-only during beta, so if you want conversational access rather than a built tool, start there.
The token limit that decides your architecture
Guesty authenticates with OAuth client credentials, and the constraint that matters is not the auth flow but the quota. Guesty allows only five access tokens per client ID per 24 hours, and each issued token remains valid for 24 hours.
This breaks the most natural way to write an integration. An MCP server starts fresh every time the assistant launches; a serverless function may cold-start dozens of times an hour; an agent that re-authenticates per session burns a token each time. Five of any of those and you are locked out until the window rolls. The fix is to mint once and cache the token for its full life, which is exactly what the gateway does centrally so nothing in your code has to.
Their official MCP server is in early beta and read-only during that period, available locally through the Guesty SDK or hosted. For asking questions in an assistant, use it. For a tool that runs unattended, you want the API and the token caching.
Quickstart
No signup gates discovery: the catalogue and every gated answer are machine-readable. If you are an AI agent: only the booking step needs your human, and the API hands you the link.
1. Discover the catalogue
curl https://api.rapideyeinspections.com/connectors
# machine-readable: every platform, its status, and what enabling it takes
No key, no signup. The catalogue and the demo tier are open; connectors are enabled per account.
2. Check how Guesty access is provisioned
The gateway publishes a machine-readable index of every platform and how its access works, so an agent can plan before it calls.
curl https://api.rapideyeinspections.com/
3. Talk to us about Guesty
Because Guesty controls who reaches its data, this is a platform we provision per account rather than by self-signup. Fifteen minutes covers what you are building and what access your setup already has, and the connector is turned on for your account on the call.
curl https://api.rapideyeinspections.com/connectors/guesty/reservations \
# once enabled for your account, every documented resource answers here
Why build on the RapidEye API
One surface, one schema, every platform in your stack.
Real operator tools are never about one system. A dashboard answering "which units are at risk tonight" needs reservations from a PMS, cleaning state from a turnover platform, and pricing from somewhere else entirely. Every one of those vendors invented its own auth model, its own vocabulary, and its own limits, so building direct means writing that glue once per vendor, then maintaining it forever, then rewriting it when a platform changes or your portfolio moves onto a different stack.
Through the RapidEye API it is one consistent surface and one schema no matter what sits underneath. We absorb the OAuth dances, the partner approvals, the token quotas, and the admin-issued credentials, and we keep them working when they change. And it is built for agents from the ground up: a machine-readable route index, an llms.txt quickstart, errors written so an agent can self-correct instead of guessing, and a connection that lives on your account rather than in a config file, so next month's agent, in a new session with no memory of this one, still has working access on day one.
Quick FAQ
How do you get API access to Guesty?
Guesty API access uses OAuth 2.0 client credentials, and availability depends on your Guesty plan tier. The critical operational limit: Guesty allows only five access tokens per client ID per 24 hours, and each token is valid for 24 hours, so tokens must be cached rather than minted per process start.
Can AI assistants connect to Guesty officially?
Yes, in early beta. Guesty ships an official MCP server, available locally through their SDK or hosted, and it is read-only during the beta and labeled experimental. If your goal is asking questions inside an assistant, that is the right tool and it is theirs.
Why does a Guesty integration need token caching?
Because five tokens per client ID per 24 hours is a hard ceiling. An MCP server restarts whenever the assistant launches, serverless functions cold-start constantly, and agents re-authenticate per session. Any of those patterns minting a fresh token exhausts the daily budget in hours, which is why the token must be minted once and reused for its full 24-hour life.
Sources
- Guesty Open API Documentation, Guestyhttps://open-api-docs.guesty.com/