import { Aside, Steps } from '@astrojs/starlight/components';

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](/guides/integrations).

## 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](/guides/verification/create-a-verification) or a [bulk CSV import](/guides/verification/bulk-import-csv) may fit better. You can use the integration alongside either.

## How it works

Once connected, the integration runs on its own:

1. **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.
2. **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.
3. **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.
4. **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.
5. **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. |

<Aside type="note" title="Which reservations create a verification">
The skips for `inquiry`, `reserved`, and `awaiting_payment` come from a routing rule that is added for you when you connect. You own that rule: you can edit or remove it, and you can add rules of your own (for example, to skip a particular booking channel). A `confirmed` reservation is always verified unless one of your routing rules skips it. Canceled reservations are handled without a rule: a cancellation converges the matching verification rather than starting a new one.
</Aside>

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](/guides/workflows/workflow-templates-create) 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.

<Steps>

1. In your Guesty account, open the [**Marketplace**](https://app.guesty.com/integrations/partners/autohost), 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).

2. In the console, open **Integrations** and choose **Guesty**.

3. Paste the **integration token**. Do this promptly and finish the form without much delay, because the token is single-use and short-lived.

4. 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.

5. (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.

6. (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.

7. Select **Connect**. The button stays disabled until a workflow is chosen and the token is filled.

</Steps>

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.

<Aside type="caution" title="A token cannot be reused">
The integration token is single-use: once it has been submitted, whether the connect attempt succeeded or failed, that same token cannot be used again. If connecting does not go through, generate a fresh integration token in Guesty's marketplace and try again rather than retrying with the same one.
</Aside>

<Aside type="tip" title="Reconnecting">
If your Guesty connection needs reconnecting, for example after it was disconnected in Guesty, open the integration, choose to reconnect, generate a fresh **integration token** in Guesty's marketplace, and paste it in. Your workflow choice, routing rules, and invite setting are preserved through a reconnect.
</Aside>

## 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.

<Aside type="caution" title="Do not rename or remove these fields">
The integration finds these fields by name (`verificationLink`, `verificationReviewLink`, `verificationStatus`). If a field is renamed or deleted in Guesty, the matching write-back cannot be delivered. Reconnect the integration to recreate any missing field.
</Aside>

## 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](#what-each-reservation-status-does) 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.

## Related

- [Integrations overview](/guides/integrations)
- [Create a verification workflow template](/guides/workflows/workflow-templates-create)
- [Glossary](/glossary)