Integrations

An integration connects one of your existing systems to Checktiv so that identity verification starts on its own. When the connected system creates or updates a record, such as a reservation, Checktiv picks it up, starts a verification, and can invite the person to complete it, all without anyone opening the console. You manage integrations from Dashboard → Integrations.

When to use integrations

Use an integration when the event that should trigger a verification already happens in another tool you run. Instead of exporting a list and starting verifications by hand, or building against the API yourself, you connect the system once and every new record it creates starts a verification automatically.

This suits teams that:

• Take new bookings, reservations, or customer records in a system Checktiv can connect to, and want each one verified.
• Prefer a no-code setup over writing against the REST API.
• Want a consistent set of checks applied to everyone, without depending on staff to remember to start each verification.

If you only need to verify a handful of people, or want to script the flow yourself, start a verification directly or use the API instead.

How it works

Once you connect a system, each new or changed record flows through automatically. Depending on the integration, Checktiv either receives it the moment it happens, or checks the connected system for new and changed records on a regular schedule; each integration’s own guide states which:

1. The connected system creates or updates a record (for example, a new or changed reservation), and Checktiv picks it up, either right away or on its next scheduled check.

2. Checktiv reads the record, applies your routing rules, and, unless a rule tells it to skip, starts a verification bound to the connection’s default workflow.

3. If the record has already produced a verification, Checktiv reuses it rather than starting a duplicate.

4. Depending on your invite setting, Checktiv either sends the verification invite itself or leaves that to the source system.

Each verification an integration starts appears in your Applicants list alongside verifications you start any other way, and runs the same checks and review flow.

Default workflow

Every connection binds to one default workflow, which is required. It is the workflow template that every verification from this connection runs, so it decides which checks each person goes through.

You choose the default workflow when you connect a system, and you can change it later by editing the connection. You cannot connect a system until you have at least one workflow template to bind, so create a workflow template first if you have none.

Tip

Give each connection the workflow that matches the people it verifies. If different systems need different checks, connect them separately and bind each to its own default workflow.

Routing rules

Without any routing rules, every record from a connected system starts a verification. Routing rules let you narrow that down so only the records you want are verified. A new connection starts with one rule already in place, seeded for you, that skips records in an early or pre-commitment state; you can edit or remove it like any other rule.

A routing rule matches records on one field and, when it matches, skips them. These are the platform’s names for the fields, in the alphabetical order the rule builder lists them in:

• Channel: a second origin field, on a connected system that records two of them. It does not contain or replace Source below: a record can have one, the other, both, or neither.
• Confirmation code: the code the connected system gives the person.
• Currency: the currency of that total.
• Email: the email address on the record.
• End date: the departure or end date on the record.
• First name: the first name of the person on the record.
• Full name: the full name of the person on the record.
• Last name: the last name of the person on the record.
• Location address: the street address of the property, listing, or unit.
• Location group ID: the identifier of the group, node, or portfolio the location belongs to.
• Location ID: the identifier of the property, listing, or unit.
• Phone: the phone number on the record.
• Rate code: the code of the rate or rate plan the record was booked on.
• Rate name: the name of that same rate or rate plan. Connected systems show the code in some places and the name in others, so both are available and you enter whichever one you can read.
• Record status: the state of the record, such as Confirmed or Inquiry.
• Record type: the connected system’s own classification of the record, such as a direct booking or an owner stay. Separate from its status, and a record has both.
• Reference ID: the identifier of the record in the connected system.
• Source: the connected system’s main origin field for the record, whatever it calls that field. On a system with one origin field this is the channel the booking came through. On one with two it is the more specific of them, and the other is Channel above.
• Start date: the arrival or start date on the record.
• Time zone: the time zone of the property, listing, or unit.
• Total amount: the total value of the record.

Where a connected system has its own name for one of these fields, the rule builder shows that name instead, so a drawer can name a field differently from the list above. Each integration guide names the fields exactly as that connection’s rule builder shows them, and is the one to follow when the two differ.

A connection offers only the fields its connected system sends, so the set differs by connection. The rule builder lists the fields that connection supports, and that list is the authoritative one. Each integration guide states the set for that integration and the value behind each field; the Track guide carries the full table.

Each rule holds a list of values to match against, and a record is skipped when its field matches one of those values. A common use is to exclude records that arrive from a channel you do not want to verify. Which field carries that channel differs by connected system, so check the integration guide rather than assuming it is Source. How a field matches depends on the field:

• Identifiers, dates, the record status, and the source must match exactly, including capitalization.
• Names, email, address, currency, time zone, rate code, rate name, channel, record type, and confirmation code match while ignoring capitalization.
• A phone number matches on its digits, so punctuation and spacing make no difference.
• A total amount matches on value, so 1557 matches 1557.00.

There are no wildcards and no partial matches. A field the record leaves empty never matches. If a rule looks like it is being ignored, check that the connected system sends a value for its field.

Rules are evaluated in order, and the first rule that matches decides the outcome. A record that no rule matches is verified as normal. You can add several rules per connection to cover multiple exclusions.

Note

A rule with no values entered never matches, so add at least one value or it has no effect. Remove every rule to verify every record.

Sending verification invitations

When a verification starts from an integration, someone needs to receive the link to complete it. The Send the verification invite setting controls who sends it.

• On (the default): Checktiv emails the verification link to the person automatically as soon as the verification starts. This is the out-of-the-box behavior, so a newly connected system invites people with no extra setup.
• Off: Checktiv does not send the invite. The verification still starts, but the source system is responsible for inviting the person, using the verification link that Checktiv writes back to that system. Turn this off only when the source system is set up to deliver that link, otherwise the person will not receive it.

You set this per connection when you connect or edit a system.

Managing a connection

Connected integrations are listed under Dashboard → Integrations. From there you can:

• Connect a system from the catalog below by entering its credentials, choosing a default workflow, setting routing rules, and confirming the invite setting.
• Edit a connection to change its default workflow, routing rules, or invite setting. You can leave the credentials blank when editing to keep the ones already stored.
• Reconnect a connection whose credentials have stopped working. Checktiv flags a connection as needing reconnection when it can no longer reach the system; reconnecting prompts you for fresh credentials.
• Pause a connection to stop it starting new verifications while keeping it configured, then Resume it later to start again. A paused connection ignores new records until you resume it.
• Disconnect a connection to remove it. This stops new verifications from the system and is confirmed before it takes effect. Verifications that already started are unaffected.

Caution

Pausing and disconnecting only stop future verifications. Verifications already in progress continue through their checks and review as usual.

Available integrations

Hostaway, Guesty, and Track are available to connect. Additional integrations across property management, payments, and business apps appear in the catalog as they become available.

HostawayStart a verification automatically when a new reservation is created in Hostaway.

GuestyStart a verification automatically when a new reservation is created in Guesty.

TrackStart a verification automatically when a reservation is created or updated in Track.