How to connect Checktiv to Zapier for no-code identity verification

To connect Checktiv to Zapier without code, build a booking-to-message workflow that sends your guest a verification link, then review the verification yourself. Instead of copying the same request into every booking conversation, let Zapier handle message delivery while you keep control of the hosting decision.

Why this matters

A professional guest verification workflow has separate jobs: request verification, review the result, and decide what happens next. Sending the request completes only the first job. Your booking record should reflect that distinction.

Checktiv provides shared-link guest verification with no code required. Zapier belongs around that experience, connecting the booking event to the message that carries the link. This guide uses that approach rather than assuming a native integration or a verification-result trigger.

Checktiv is best for independent hosts who want zero-code, shared-link guest verification. The benefit is a straightforward guest request; the limitation is that message delivery does not tell you whether the guest completed verification.

For your 2026 workflow, keep the boundary clear: Zapier sends the request, and you review the verification before making a decision. That gives you a practical starting point without building your hosting process around an unconfirmed connection.

Before you start

• Accounts and access: Have access to your booking app, Zapier, your guest messaging account, and the guest verification account. You need permission to connect the booking and messaging apps and to review verifications.
• Materials: Prepare a verification link, a guest message, and a booking reference that lets you match the request to the reservation. The Checktiv setup journey is 3 steps in 5 minutes: sign up, get a link, and review the verification. Guest completion time is separate.
• The gotcha: Confirm the link's intended use before putting it into a reusable message. Do not assume a guest-specific link can be sent to every reservation. Also confirm that your booking and messaging apps support the events and actions you need in Zapier.

Use a booking record you control for testing. Keep the first test away from real guest communication, and use your own address or number as the destination. You should see the exact message a guest would receive before publishing anything.

Choose the booking event

Two adjacent workflows make sense, but they solve different problems. Start with a new booking unless an update is the specific point at which you need to request verification.

Use the new-booking workflow first. Add the update variant only after you can explain exactly which change should send a request and which changes should do nothing.

Booking trigger

Set up the reservation event

1. Create a new Zap in Zapier and open the Trigger step.
2. Choose your booking app in App. Select the supported booking event in Trigger event that matches your request timing.
3. Connect the booking account you use for guest reservations. Select any required property or account settings presented by that app.
4. Choose Test trigger and inspect the sample reservation. Confirm that it contains the guest contact information and a booking reference you can recognize.
5. Check the reservation's eligibility. Exclude cancellations, internal test records, and any booking category outside your verification process using the controls available in your workflow.

Expected result: The trigger produces a reservation record with the correct guest destination and enough booking information to identify the request later.

Do not map a contact field just because it contains an address. A reservation can include different contacts for the guest, booking contact, and property team. Read the sample record and choose the person who should receive your verification request.

For the 2026 setup, write down the event you selected and what makes a reservation eligible. A plain-language rule is enough: send the request when a qualifying new booking arrives. If you cannot explain the rule without describing several exceptions, simplify the first version.

Check the booking reference

A booking reference connects the message to your hosting work. Use a reference already present in the reservation record rather than inventing a new identifier inside the message.

You do not need to expose every booking detail to the guest. Include enough context for the guest to recognize the reservation, and retain the reference in your own booking notes or tracking process. Avoid adding unrelated personal information merely because the trigger supplies it.

Guest message

Configure the delivery action

1. Add an Action step and choose the messaging app you use for guest communication in App.
2. Select its supported send-message action in Action event. Connect the account that should send the request.
3. Map the guest's destination from the tested booking record. Use a test destination while building the workflow.
4. Add a short explanation, the verification link, and the relevant booking context. Confirm that the link is appropriate for the recipient before inserting it.
5. Choose Test step and read the delivered message on the receiving device. Open the link and check that it starts the intended verification experience.

Expected result: Your test destination receives a readable guest verification request with the intended link and recognizable booking context.

The message should answer three guest questions: why am I receiving this, what should I do, and who should I contact if I need help? Keep the tone welcoming. Verification is part of preparing for the stay, not an accusation.

Write a guest-friendly request

A useful message explains the action without making promises about the result. For example, ask the guest to complete identity verification for the reservation using the link provided, then direct questions back to your usual guest communication channel.

Do not say the guest is verified when the message is sent. Do not promise that completing the form guarantees acceptance. Your review comes after the guest's action, and the wording should preserve that sequence.

Keep sensitive identity information out of the booking message. Send the verification link rather than asking the guest to reply with an identity document or copy document details into the conversation.

Verify delivery before publishing

Run 1 test booking through the delivery action with a destination you control. Inspect the sender, recipient, booking context, message formatting, and link behavior. A successful action test is useful, but the delivered message is what your guest experiences.

If your messaging app requires a template or a particular channel, use that app's supported setup. Do not assume every send-message action accepts the same fields or formatting. Choose the delivery route you can inspect and support during an ordinary hosting day.

Verification review

Keep the hosting decision separate

1. Complete the test verification through the intended guest experience, following the account's supported testing process where available.
2. Review the verification in Checktiv and match it to the booking through the information your account provides.
3. Record the actual stage in your booking notes: request sent, verification awaiting review, or review completed. These are tracking descriptions, not assumed product status labels.
4. Decide what guest communication should follow your review. Keep this separate from the action that sends the initial request.
5. Return to Zapier and select Publish only after the trigger, destination, link, and message have passed your tests.

Expected result: You can trace a booking from request delivery to a reviewed verification without confusing a sent link with a completed check.

Your 2026 checklist should make the decision boundary explicit. A delivered message is evidence of delivery, not evidence of identity verification. A guest's response in the booking conversation also does not replace reviewing the verification itself.

*Message delivery and the hosting decision belong to separate stages.*

Checktiv guest verification gives you a shared-link starting point, while your review remains the control point. Keep a short operational note explaining where you review results and where you record the booking decision. That note helps you repeat the process consistently without adding more software steps.

Send a request when a booking is updated

The second workflow uses a booking update rather than a new reservation. Use it only if your booking app exposes the relevant update event in Zapier and supplies enough information to distinguish the change that matters.

1. Start a separate Zap with the booking app's supported update event.
2. Test the event using a booking change that should qualify for a verification request.
3. Apply a condition tied to the relevant booking stage, not simply the existence of any update.
4. Exclude reservations that already received the intended request, using the tracking method your connected apps support.
5. Reuse the approved message wording, but confirm the link's suitability for this reservation before sending it.

Expected result: A qualifying booking change sends a request, while unrelated changes and already-handled reservations do not.

Test 2 booking changes: one that should send the request and one that should not. If both send a message, the workflow is not ready. Fix the event or eligibility conditions before publishing the update variant.

The advantage is timing: you can request verification at the booking stage you chose. The trade-off is complexity. Updated reservations require clearer exclusion rules than a simple new-booking workflow, so keep this variant out of your first setup unless it solves a specific operational need.

Troubleshooting

The booking app or event is not listed

Use only the apps and events available to your Zapier account. Do not substitute an unrelated event just to finish the setup. Keep sending the shared link through your existing guest communication process until a supported connection meets your requirements.

The message reaches the wrong person

Inspect the destination mapping against the trigger's sample record. Replace the booking contact or property-team field with the intended guest contact field, then repeat the delivery test using a destination you control.

The guest receives repeated requests

Inspect the trigger history and the booking changes that initiated each run. Tighten the eligibility rule and exclude already-handled reservations using a supported tracking method. Do not rely on the guest to identify which repeated message is current.

The link opens an unexpected request

Stop the affected delivery workflow and confirm the link's intended recipient and reuse rules. Replace it only after checking the correct destination in the verification account. Test the corrected message before restarting delivery.

A sent request is recorded as verified

Correct the tracking rule. Keep message delivery and verification review in separate stages, and record completion only after reviewing the actual verification. A send-message action cannot establish the guest's verification outcome.

Customize your workflow

Make the first version dependable before adding more steps. For a 2026 guest verification workflow, the useful expansion is clearer timing and follow-up, not a longer chain of actions.

• Best for multiple properties: Include recognizable reservation context so guests understand which stay the request concerns.
• Best for shared hosting duties: Document who reviews verification and where the hosting decision is recorded. Do not assume everyone who sees a booking has verification-account access.
• Best for follow-up: Check the actual verification stage before sending another request. A reminder should not be triggered solely because the first message was delivered earlier.

For the hospitality process around the link, read the identity verification guide for short-term rental hosts. Keep the guest experience consistent even when your booking channel changes.

One last thing

Test the message that should not be sent. A workflow that delivers the right request still needs to leave excluded bookings alone. Before your 2026 launch, test an ineligible reservation and confirm that it produces no guest message.

Related guides

• Connect guest verification to Guesty
• Connect identity verification to Hostaway
• Identity verification software ranked by accuracy