Hospitable opens rental agreements to its API, but partners only get to see whether one is signed

Hospitable has exposed its rental agreements through the API, the MCP server and webhooks. How much you can actually read depends on which door you come through, and that distinction is the whole story.

Nik Logachev of the Hospitable team posted the change on 20 October, calling it a frequently requested improvement from the community.

What you get

Reservations now carry a rental agreement summary: the agreement name, its ID, and whether it has been signed. That summary is available both to personal access tokens and to API vendors, which means a connected third party tool can see the signing status of every booking.

Summaries stop there. They do not include the filled fields or the content of the agreement.

For that you need a personal access token, which unlocks a separate endpoint returning the filled fields, the agreement content with the filled information in place, and a URL to download the PDF.

A new agreements endpoint lets you search the summaries by reservation or by signing status. Webhooks on reservations now include the summary when an agreement is created or signed, though Hospitable says webhooks do not carry the filled fields "for now".

The line that matters

A personal access token is you, acting on your own account. An API vendor is the software company whose tool you have connected.

So an integration partner can build you a dashboard showing which guests have not signed, and can trigger a chase message the moment a booking appears without a signature. That is genuinely useful and it is the common case.

What an integration partner cannot do is pull the signed document. If you wanted a third party tool to file signed agreements into your document store, attach one to a damage claim, or hand one to an insurer or an owner, that tool cannot fetch the PDF. Only a script running on your own personal access token can.

Whether that is a deliberate privacy boundary or a gap still to be closed, Hospitable does not say. The "for now" on the webhook limitation suggests the surface is still being filled in.

What it means for operators

If you do nothing, nothing changes. Agreements keep working as they did.

If you run any automation of your own, this is the piece that was missing. Signing status on the reservation object means your rules can finally treat an unsigned agreement as a condition, so you can hold a door code, delay a check in message or flag an arrival for the morning briefing until the agreement is signed. Doing that before this change meant checking by hand.

The MCP side is the quieter addition. Hospitable has been steadily widening what an AI assistant can read from the account, with owner statements in early October and availability and pricing rules a few days before this. Agreements add another slice, so asking an assistant which of this week's arrivals have not signed is now a question it can answer.

One caveat for anyone planning on the PDF endpoint. Personal access tokens are credentials tied to your account, so a script that downloads signed agreements is handling both a long lived credential and documents containing guest personal data. That belongs in something with proper secret storage, not in a spreadsheet macro on a front desk machine.