import { Aside, Code } from '@astrojs/starlight/components';
import { apiOrigin, supportEmail } from '../../../lib/docs-env';
Checktiv replaces identity verification from Autohost. This guide is for product managers and developers who built on the Autohost SDK (`AutohostSDK`), the hosted Guest Portal, or the Autohost Data API (`data.autohost.ai`). It tells you what changes, what stays the same, and how to move each part of your integration.
## Which parts apply to you
| You use | Read |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| Only an Autohost connection to Guesty, Hostaway, or Track | [Integrations](/guides/integrations) first. A Checktiv integration can replace your code. |
| The Autohost SDK in your applicant pages | [Step 3](#step-3-start-verifications-on-your-server) and [Step 4](#step-4-replace-the-autohost-sdk-in-your-applicant-pages) |
| The hosted Guest Portal, as a link or in an iframe | [Step 3](#step-3-start-verifications-on-your-server) and [Replace an embedded Guest Portal](#replace-an-embedded-guest-portal) |
| The admin components (`ReservationResults`, `SexOffenders`) | [Step 5](#step-5-replace-the-admin-components) |
| The Data API from your server | [Step 6](#step-6-change-endpoints-and-fields) and [Step 7](#step-7-rewrite-your-webhook-receiver) |
| The reseller APIs, for many host accounts | [Partners with many host accounts](#partners-with-many-host-accounts) |
| You are a product manager | [Overview](#overview), [What changes for your team](#what-changes-for-your-team), and the [checklist](#migration-checklist) |
## Overview
### Timeline
The Autohost SDK, the hosted Guest Portal, and the Autohost Data API reach end of life before October 2027. Plan to finish your migration by April 2027.
After the end-of-life date:
- The Autohost API hosts are turned off. Every call to the Autohost Data API and the Autohost SDK fails.
- Guest Portal links stop working, including links you already sent to applicants.
- Autohost sends no more webhooks.
Until that date, your Autohost integration keeps working. You can move to Checktiv at any time before it, and you can run both at the same time while you move.
### What happens to your Autohost data
We copy your Autohost reservations and part of their verification data, including ID images, into your Checktiv organization. Each copied reservation becomes a verification with the decision Autohost recorded. The `external_id` of its applicant is the Autohost reservation id. See [Link copied reservations to your bookings](#link-copied-reservations-to-your-bookings).
We do not copy verification reports or signed e-signature documents (PDFs). Download each report and signed document you must keep before the end-of-life date.
We copy your data into the US region. If your applicants' data must stay in the EU, create your organization in the EU region. Then email support@autohost.ai before we copy your data, and name that organization.
### What you get
Checktiv covers most of the identity verification and screening checks that the Autohost SDK and Data API offered. The table in [Map Autohost checks to Checktiv checks](#map-autohost-checks-to-checktiv-checks) shows the Checktiv check to use in place of each one. You also get:
- **US or EU data residency.** You pick the region when you sign up. Your applicants' data stays in that region.
- **A test mode with predictable results.** A test-mode key creates free, synthetic verifications. You choose whether each one passes or goes to review.
- **Signed webhooks.** Every delivery carries an HMAC signature and a stable event id. You can replay a delivery from the console.
- **A workspace reviewer.** Your staff approve or decline a verification inside your own admin dashboard. Each token carries only the capabilities you grant.
- **Workflow templates.** You configure the checks once, in the console or over the API, and reuse them by id.
- **Types, React, and cross-device capture.** The npm package ships TypeScript types and a React wrapper. An applicant on a desktop can move to a phone for document capture.
- **Ready-made integrations** for Guesty, Hostaway, and Track. See [Integrations](/guides/integrations).
### What is not part of Checktiv
Checktiv is an identity verification and screening platform. These Autohost features have no Checktiv equivalent:
| Autohost feature | What to do |
| ---------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| Security deposits, payment validation, damage waivers (`GET /reservations/{id}/payments`, `POST /reservations/{id}/payment-event`) | Keep these in your own checkout. Checktiv does not take payments from applicants. |
| Guest messaging (Stargate, `GET /reservations/{id}/stargate`, `stargate_webhook_url`) | Send these messages from your own system. Checktiv can email the verification link: set `send_invite: true`. |
| Business rules that read the reservation details | Keep them on your server. Choose the workflow template before you create the verification. Screening rules cannot read your booking details. |
| The details read from the ID document (`identification`) | A verification does not return them over the API. To read the fields from ID images outside a verification, call `POST /v1/id-verification`. Your reviewers see the ID check in the workspace reviewer and the console. |
| Loyalty segments (`/loyalty/*`, `loyalty_segments`) | No equivalent. Remove these calls. |
| Tenant eviction search (`/tenant-evictions/*`) | No equivalent. Remove these calls. |
| Your own blocklist, social verification, authority reporting | No built-in equivalent. Keep this logic in your own system. To act on a list of known emails, add a screening rule on `applicant.email` with the `in` operator. |
| Standalone lookups (`/lookup/*`, `/validate/*`, `/predict/*`, `/fraud/analyze`, `/global-watchlist/*`, `/background-check/*`) | No standalone equivalent. Run screening inside a verification. See [Map Autohost checks](#map-autohost-checks-to-checktiv-checks). |
## What changes for your team
Some of your integration stays the same:
- **Your decision logic.** Your code still decides which bookings need a verification. Checktiv does not need your listings.
- **Your tiers.** If riskier bookings get more checks, keep that logic on your server. Create one workflow template per tier, then send the id of the template you chose.
- **Your state management.** You still store the verification id next to your booking, and you still update the booking when the result arrives.
Plan for this new work:
- **A server route that starts the verification.** The Autohost SDK started from a reservation id in the browser. Checktiv starts from your server, which returns a token to the browser. This route must check that the caller is the applicant for that booking.
- **The template decides the steps.** The workflow template decides the steps and their order. The SDK shows one step at a time. After each step, your page reloads or mounts the SDK again to show the next one. A progress bar you built around your own pages must change.
- **Workflow templates.** You create one template for each tier. A document the applicant signs belongs to a template, so different agreement text means a different template.
- **Booking rules stay on your server.** Screening rules in a template read the applicant, the check results, and the fraud signals. They cannot read the dates, the price, or the source of a booking.
- **Translations.** The Checktiv SDK does not translate its screens for you. You pass your own translated text, and any text you leave out shows in English. See [Translations](#translations).
- **A fraud-signal disclosure.** Fraud signals start only after the applicant agrees to the disclosure you show.
- **A new webhook receiver.** It verifies a signature, reads one event type field, and fetches the verification.
- **A server route for the admin reviewer.** It mints a short-lived token pair for one staff member and one verification.
## Migration checklist
1. [Find every place that uses Autohost](#step-1-find-every-place-that-uses-autohost).
2. [Set up your Checktiv organization](#step-2-set-up-your-checktiv-organization): keys, workflow templates, and a webhook subscription.
3. [Start verifications on your server](#step-3-start-verifications-on-your-server).
4. [Replace the Autohost SDK in your applicant pages](#step-4-replace-the-autohost-sdk-in-your-applicant-pages).
5. [Replace the admin components](#step-5-replace-the-admin-components).
6. [Change endpoints and fields](#step-6-change-endpoints-and-fields).
7. [Rewrite your webhook receiver](#step-7-rewrite-your-webhook-receiver).
8. [Test each result in test mode](#step-8-test).
9. [Move your bookings in stages, then remove Autohost](#step-9-move-in-stages-then-remove-autohost).
## Concepts that changed names
| Autohost | Checktiv |
| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Reservation (the container for a verification request) | **Session.** The API resource is `/v1/sessions` and the object is `verification_session`. |
| Guest (`guest` on the reservation) | **Applicant.** Send it inline as `applicant` on the create. The inline `applicant` can complete the identity information step; an `applicant_id` cannot. |
| Listing (`listing_id`, `/listings`) | **Not needed.** Send the transaction details in `metadata`. See [Map the create fields](#map-the-create-fields). |
| Guest Portal screens, risk colors, Screening Assistant | **Workflow template.** It lists the checks and their order. Its screening rules can send a verification to review. |
| Guest Portal URL (`guest_portal_url`) | **Verification link** (`applicant_url`). It opens the hosted journey. It cannot be shown in an iframe. |
| Custom Guest Portal domain | A [custom domain](/guides/organizations/custom-domains) for the verification link. |
| Host decision (`supervised`) | **Reviewer decision.** `outcome` is `approved` or `declined`, and `decision_source` is `reviewer`. |
| API key (`x-api-key` header) | **Secret key** (`ah_sk_...`) in the `Authorization: Bearer` header. |
| SDK key (used on your server to mint the admin `apiToken`) | **Secret key.** It mints the workspace token for the admin reviewer. |
| No key in the applicant pages | **Publishable key** (`ah_pk_...`). It is new, and it is safe to put in a page. |
| `sandbox: true` and the Autohost test hosts | **Test mode.** Use a test-mode key (`ah_sk_us_test_...`) against the same API host. |
| Reseller account with child host accounts | **One organization**, with each host's verifications marked by `tenant_ref`. See [Partners with many host accounts](#partners-with-many-host-accounts). |
| Autohost MCP server | [Connect an AI assistant](/guides/integrations/connect-ai-assistants) to your Checktiv organization. |
## Step 1: Find every place that uses Autohost
Search your code and your configuration for `autohost.ai`, `autohost.ca`, `verifyhub.org`, `gueststay.in`, `AutohostSDK`, `x-api-key`, and `guest_portal_url`. Then check these places, which a code search does not find:
- Email, SMS, and booking-confirmation templates that contain a Guest Portal link.
- Guest Portal links that your database stores for future bookings. They stop working at the end-of-life date.
- Mobile apps that open a Guest Portal link.
- Scheduled jobs that read Autohost status.
- Your Content Security Policy and other allowlists.
Give this list to your AI assistant with your code.
## Step 2: Set up your Checktiv organization
1. In the console, open **Developers → API keys** and click **Create Key**. Select **Secret key** and give it these scopes:
| Scope | Why you need it |
| -------------------------- | ------------------------------------------------------------------------------------- |
| `sessions:write` | Create, cancel, and resend verifications, and add notes |
| `applicants:write` | Send applicant details inline on the create |
| `sessions:read` | Read verifications and their results |
| `sessions:read_report` | Download the PDF report and the evidence images |
| `sessions:workspace_token` | Mint tokens for the workspace reviewer in your admin dashboard |
| `applicants:read` | Read applicant records, and link copied reservations to your bookings |
| `sessions:browser_token` | Only if a template has a `custom_form` step, or you translate the signing or credit history screens. See [Translations](#translations). |
| `idv:write` | Only if you call `POST /v1/id-verification` |
See [Choosing scopes for your key](/developers/choosing-scopes).
2. Store the secret key where your server keeps the Autohost API key, for example a secrets manager. Never put it in a page.
3. Click **Create Key** again and select **Publishable key**. Add each origin that loads the SDK. The SDK does not render on an origin that the key does not list.
4. In **Workflows**, create one workflow template for each tier. See [Create a verification workflow template](/guides/workflows/workflow-templates-create).
5. Open **Developers → Webhooks** and click **New subscription**. You need the Owner or Admin role. Select these event types: `kyc.session.completed`, `kyc.session.manual_review_requested`, `kyc.session.cancelled`, `kyc.session.expired`, and, if a template has a signing step, `kyc.session.document_signed` and `kyc.session.document_declined`. A subscription receives events for one mode only, so create one for test mode now and one for live mode later.
6. If you show the admin reviewer, open **Developers → Workspace origin** and enter the `https` origin of your admin dashboard. It takes one origin.
### Partners with many host accounts
If you used the Autohost reseller APIs, we copy your data into one Checktiv organization. Each Autohost host account becomes a partition of that organization, marked by `tenant_ref`. The value is the Autohost user id of that host. If some of your hosts' data must stay in the EU, email support@autohost.ai before we copy your data.
- **Keys and webhooks** belong to the organization, one set for each mode. One secret key and one webhook subscription can serve all your hosts. Each key has its own rate limit, so a batch for one host spends the budget of every host that shares the key.
- **New verifications:** send the host's id as `tenant_ref` on the create. For a host from Autohost, send its Autohost user id. For a new host, send a stable id from your own system. Do not put personal data in it.
- **The workspace reviewer:** mint each workspace token with the host's `tenant_ref`. The reviewer then refuses a verification that belongs to another host.
- **The console** shows the verifications of all your hosts. There is no console login limited to one host, so a host's staff review in your admin dashboard, through the workspace reviewer.
- **Workflow templates** belong to the organization. If hosts need different checks or agreement text, create a template for each and name it after the host.
- **Routing results:** the webhook body does not carry `tenant_ref`. Read it from `GET /v1/sessions/{id}`.
- **Listing by host:** `GET /v1/sessions` does not filter by `tenant_ref`. Keep the host for each verification in your own database.
`POST /accounts/register`, `PUT /accounts/{id}`, `GET /accounts/children`, and `POST /accounts/signup` have no equivalent. To stop a host, stop creating verifications with its `tenant_ref` in your own code. If you are not a reseller, do not send `tenant_ref`.
## Step 3: Start verifications on your server
This step moves the start of each verification from the browser to your server. The Autohost SDK took a reservation id in the browser, and the reservation id was the only credential. The Checktiv SDK takes a client token that your server gets when it creates the verification. Your secret key stays on your server.
Before, with Autohost (browser):
```js
const client = await AutohostSDK.init({ reservationId: RESERVATION_ID });
```
After, with Checktiv (your server):
```js
// POST /api/verifications (your backend). Never call the Checktiv API from a browser.
import { regionToApiBase } from '@checktiv/sdk-web';
app.post('/api/verifications', requireApplicantForBooking, async (req, res) => {
const booking = req.booking; // set by your own access check
// Reuse the verification you already created for this booking.
// When you cancel a verification, clear the stored token first.
if (booking.checktivClientToken) {
res.json({ clientToken: booking.checktivClientToken });
return;
}
const response = await fetch(`${regionToApiBase('us')}/v1/sessions`, {
method: 'POST',
headers: {
Authorization: `Bearer ${process.env.CHECKTIV_SECRET_KEY}`, // ah_sk_*
'Content-Type': 'application/json',
'Idempotency-Key': `verification-${booking.id}-${booking.verificationAttempt}`, // a retry returns the same verification
},
body: JSON.stringify({
workflow_template_id: templateIdForTier(booking), // your own logic, for example one template per tier
applicant: {
given_names: booking.guestGivenNames, // an array, for example ["Mary", "Ann"]
family_name: booking.guestFamilyName,
email: booking.guestEmail,
phone: booking.guestPhone,
date_of_birth: booking.guestBirthDate, // YYYY-MM-DD
booking_name: booking.nameOnBooking, // compared against the ID when Name match is on
external_id: booking.id, // your own id, returned when you read the applicant
},
metadata: {
start_datetime: booking.checkIn, // ISO 8601 with an offset
end_datetime: booking.checkOut,
amount: booking.totalInMinorUnits, // 125000 means 1,250.00 in usd
currency: booking.currency,
location: booking.propertyAddress,
confirmation_code: booking.confirmationCode, // your own key
},
}),
});
if (!response.ok) {
logCreateError(booking, response.status, await response.json()); // keep the error on your server
res.status(502).json({ error: 'verification_unavailable' });
return;
}
const { data } = await response.json();
await saveVerification(booking, {
verificationId: data.id, // the id that webhooks refer to
clientToken: data.client_token, // returned only on this response
identityDetailsMissing: Boolean(data.warnings), // see the caution below
});
res.json({ clientToken: data.client_token, identityDetailsMissing: Boolean(data.warnings) });
});
```
`regionToApiBase('us')` returns `https://api.us.checktiv.com`, and `regionToApiBase('eu')` returns `https://api.eu.checktiv.com`. This sample calls the REST API directly because it needs the verification id. The `sessions.create` helper in the SDK returns only the client token.
Rules for this route:
- **Check the caller.** The client token resumes the applicant's verification. Return it only to the applicant for that booking, for example after you check a signed link or a login.
- **Store the client token.** The create returns `client_token` once, and a read never returns it again. Store it with the booking and return the stored value when the applicant comes back.
- **Send the identity details.** See the caution below.
- **Keep errors on your server.** A Checktiv error can describe your key's region or your request. Log it, and send the browser a short error of your own.
- **Use one region.** An EU organization uses `regionToApiBase('eu')` and EU keys. A key works only in its own region.
## Step 4: Replace the Autohost SDK in your applicant pages
### Remove the Autohost SDK
1. Delete the Autohost script tag. It looks like one of these:
```html
```
2. If you installed the Autohost package with npm, remove it:
```bash
npm uninstall @autohostai/autohost-sdk
```
3. Remove every call to `AutohostSDK.init`, `client.component(...)`, `client.verification.save`, `client.reservation.get`, `AutohostSDK.fraudCollector`, and `AutohostSDK.createSecuredToken`.
4. Remove every `autohost.ai` and `autohost.ca` host from your Content Security Policy and other allowlists. Also remove `verifyhub.org` and `gueststay.in` if you embedded the Guest Portal.
Do this one booking at a time. A booking with an Autohost verification in progress keeps the Autohost code until that verification ends. See [Step 9](#step-9-move-in-stages-then-remove-autohost).
### Install the Checktiv SDK
```bash
npm install @checktiv/sdk-web
```
Or load it from the CDN. The script sets `window.Checktiv` and registers every module:
```html
```
For production, pin a version and add a Subresource Integrity hash. See [Versioning](/developers/sdks/versioning). If your pages send a Content Security Policy or a Permissions-Policy, add the Checktiv origins. See [Security headers](/developers/sdks/security-headers).
### Mount the journey
Before, with Autohost:
```js
const reservation = client.reservation.get();
AutohostSDK.fraudCollector(
{ reservationID: reservation.id, listingID: reservation.lid, userID: reservation.hid },
{ sandbox: false },
);
client.component('IDV', { callbacks: { onIDVComplete: () => goToNextStep() } }).mount('#target');
await client.verification.save({ step: 'Finish', complete: true, data: {} });
```
After, with Checktiv:
```js
import { mount } from '@checktiv/sdk-web';
import '@checktiv/sdk-web/idv'; // identity verification
import '@checktiv/sdk-web/fraud'; // only if your templates use fraud signals
import '@checktiv/sdk-web/esign'; // only if your templates have an esign step
import '@checktiv/sdk-web/credit-history'; // only if your templates have a credit_history step
import '@checktiv/sdk-web/capture-ui/style.css'; // required: styles the capture screens
const handle = mount('#target', {
publishableKey: 'ah_pk_us_test_...',
resumeKey: bookingId, // an applicant who comes back resumes at the current step
fetchToken: () =>
fetch('/api/verifications', { method: 'POST' })
.then((res) => res.json())
.then((body) => body.clientToken),
onConsent: () => showFraudDisclosure(), // resolve true to start fraud signals, false to decline
onComplete: () => window.location.reload(), // the applicant submitted a step: reload to show the next one
onEvent: (event) => {
if (event.type === 'checktiv.idv.processing' && event.reason === 'no_renderable_step') {
showSubmittedScreen(); // nothing for the applicant to do on this step; the result arrives by webhook
}
},
onError: (error) => showError(error.code),
});
```
On the npm path, each step type needs its import. A step without its import stops the journey with `sdk_load_failed`. The CDN script registers every module, so it needs no imports.
What changes:
- **The template decides the steps.** You do not mount each step yourself, and you do not call `save` for each step. Each mount shows the applicant's current step.
- **Reload after each step.** `onComplete` fires each time the applicant submits a step. The journey does not move to the next step by itself: reload the page, or mount again, to show it. When there is nothing for the applicant to do, for example after the last step, the mount reports `checktiv.idv.processing` with `reason: "no_renderable_step"`. Show your own "submitted" screen then.
- **No finish call.** Submitting the last step ends the applicant's part, and you send no completion signal. Remove `complete: true` from the `save` call that carried it.
- **Fraud signals need consent.** `onConsent` must resolve `true`. A callback that resolves `false`, resolves nothing, or throws keeps fraud signals off, and the SDK reports no error. With `mount`, you do not call a fraud collector yourself. Autohost recommended calling its collector at least twice.
- **`onComplete` is not a result.** It carries no ID data and no verdict. Get the outcome from the webhook or from `GET /v1/sessions/{id}` on your server.
- **Desktop-to-phone capture.** To offer it, also import `@checktiv/sdk-web/idv/cross-device`, pass `crossDeviceCopy`, and call `handle.openCrossDevice()` from your own button. See [Cross-device handoff](/developers/sdks/cross-device).
For React, use ``. It takes the same options. See [React](/developers/sdks/react).
### Replace an embedded Guest Portal
If you showed the Guest Portal in an iframe (`verifyhub.org/{id}?embed=1`, or `gueststay.in` in test), mount the SDK in its place, as shown above. The Checktiv verification link cannot be shown in an iframe: the hosted journey refuses to load inside another site's page.
| Autohost Guest Portal embed | Checktiv |
| -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| `