Track integration

View as Markdown Open in ChatGPT Open in Claude

The Track integration starts an identity verification automatically when a reservation is created or updated in your Track account. You connect once, choose the workflow the verification runs, and each qualifying reservation starts a verification for the applicant without any manual step. The verification’s status is written onto the reservation as a tag, and the applicant’s verification link and an internal review link are written on as private notes, so your team sees them where they already work.

This page covers the Track integration specifically. For the full list of available integrations and how connections work in general, see the Integrations overview.

When to use

Connect Track when you want reservations to trigger identity verification on their own, instead of adding each applicant by hand or through the API. It suits teams that:

Take reservations in Track and want every confirmed applicant verified before arrival.
Want the verification status and links visible on the reservation, so reviewers and front-desk staff do not switch tools.
Want to control which reservations get verified (for example, skip held reservations) with routing rules rather than code.

If you only verify applicants occasionally, or you drive verification from your own system, the API or a bulk CSV import may fit better. You can use the integration alongside either.

How it works

Track has no webhooks, so the integration cannot be notified the instant a reservation changes. Instead, once connected, it checks Track for new and updated reservations on its own schedule:

The integration checks Track. This happens every few minutes, so a reservation is typically picked up within about 5 minutes of being created or updated in Track.
The reservation status decides the action. The integration reads the reservation and acts on its status (see the table below). A confirmed, checked-in, or checked-out reservation starts a verification if it does not already have one; a held reservation is skipped; a canceled reservation withdraws any verification still in progress.
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 reservation’s contact details are carried onto the applicant so reviewers can identify them in the console, and Track’s reservation number is stored as the applicant’s external reference.
The applicant is invited. By default, the platform emails the applicant their verification link. You can turn this off if you would rather send the link yourself from Track using the note field described below.
The status and links are written back. The verification’s status is kept in step as a tag on the reservation, and the verification link and an internal review link are written as private notes the first time the verification starts.

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:

Track status	Console record status	What happens
Hold	Inquiry	Skipped by default. This is a held or pre-commitment booking, not a committed stay.
Confirmed	Confirmed	Starts a verification if the reservation does not already have one.
Checked In	Confirmed	Starts a verification if the reservation does not already have one; leaves an existing verification as is.
Checked Out	Confirmed	Starts a verification if the reservation does not already have one; leaves an existing verification as is, never withdrawing it.
Cancelled	Canceled	A verification for the reservation that has not yet completed is withdrawn.

The integration only reads a reservation that is created or changes after you connect; it does not look at when the reservation was originally created. A reservation that has not changed since you connected is never read, no matter how old it is. But an old reservation that changes for the first time after you connect, for example because it checks in, is read and treated like a new one: if it does not already have a verification, one starts, and you are billed for it. To keep a specific old reservation from starting a verification this way, add a routing rule that matches its Reservation ID (the reservation’s Track number) before it next changes. A verification you start yourself for that reservation, through the API or a bulk CSV import, is not linked to it: the integration still starts its own when the reservation changes, and neither one gets the tag or the notes.

Only the verification status and the two link notes are ever written back to Track. No applicant personal data is sent to Track.

Reservation fields you can use in routing rules

Routing rules match on the fields the integration reads off each Track reservation. On a Track connection the rule builder names most of these fields the way Track does, so the first column below is what you look for in the drawer. The rows are listed alphabetically, the same order the drawer lists them in, followed by where the value comes from on the reservation and how a rule compares it:

Rule field	Taken from the Track reservation	How a rule compares it
Arrival	The reservation’s arrival time, exactly as Track stores it.	Exactly, so enter the full value Track stores, not just a day.
Channel	The channel the booking came through. A separate field from Sub-channel below, not its parent.	Ignoring capitalization.
Confirmation code	The reservation number, the same value as Reservation ID below. Track keeps no separate booking code.	Ignoring capitalization.
Currency	Reservation currency.	Ignoring capitalization.
Departure	The reservation’s departure time, exactly as Track stores it.	Exactly, so enter the full value Track stores, not just a day.
Email	Contact primary email, falling back to the secondary email when the primary is empty.	Ignoring capitalization.
First name	Contact first name.	Ignoring capitalization.
Full name	Contact name.	Ignoring capitalization.
Grand total	Guest breakdown grand total.	By value, so 1557 matches 1557.00.
Last name	Contact last name.	Ignoring capitalization.
Node ID	The node the reservation’s unit belongs to, as a number.	Exactly, including capitalization.
Phone	Contact cell phone, falling back to home, other, then work.	Digits only, so any punctuation you use is fine.
Rate type code	The code of the reservation’s rate type, not its name and not its id.	Ignoring capitalization.
Rate type name	The name of the reservation’s rate type. This is the one the reservation screen shows.	Ignoring capitalization.
Record status	The reservation’s status, normalized to the values in the table above.	Exactly, from the fixed list above.
Reservation ID	The reservation number. The value the integration writes back against.	Exactly, including capitalization.
Reservation type	The reservation’s type in Track, by name, such as Guest Direct or Owner.	Ignoring capitalization.
Sub-channel	The booking’s sub-channel. A separate field from Channel above, empty on most reservations.	Exactly, including capitalization.
Unit address	The unit’s address, joined into one line: street, extended address, city, region, postal code, and country.	Ignoring capitalization, and the whole line must match.
Unit ID	The reservation’s unit.	Exactly, including capitalization.
Unit time zone	The unit’s time zone.	Ignoring capitalization.

A few rows are worth a second look:

Record status is ours, not Track’s. It is the reservation’s Track status put through the table above, so a rule on it picks from Confirmed, Inquiry, Pending, Canceled, and Excluded, never from Hold, Checked In, or Checked Out. That is why this one field keeps a platform name in the drawer while the rest use Track’s.
Confirmation code and Reservation ID are the same number. Track has no guest-facing booking code separate from the reservation number, so a rule on either compares the same value. Use Reservation ID, which is also the value every write-back is addressed to.
Channel and Sub-channel are two separate fields, and one does not contain the other. The names suggest a hierarchy and the data does not have one: a reservation can carry a channel with no sub-channel, a sub-channel with no channel, both, or neither. Most reservations that come through a channel carry no sub-channel at all, and some reservations carry only a sub-channel. So a rule on one of them does not cover the other, and to skip everything from a given booking source you may need a value on each. To exclude a whole channel, start with Channel. Where you connect an OTA through a channel manager, Track usually records the channel manager as the Channel and the OTA itself as the Sub-channel, so that case needs the rule on Sub-channel.
Neither Channel nor Sub-channel is the rate type. To match the rate instead, use Rate type code or Rate type name, which are separate fields. If you need to route on something this table does not list, tell us which Track field it is and we will look at adding it.
Rate type code and Rate type name are both available, because Track shows different ones in different places. A Track rate type has a short code and a longer name, and the reservation screen shows the NAME. So if you are reading a rate off a reservation, use Rate type name and enter it the way it appears there, for example Standard Rate. Use Rate type code, for example R1, when you are working from the rate type itself in Track. Entering the name into the code field, or the other way round, gives you a rule that never matches.
Reservation type is how you skip owner stays. Track marks a reservation type as an owner type in that type’s own settings, and a routing rule matches the type’s NAME as the reservation screen shows it. So list the type names your account uses for owner stays, for example Owner and Owner Guest, rather than looking for a single owner switch. Check the names first: an account can have an owner type whose name does not contain the word owner, and that one has to be listed too. We do not offer the owner setting itself as a rule field because it is a checkbox on the reservation type rather than a value you can read on a reservation, so there would be nothing for you to enter.
Node ID is a number. Track gives a node no code and no short name, so a rule on this field takes the numeric id. Read that id off the node in Track. Use Node ID to skip every unit under one node at once, and Unit ID to skip a single unit.

Only Arrival and Departure need the value in Track’s own format. A rule on either compares the stored value as-is, so copy it from the reservation rather than typing a calendar date.

A field that is empty on the reservation is empty to the rule as well. A rule that requires a value it never receives never matches, which is worth checking first when a rule looks like it is being ignored.

Status tag and notes on the reservation

Track has no custom fields on reservations, so the integration writes back using a status tag and two private notes instead.

Status tag

The integration keeps exactly one of five tags on the reservation, replacing it as the screening progresses. The tags say Guest screening rather than naming one kind of check, because a workflow may run an ID check, a background check, or neither: the tag reports where the guest’s screening has got to, whatever it is made of.

Tag	When it is applied
Guest screening: Pending	The screening has started and has not yet reached review.
Guest screening: In review	The screening is awaiting your team’s review, or finished with no outcome recorded yet.
Guest screening: Approved	The screening was approved.
Guest screening: Declined	The screening was declined.
Guest screening: Not completed	The screening expired, or was canceled without reaching an outcome.

These five names are managed by the integration. It creates a tag the first time it needs to apply it, not when you connect, so do not expect to see any of them on the reservation before a verification starts. Do not reuse one of these five names for your own tags: the integration treats any tag with a matching name as its own, and the next status change replaces or recreates whichever one the current status needs.

Applicant link and review link

The integration adds two private notes to the reservation when the verification starts:

Screening link for the guest carries the applicant’s durable verification link. Share this with the applicant if you send invites yourself.
Screening review link carries an internal link your team uses to open the verification in the console. Not for the applicant.

Both notes are created as private folio notes, marked to keep them from the reservation’s guest. Each is written once, when the verification starts, and is not edited or recreated afterward, so a note you remove by hand stays removed. You can always find both links by opening the verification directly in your Applicants list, whether or not the note is still there.

Connecting Track

You need the Owner or Admin role, an active organization, and at least one workflow template 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 your account domain and a Track server key: an API key and an API secret.

In Track, open Configuration → Company Setup → API Keys and create a server key. Track also offers channel keys, which only see channel-enabled reservations and reach no write-back endpoint, so create a server key, not a channel key.
In the console, open Integrations and choose Track.
Enter your account domain, the address you sign in to, for example yourcompany.trackhs.com.
Enter the server key’s API key and API secret.
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 skips it. The list shows your active workflows, with your organization default marked.
(Optional) Add routing rules to change which reservations are verified. The connection starts with a rule that skips Hold reservations by matching Record status: Inquiry; you can keep it, edit it, or remove it, and add rules of your own. Each rule matches a field (such as Record status or Sub-channel) against one or more values, and skips a reservation that matches.
(Optional) Set the Send the verification invite toggle. It is on by default, so the platform emails each applicant their verification link. Turn it off only if you plan to send the link yourself from Track using the note described above.
Select Connect. The button stays disabled until a workflow is chosen and the account domain, API key, and API secret are all filled.

When you select Connect, the platform first checks that the server key can read reservations and manage tags; once that check passes, the connection appears in your Integrations list. Tags are created the first time the integration needs to apply one, not at connect.

While Track needs reconnecting

If Track rejects the stored server key, for example because it was revoked or regenerated, the connection shows Reconnect needed and stops reaching Track: it stops checking for new and updated reservations, and any status tag or note that would be written back is held instead. Nothing already written to Track is undone.

Once you reconnect with a working server key, the integration picks up where it left off: it resumes checking Track from before the interruption, so reservations that changed while it needed reconnecting are still read. It also rebuilds the status tag and both notes for every verification that was waiting, as long as it had been waiting less than 14 days; reconnect promptly, since one waiting longer is not rebuilt automatically. You do not need to do anything else beyond reconnecting.

If you see “Some updates from the connected system could not be read”

When an unusually large or fast-changing batch of reservations cannot be fully read after repeated attempts, the integration sets that period aside instead of getting stuck on it, and shows this notice on the connection:

Some updates from the connected system could not be read. Check recent records and send verification links if needed.

For the period the notice covers, the integration may have missed more than a status update: a new reservation that should have started a verification, and a cancellation that should have withdrawn one (so you could be billed for a verification you no longer need). Reservations outside that period are unaffected, and the connection keeps working normally afterward.

If you see this notice, compare your recent reservations in Track against your Applicants list for the affected period and act on anything missing: start a verification for a reservation that should have one, or cancel one you no longer need. If your workflow’s document prints the transaction amount, currency, or location, starting a verification by hand or through a bulk CSV import will not carry those details; use the API with the metadata object instead.

This notice clears when you reconnect or resume the integration, or on its own once it has read normally for 7 days after the notice appeared.

Troubleshooting

The connection did not go through. Check, in order:

The API key or API secret was not accepted. Check them against Track’s API Keys page. The console shows: “These credentials were not accepted. Check the values you entered and try again.”
You entered a channel key. Create a server key instead, under Configuration → Company Setup → API Keys.
The account domain could not be reached, or is not a Track address. It must end in trackhs.com, for example yourcompany.trackhs.com; a pasted sign-in URL also works, as long as it points to that address.
Track was temporarily unavailable. Wait a moment and try connecting again.

The connection shows “Reconnect needed.” The stored server key is no longer valid, usually because it was revoked or regenerated in Track. Open the integration, choose to reconnect, and enter a fresh API key and API secret; your account domain is already shown and cannot be changed. See While Track needs reconnecting above for what happens to reservations and write-backs in the meantime.

The connection shows “Not responding. We will keep retrying automatically.” Track has been unreachable or timing out for a while. This clears on its own once Track responds normally again; you do not need to do anything.

The connection is paused and shows “The saved credentials are no longer accepted. Use Edit to enter working credentials to resume.” Edit the connection and enter a working API key and API secret; your account domain is already shown and cannot be changed. Saving working credentials returns the connection to active on its own; there is no separate step after that. Trying to resume the connection before that is done shows: “Enter working credentials for this integration to resume.”

A reservation did not create a verification. Check, in order:

The reservation status. Only Confirmed, Checked In, and Checked Out reservations start a verification, and only when the reservation does not already have one. A Hold reservation is skipped until it is confirmed, and a Cancelled reservation never starts one. See the status table above.
Routing rules. A reservation that matches a skip rule is intentionally not verified. Review the connection’s rules, including the rule that skips Hold reservations (Record status: Inquiry), against the reservation’s fields (for example, its record status or sub-channel).
Timing. The integration checks Track roughly every 5 minutes, so a very recently changed reservation may not have been picked up yet.
Whether the reservation has changed since you connected. The integration only reads a reservation that changes after you connect; one that has not changed is never read, however old it is. See The integration is forward-only above.
The workflow. The connection must be bound to an active workflow. If the bound workflow was deactivated, edit the connection and choose an active one.

An applicant did not receive their invite. Confirm the Send the verification invite toggle is on for the connection. If you turned it off, the platform does not email the applicant; you are expected to send the link yourself using the note the integration wrote onto the reservation. Also confirm the reservation carried an email address for the applicant, since there is no address to send to otherwise.

The status tag is missing or looks wrong. The five status tag names are managed by the integration; see Status tag above. If a tag is simply absent, the next status change replaces it with the correct one. If the verification has already reached its final status and will not change again, the tag stays as it is; this does not affect the verification itself.

A note is missing from the reservation. The integration writes each note once, when the verification starts, and does not recreate a note removed afterward. You can still find both links by opening the verification directly in your Applicants list.

You want to stop the integration. Pausing stops the integration from checking Track for new and updated reservations, but it does not stop a write-back already under way: a verification that was already in progress keeps updating its status tag as it moves through review, since that happens independently of the check schedule. Reservations that change while paused are not read once you resume, unless they change again afterward; resuming does not catch up the way reconnecting does. Disconnecting removes the connection entirely and stops all future write-backs; verifications that already started are unaffected either way. To start again later, resume a paused connection, or connect again if you disconnected it.