Data Fields & Indicators

Every verification confirms that the person holding the license is the person in the selfie. On top of that, you choose what extra data comes back with the result, and you can turn on indicators: background checks against outside data sources that add confidence in who you're dealing with.

What's available depends on the verification type you pick when creating a request or template:

Core: identity and liveness only. No personal data is returned.
Basic: Core, plus the person's name and address.
Full: everything on the license, plus phone and address verification.

You only get the fields you select. If you don't need a value, leave it off. You'll collect less personal data, and the consent screen your end user sees will be shorter.

Data Fields

Included With Every Verification

Field	Description	Core	Basic	Full
License Authenticity `license_appears_real`	Whether the scanned document looks like a genuine ID, based on edge detection, proportions and the presence of a face photo.	✓	✓	✓
License Expired `license_expired`	Whether the expiration date on the license has already passed.	✓	✓	✓
Age Checks `over_18 / over_21`	Whether the person is at least 18 and at least 21, worked out from the date of birth. You get the yes/no answer, not the date itself.	✓	✓	✓
Liveness `webcam_appears_live`	Whether the selfie passed liveness detection, meaning a real person was in front of the camera rather than a photo or a screen replay.	✓	✓	✓
Face Match `face_match_score`	How closely the selfie matches the license photo: definite, likely, possible or no match. See Face Match Scoring.	✓	✓	✓

Optional Data Collection

These fields come from the license itself. They're read from the barcode on the back where possible and from the printed front otherwise. Select them per request or save them in a template.

Field	Description	Core	Basic	Full
First Name(s) `first_names`	The given name(s) as printed on the license.	–	✓	✓
Middle Name(s) `middle_names`	Any middle names on the license. Many licenses have none, so this is often empty.	–	✓	✓
Last Name `last_name`	The family name as printed on the license.	–	✓	✓
Street Address `street_address`	The residential street address on the license, which may be out of date if the person has moved.	–	✓	✓
City / State / Postal Code `city, state, postal_code`	The remaining parts of the license address. Each one can be requested separately, for example to collect only the state.	–	✓	✓
Date of Birth `dob`	The full date of birth. If you only need part of it, ask for the year, year and month, or month and day instead (dob_year, dob_year_month, dob_month_day).	–	–	✓
Sex `sex`	The sex marker printed on the license.	–	–	✓
License Number `license_number`	The license or ID number issued by the state.	–	–	✓
License Issue Date `license_issue_date`	The date the current license was issued. A very recent issue date can be worth a second look on high-risk accounts.	–	–	✓
License Expiration Date `license_expiration_date`	The exact expiration date. Every verification already includes the yes/no License Expired check; request this field if you need the date itself.	–	–	✓
Cropped Headshot from License `license_photo`	The cropped face from the license, returned as an image. It is encrypted the same way as other personal data.	–	–	✓
Phone Verification `phone_verification`	The end user confirms a phone number with an SMS code. Results include the line type (mobile, landline, VoIP) and, where available, the carrier and caller name.	–	–	✓

If you supply your own public key, personal data fields are encrypted in the end user's browser before they reach us, so only your server can read them. See Encryption.

Indicator Flags

Indicators go beyond reading the license. They check the details on it against outside sources: postal records, consumer address data and network geolocation. They answer questions a photo match can't, such as "does this person actually live where their license says they do?"

A negative indicator is not a sign of fraud. Not every session can produce every indicator, and outside data sources have gaps. A false or inconclusive result usually has an ordinary explanation. Treat indicators as extra confidence when they're positive, and as a reason to take a closer look when they're not. Never reject someone on an indicator alone.

Indicator	What It Tells You	Core	Basic	Full
Address Deliverability `address_verification.address_valid`	Whether the address on the license is a real, deliverable postal address, checked against postal service address data. This is a check on the address only. It doesn't say who lives there. Why it might be false: new construction not yet in postal records, rural route or unusual unit formats, or a license that uses a mailing address the postal service doesn't recognise.	–	–	✓
Address Confirmation `address_verification.full_name_match` `address_verification.last_name_match`	Whether the person named on the license is on record as living, or having lived, at the license address, based on consumer and change-of-address records. `full_name_match` means first and last name both matched. `last_name_match` alone often means someone in the same household is on record, such as a spouse or parent. Why it might be false: the person's name may never have been registered with the postal service at that address, they may not have filed a forwarding address when they moved, they may have recently changed their name, or they may rent a room in a home listed under someone else's name.	–	–	✓
Location Consistency `location_consistency.status`	Whether the end user's internet connection (IP address) geolocates near the address on their license. The result is `consistent`, `inconsistent` or `inconclusive`. It also reports whether the connection is coming through a VPN, proxy, Tor or a hosting provider, and the approximate distance when one could be measured. The check runs on our servers, so the end user can't tamper with it. Why it might not be consistent: `inconclusive` is the most common result. Mobile carriers route traffic through regional gateways that can be hundreds of miles away, and many phones use privacy relays. The person may be on a company device or office network that geolocates to corporate headquarters. They may be travelling, or they may have moved recently and not yet updated their license.	–	✓	✓
Proxy Detection `verification.is_proxy`	Whether the connection used to submit the verification came through a known proxy or anonymizing service. When it did, the proxy type is included. Why it might be true: plenty of honest users run a privacy VPN all the time, and some employers send all traffic through a corporate proxy.	✓	✓	✓

When an Indicator Is Missing

Address Deliverability, Address Confirmation and Location Consistency all need the structured address that's encoded in the barcode on the back of the license. If the end user skips the barcode step, or it can't be read (worn, damaged, or a non-standard card), these indicators don't run and are left out of the result rather than reported as false. If an outside data source is temporarily unavailable, the verification still completes without that indicator. The end user is never blocked from finishing because an indicator couldn't run.

Reading Indicators Together

Indicators are most useful together. Some examples:

Strong: a definite face match, a deliverable address, a full name match and a consistent location. Every signal agrees.
Normal: a definite face match and a deliverable address, only a last name match, and an inconclusive location. This is typical of a young adult on a mobile connection still listed under a parent's household.
Worth a closer look: an address that isn't deliverable, no name match, and a connection flagged as anonymized that geolocates to another country. Each of these could be innocent on its own, but together they justify a follow-up step, such as a phone call or a request for a second document.

See how these fields appear in the payload you receive.

Webhook Payload Shape →