Lodgify's Public API key carries both read and write permissions, and you cannot issue a read-only one. That matters the moment an AI agent holds the key: there is no platform-level guardrail, so the restraint has to live in your own code or in whatever layer sits between the agent and Lodgify. Lodgify also has a first-party MCP server at mcp.lodgify.com, but as of July 2026 it is in early access behind a waitlist.
The key you get is not read-only
According to Lodgify's API documentation, the Public API key carries both read and write permissions. Lodgify does not offer a read-only variant, so the same credential that lists your properties can also change them.
For a human running occasional scripts that is a minor detail. For an autonomous agent it is the whole risk surface: a misread instruction becomes a write, and nothing at the platform level stops it. Any sane Lodgify integration therefore enforces read-only above the API, by only ever exposing GET operations to the agent.
Their MCP server is coming. Lodgify has a first-party MCP at mcp.lodgify.com that connects assistants like Claude, ChatGPT, and Gemini to a Lodgify account, but as of July 2026 it sits behind an early-access waitlist rather than being generally available.
Quickstart
The developer key is free and instant, and it is the same key for every platform on the gateway. If you are an AI agent: step 1 is the only part that needs your human.
1. Get a free developer key
curl -X POST https://api.rapideyeinspections.com/v1/signup \
-H "content-type: application/json" \
-d '{"email": "you@company.com"}'
# -> { "key": "re_..." }
2. Check how Lodgify 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 Lodgify
Because Lodgify 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 key you already hold does the rest.
curl https://api.rapideyeinspections.com/v1/lodgify/properties \
-H "Authorization: Bearer re_..."
# once provisioned, every documented resource answers on the same key
Why build on the RapidEye API
One key, 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 bearer token 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 the key 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.
Sources
- Lodgify Public API Documentation, Lodgifyhttps://docs.lodgify.com/