Data
Identifiers
An identifier is a phone number or email address the user uses to verify for 1-Click Signup.
Identifiers are inputs: you pass them to us in API request bodies.
Name | Key | Type | Format | Description | Example |
---|---|---|---|---|---|
Phone | phone | string | E.164 | Phone number a user uses to verify for 1-Click Signup | "+10123456789" |
email | string | Email address a user uses to verify for 1-Click Signup | "richard@piedpiper.net" | ||
Birth Date | birthDate | string | YYYY-MM-DD | User's birth date (in Sandbox, this must be "1989-08-01" to pass validation) | "1989-08-01" |
SSN4 | ssn4 | string | 4 digits (0-9) | Last 4 digits of user's Social Security Number (in Sandbox, this must be "6789" to pass validation) | "6789" |
To source verified data (credentials and metadata) for a user:
- Phone is always required.
- Email is optional, but including it helps source better and more data — especially risk signals metadata.
- Birth date and/or SSN4 are only required sometimes: if you get the
OCE11
error code, which indicates that additional information is required. This happens when Verified is unable to narrow down to a single user based on only phone (and email if included).
Credentials
A credential is a piece of identity data about a user.
Credentials are outputs: we return them to you in API response bodies.
We support multiple formats for some credential types (see below). If you'd like to use formats different than the defaults, please reach out to us at Support@Verified.inc and we'll enable them for you.
Metadata
A piece of metadata is additional data that's not a user's identity data (their identifiers or credentials) — though it's often about that identity data.
Metadata are outputs: we return them to you in API response bodies.
Name | Key | Type | Applies To | Format | Description | Example |
---|---|---|---|---|---|---|
Verification Method | verificationMethod |
|
| snake_case | How an identifier or credential was verified | "phone_carrier" |
Risk Signals | riskSignals | Object |
| Object with keys specified below in Risk Signals | Risk signals associated with the identifiers provided | See RiskSignals example |
ID | id | string |
| Version 4 UUID | Unique identifier for a credential | "174b9aaf-3219-4499-b54c-0eb6acc5dbf2" |
Status | status |
|
| snake_case | The status of a credential | "valid" |
Expiration Date | expirationDate | string |
| Unix time (milliseconds) or null | The date a credential expires | "1671847264479" |
Fraud Signals Legacy | fraudSignals | string |
| Unix time (milliseconds) or null | The date a credential expires | "1671847264479" |
The most commonly used type of metadata is verificationMethod
, which describes how a credential was verified:
"phone_carrier"
: verified via phone carrier records"credit_bureau"
: verified via credit bureau records"otp"
: verified via an OTP (one time passcode)"customer_otp"
: verified via an OTP (one time passcode) by a Verified customer, not directly by Verified"self_attested"
: attested by the user themselves (not verified)null
You can build custom logic to handle credentials based on their verificationMethod
, for example requiring additional verification if an important credential is "self_attested"
.