Guesty integration

View as Markdown Open in ChatGPT Open in Claude

The Guesty integration starts an identity verification automatically when a reservation is confirmed in your Guesty account. You connect once, choose the workflow the verification runs, and each confirmed reservation starts a verification for the guest without any manual step. The guest’s verification link is written straight onto the reservation, and the verification’s status is mirrored there as it progresses, so your team sees it where they already work.

This page covers the Guesty integration specifically. For the full list of available integrations and how connections work in general, see the Integrations overview.

When to use

Connect Guesty when you want reservations to trigger identity verification on their own, instead of adding each guest by hand or through the API. It suits teams that:

Take reservations in Guesty and want every confirmed guest verified before arrival.
Want the verification link and its live status visible on the reservation record, so reviewers and front-desk staff do not switch tools.
Want to control which reservations get verified (for example, skip a particular channel or status) with routing rules rather than code.

If you only verify guests occasionally, or you drive verification from your own system, the API or a bulk CSV import may fit better. You can use the integration alongside either.

How it works

Once connected, the integration runs on its own:

A reservation event arrives. Guesty sends a webhook to a private, per-connection address whenever a reservation is created or updated, including when it is canceled.
The reservation status decides the action. The integration reads the reservation and acts on its status (see the table below). A confirmed reservation starts a verification; a pre-commitment or pre-payment reservation is skipped; a canceled reservation withdraws any verification still in progress.
A verification is started. For a reservation that should be verified, the integration starts a verification bound to the workflow you chose when connecting. The guest’s name, and their email and phone when present, are carried onto the applicant so reviewers can identify them in the console. The reservation’s confirmation code is stored as the applicant’s external reference.
The guest is invited. By default, the platform emails the guest their verification link. You can turn this off if you would rather send the link yourself from Guesty using the link field described below.
The link and status are written back. The verification link and an internal review link are written onto the reservation the moment the verification starts. The status field is then kept in step with the verification as it moves through review to a final outcome.

What each reservation status does

The integration decides what to do from the reservation’s status. This is the default behavior for a new connection:

Reservation status	What happens
`confirmed`	Starts a verification for the guest.
`inquiry`, `reserved`	Skipped by default. These are held or pre-commitment bookings, not a committed stay.
`awaiting_payment`	Skipped by default. The guest is verified once the booking is confirmed, not before payment clears.
`canceled`, `closed`, `declined`, `expired`	Treated as canceled. A verification for the reservation that has not yet completed is withdrawn.
Any other status	Skipped. An unrecognized status never starts a verification by mistake.

Only the verification link, the review link, and the verification status are ever written back to Guesty. No applicant personal data is sent to Guesty.

Connecting Guesty

You need the Owner or Admin role, an active organization, and at least one workflow template to bind the connection to. Create a workflow first if you do not have one; the connect form links you to the workflow editor when none exist.

You connect using one credential: an integration token you generate from your Guesty account.

In your Guesty account, open the Marketplace, connect this integration, and generate an integration token. Generate it right before you connect: the token is single-use and expires a few hours after you create it (about four hours).
In the console, open Integrations and choose Guesty.
Paste the integration token. Do this promptly and finish the form without much delay, because the token is single-use and short-lived.
Choose the default workflow the integration runs for each reservation. This is required. Every verification the connection creates uses this workflow unless a routing rule sends the reservation elsewhere. The list shows your active workflows, with your organization default marked.
(Optional) Add routing rules to change which reservations are verified. The connection starts with a rule that skips inquiry and awaiting-payment reservations; you can keep it, edit it, or remove it, and add rules of your own. Each rule matches a field (such as the booking source or status) against one or more values, and skips a reservation that matches.
(Optional) Set the guest invite toggle. It is on by default, so the platform emails each guest their verification link. Turn it off only if you plan to send the link yourself from Guesty using the written-back link field.
Select Connect. The button stays disabled until a workflow is chosen and the token is filled.

On a successful connect, the platform exchanges the integration token for durable credentials, registers the reservation webhook in your Guesty account, and creates the custom fields it writes back into (see below). The connection then appears in your Integrations list.

Fields we set in Guesty

The integration provisions three custom fields on your Guesty reservations when you connect, and fills them automatically as verifications progress. All three are reservation-scoped text fields and are visible in Guesty.

Field name	When it is set	What it holds
`verificationLink`	When the verification starts	The guest’s durable verification link. Share this with the guest if you send invites yourself.
`verificationReviewLink`	When the verification starts	An internal link your team uses to open the verification in the console. Not for the guest.
`verificationStatus`	When the verification starts, then updated as it progresses	The verification’s current status for the reservation’s guest, moving from in-progress through review to the final outcome.

A few details worth knowing:

The two link fields are filled the moment a verification starts, so the guest link is available on the reservation right away. The link written to verificationLink is durable and reusable: it is safe to keep on the reservation, it does not expire the way a one-time link does, and it is reused if the reservation is updated.
The status field tracks the verification live. It is set when the verification starts and updated as the verification moves through its stages, so the reservation always reflects the current status, ending on the final outcome.
These fields only ever carry the links and the status. They never carry the guest’s personal details.
The written-back result lands on the exact reservation the verification came from, so a status cannot be recorded against the wrong booking.

Troubleshooting

Connecting failed, or the token was rejected. Guesty integration tokens are single-use and expire a few hours after you generate them. A token that already failed once, or that sat unused past its expiry, cannot be reused, even if the failure looked unrelated to the token itself. Go back to Guesty’s marketplace, generate a fresh integration token, and try connecting again.

The connection shows “Reconnect needed.” The stored credentials are no longer valid, usually because the connection was disconnected in Guesty or access was revoked. Open the integration, choose to reconnect, generate a fresh integration token in Guesty’s marketplace, and paste it in. Your workflow, routing rules, and invite setting carry over.

A reservation did not create a verification. Check, in order:

The reservation status. Only confirmed reservations are verified by default. An inquiry, reserved, or awaiting-payment reservation is skipped until it is confirmed, and a canceled reservation is never verified. See the status table above.
Routing rules. A reservation that matches a skip rule is intentionally not verified. Review the connection’s rules, including the rule that skips inquiry and awaiting-payment reservations, against the reservation’s fields (for example, its status or booking source).
The reservation event. The integration acts on reservation events from Guesty. A reservation created outside the connected account, or before the integration was connected, will not have triggered one.
The workflow. The connection must be bound to an active workflow. If the bound workflow was deactivated, reconnect and choose an active one.

The custom fields are missing in Guesty. The three fields are provisioned automatically when you connect. If they are absent, reconnect the integration to recreate them. Do not rename or remove them in Guesty, or the write-back cannot be delivered.

A guest did not receive their invite. Confirm the guest invite toggle is on for the connection. If you turned it off, the platform does not email the guest; you are expected to send the link yourself using the verificationLink field written onto the reservation. Also confirm the reservation carried a guest email, since there is no address to send to otherwise.

The status is not showing on the reservation. The status field (verificationStatus) is written when the verification starts and updated as it progresses. If a reservation started a verification but the field is empty, confirm the custom field still exists in Guesty under its original name; reconnect the integration to recreate it if it was renamed or removed. If no verification started, check the reservation status and routing rules above first.

You want to stop the integration. Disconnecting the connection removes the reservation webhook in Guesty and stops all further write-backs. Verifications that already started are unaffected. To start again later, reconnect with a fresh integration token.