TL;DR
- Checktiv is best for independent hosts who want zero-code guest verification through shared links.
- Use the Checktiv Hospitable integration workflow to connect booking messages with a separate verification review.
- Sending a verification link does not confirm completion or approve a reservation.
- Keep guest verification, your hosting decision, and guest registration as separate checkpoints.
Instead of rewriting verification instructions for every reservation, use a shared-link handoff: send the guest verification link in the Hospitable booking conversation, then review the verification before making your hosting decision. A Checktiv Hospitable integration built around this workflow keeps guest communication straightforward without treating a sent message as a completed check.
Why this matters
A verification request is only useful when you can connect the result to the right reservation. Otherwise, you are left searching conversations, checking whether someone responded, and deciding what to send next.
Checktiv provides guest verification through shared links, with zero code required. Hospitable supplies the booking-conversation context for this guide. The workflow connects your operating steps; a shared link alone does not synchronize reservation records or verification results.
For your 2026 hosting process, define success as a reviewed verification attached to a clear booking decision. Message delivery is an earlier checkpoint, not the finish line.
Before you start
- Get access to both workspaces. You need a guest verification account and permission to manage the relevant booking conversations in Hospitable. Keep a reservation available so you can check the complete handoff before using it more widely.
- Prepare your guest instructions. Decide who needs to complete verification, when you will request it, and who will review the result. Check the applicable booking-channel rules before adding an off-platform verification step.
- Plan the reservation match. Do not assume a shared link carries the booking reference or returns completion information to Hospitable. Establish how you will associate the verification with the correct guest and reservation before sending requests.
The product's introductory journey is three steps in five minutes: sign up, get a link, review the verification. Treat that as a setup journey, not a promise that every guest will finish within five minutes.
Prepare 1 test reservation before sending requests to live guests. That gives you a controlled place to check the message, link, matching process, and review responsibility.
Guest request setup
Define the verification checkpoint
- Choose the point in your booking process when you will request verification. Make the request early enough for the guest to understand what is required and for you to review the result.
- Specify who should complete the request. Use the same rule across comparable bookings rather than changing the requirement from conversation to conversation.
- Assign a reviewer. If more than one person handles guest messages, identify who checks the verification and communicates the next step.
- Write down what happens after review. Separate a completed verification from your decision to accept the booking or continue check-in preparations.
Expected result: You have a defined request point, a responsible reviewer, and a clear next action. Nobody needs to infer the booking decision from the presence of a link.
Prepare the shared link
- Sign in to Checktiv and obtain the shared verification link for your intended guest-verification workflow.
- Copy the link without shortening it or changing its contents. Keep the guest-facing destination clear.
- Prepare a test message in your own working document before placing it into a live booking conversation.
- Confirm how you will match the resulting verification to the reservation. Do not add sensitive identity information to the message as a substitute for a proper match.
Expected result: You have a verification destination and a matching method ready before the first guest receives a request.
For your 2026 setup, record the matching method alongside your guest-message procedure. A process that only one team member remembers is difficult to repeat consistently.
Hospitable message setup
Write the guest request
- Open the relevant reservation conversation in Hospitable and confirm that you are addressing the intended guest.
- Introduce the request in ordinary hospitality language. Explain what the guest needs to do and how it fits into your booking process.
- Insert the shared verification link into the message. Keep the action separate from unrelated arrival details so the guest can find it easily.
- Read the complete message before sending it. Remove any wording that promises approval merely for opening or completing the link.
Use this draft as a starting point, adapting it to the requirements you have already disclosed:
Hi, thanks for booking your stay. Please complete our guest verification using the link below so we can review it as part of your booking process. If you have trouble opening the link, reply here and we’ll help with the next step.
Insert your actual verification link beneath the message. Do not replace it with an identity-document upload request in the conversation.
Expected result: The guest receives one understandable request with a clear action and a way to ask for help.
Check the message handoff
- Use your test reservation to inspect the message as a guest would read it. Confirm that the link is visible and that the surrounding explanation makes sense on its own.
- Open the intended verification destination through your controlled test process. Confirm that you have not pasted a host-only page or an unrelated account link.
- Check the reservation reference in your working record. Make sure you can distinguish this request from another booking by the same guest.
- Review the verification through the verification service rather than interpreting a reply in Hospitable as evidence of completion.
Expected result: The booking conversation leads to the intended guest task, and you know where the reviewer will check the outcome.
For a 2026 workflow, keep 2 separate message drafts: the initial request and a follow-up. These are operating materials to prepare, not claims about built-in message templates.
Verification review and booking decision
Complete the review loop
- Check whether the guest has completed the verification. A message saying they finished is a prompt to review, not a replacement for review.
- Match the verification to the intended guest and reservation using the method established before sending.
- Review the information presented and make your hosting decision according to your disclosed requirements and applicable rules.
- Record the operational outcome in the booking record you maintain. Keep the note limited to what the hosting team needs to know.
- Send the guest the appropriate next-step message. Do not leave a completed request sitting without acknowledgement.
Expected result: The reviewer has connected the result to the reservation, recorded a decision, and told the guest what happens next.
Keep three checkpoints distinct: Link sent, Verification reviewed, and Booking decision. These are suggested working labels, not product interface labels or a claim that either service creates them for you.
*Sending the request starts the process. Review comes before the booking decision.*
For your 2026 operating checklist, name the person responsible for moving each reservation through these checkpoints. Clear ownership prevents two people from sending conflicting instructions.
A second workflow: follow up after a booking changes
A changed reservation creates a different question from an incomplete verification. First determine whether the change affects the person you need to verify.
Best for an unchanged lead guest: Review the existing request before sending another. Best for a different lead guest: Reassess who must complete verification and issue the appropriate request under your policy.
| Workflow | Best for | Advantage | Limitation |
|---|---|---|---|
| Initial shared-link request | A booking awaiting its first verification request | Establishes a clear action in the booking conversation | Still requires a separate result review |
| Follow-up on an existing request | An unchanged guest who has not completed the process | Keeps the conversation focused on an outstanding task | Requires checking that the request is still outstanding |
| Fresh request after a guest change | A reservation now associated with a different person | Aligns verification with the person you intend to host | Requires another matching and review step |
For the follow-up workflow:
- Reopen the reservation and confirm what changed.
- Check the existing verification before sending another message.
- Decide whether the original request still applies to the intended guest.
- Send either a concise reminder or an explanation of the new request.
- Review the outcome before updating the booking decision.
Expected result: You respond to the actual booking change rather than sending every guest through the same request twice.
Keep verification separate from local reporting obligations. In Spain, automated guest registration concerns a different operational task from reviewing a guest’s identity verification; organize those checkpoints separately rather than treating either one as proof that the other is complete.
Troubleshooting
The guest received a message but has not completed verification
Check the verification service before sending a reminder. If the request remains incomplete, reply in the existing booking conversation with one clear action.
Avoid stacking several requests into the follow-up. Ask the guest to complete the verification, and keep arrival instructions in their appropriate place.
The link opens the wrong destination
Return to the source of the shared verification link and copy it again. Replace the incorrect link in your working message draft, then test the destination before sending a correction.
Do not ask the guest to send identity documents into the booking chat to work around a link problem. Restore the intended verification path.
You cannot match a result to the reservation
Pause the booking decision and check the guest and reservation details against your matching procedure. A similar name alone is not a reliable operating method.
Resolve the mismatch before recording completion. Then improve the procedure so the next reviewer does not face the same ambiguity.
A guest receives duplicate requests
Review the conversation and existing verification before sending anything else. Check whether another team member already issued the request or whether a reservation change prompted a second message.
Assign one owner for the next response. Tell the guest which request to use only after confirming the intended verification destination.
Hospitable does not show the verification outcome
Review the result in Checktiv rather than assuming the booking conversation will display it. A shared-link handoff does not itself establish a return path for results.
Record the hosting decision in your booking process after review. Do not describe this link-based workflow to your team as a fully synchronized connection.
Customize your workflow
Expand consistency before adding more steps. Start with a repeatable request, a reliable reservation match, and an assigned reviewer. Those are the foundations of a professional guest experience.
Use your 2026 review checklist to inspect 1 complete test booking from request through decision whenever you change the message or handoff. Check both the guest-facing wording and the reviewer’s ability to find the correct result.
For hospitality-specific scope, use the ID verification guide for short-term rental hosts to keep your procedure focused on guest verification rather than unrelated screening tasks.
The shared-link approach gives you zero-code setup and direct control over review. Its limitation is equally important: you remain responsible for connecting the booking conversation, verification result, and hosting decision.
One last thing
Test the reviewer’s job, not just the guest’s link. A working link proves the guest can reach the request. A complete workflow proves you can find the right result, connect it to the reservation, and confidently communicate the next step.
Related guides
- How document verification detects forged IDs
- How long an ID verification check takes
- Can guest screening prevent property damage claims?
Frequently asked questions
How do I set up a Checktiv Hospitable integration without coding?
Use a shared verification link in the Hospitable booking conversation, then review the verification separately. Establish how you will match the result to the reservation before sending the request.
Does sending a verification link approve my guest?
No. Sending a link starts the request; you still need to review the verification and make the hosting decision.
Will the verification result appear inside Hospitable?
Do not assume a shared-link workflow returns results to Hospitable. Review the verification in the verification service and record the booking decision in your operating process.
Should I send another request when a reservation changes?
Check whether the change affects the person being verified before sending another request. An unchanged guest and a replacement lead guest require different decisions.
What should I say in the guest verification message?
Explain the requested action, how it fits into the booking process, and where the guest can ask for help. Keep the link easy to find and avoid promising approval before review.
How long should I allow for setup?
The introductory product journey is three steps in five minutes: sign up, get a link, review the verification. Testing the Hospitable handoff and your reservation-matching procedure is a separate task.
Is identity verification the same as guest registration?
No. Identity verification and guest registration are separate tasks, so completing one should not be treated as evidence that the other is complete.
