Verisoul Authenticate API Signal Glossary
Last updated: September 1, 2026
How to read the glossary
Label | What it means |
|---|---|
Data | An identifier, customer input, observed fact, counter, timestamp, or category. Data provides context but usually needs corroboration before it drives a fraud action. |
Signal | A boolean flag, named reason, match type, or categorical outcome. Signals explain which condition was detected and why a score moved. Some signals add trust or describe context rather than indicating fraud. |
Score | A numeric estimate for one model, risk dimension, or account relationship. Higher means riskier or more confident unless the description says otherwise. |
Aggregate score | A numeric rollup across component models, account links, or sessions. Aggregate scores are the broadest measures and should be explained with the underlying scores and signals. |
Most risk scores range from 0 to 1, where higher means more risk. The email score is the exception: it ranges from -1 for highest trust to 1 for highest risk. Dashboard percentages equal the API decimal multiplied by 100, and production rules should use the project's configured thresholds.
Read the response in this order:
Start with
decisionandaccount_score.Read
bot,multiple_accounts, andrisk_signalsto find the main risk category.Open Session > Risk signal scores and Session > Risk signals to measure and name the current-session issue.
Use Session > Risk signal details, Account > Email intelligence, and Linked accounts > Match types to explain the evidence.
Compare the current session with Account > Risk signal averages before applying an account-wide restriction.
Sample Authenticate request and response
The request below includes the optional identity fields that improve email, location, and multi-accounting coverage. Replace the placeholder values with your own server-side API key, stable account data, and the session ID created by the client SDK.
curl --request POST \
--url '<https://api.prod.verisoul.ai/session/authenticate?accounts_linked=true>' \
--header 'Content-Type: application/json' \
--header 'x-api-key: YOUR_API_KEY' \
--data '{
"account": {
"id": "acct_123",
"email": "person@example.com",
"phone": "+14155550123",
"first_name": "Avery",
"last_name": "Chen",
"username": "avery.chen",
"expected_countries": ["US"]
},
"session_id": "SESSION_ID_FROM_SDK"
}'
This abridged response is illustrative. It shows the nesting used throughout the glossary without implying that these exact values normally occur together.
{
"project_id": "project_123",
"session_id": "session_123",
"account_id": "acct_123",
"request_id": "request_123",
"decision": "Suspicious",
"account_score": 0.72,
"bot": 0.08,
"multiple_accounts": 0.64,
"risk_signals": 0.81,
"accounts_linked": 1,
"session": {
"network": {
"ip_address": "203.0.113.10",
"connection_type": "hosting"
},
"risk_signals": {
"proxy": true,
"location_spoofing": true
},
"risk_signal_scores": {
"proxy": 0.93,
"location_spoofing": 0.88
}
},
"account": {
"num_sessions": 6,
"email": {
"email_score": 0.4,
"risk_signals": ["email_young_age"]
},
"risk_signal_average": {
"proxy": 0.61
}
},
"linked_accounts": [
{
"account_id": "acct_456",
"score": 0.96,
"match_type": ["email", "device"]
}
]
}
Request
The JSON body requires the Account object and session_id; the Account object requires id. Optional identity fields improve intelligence when they are available. See the Account object for normalization and update behavior.
Authentication header and query
Field | Label | Description |
|---|---|---|
| Data | Required. Server credential that authorizes the request. |
| Data | Requests the |
Request body
Field | Label | Description |
|---|---|---|
| Data | Required. Session identifier created by the client SDK. |
Account
Field | Label | Description |
|---|---|---|
| Data | Required. Your unique identifier for the account. |
| Data | Email address associated with the account. |
| Data | Phone number stored for the account and normalized to E.164 before matching. |
| Data | First name used with any available last name for normalized name matching. |
| Data | Last name used with any available first name for normalized name matching. |
| Data | Username associated with the account. Matching lowercases the value and preserves letters, digits, periods, underscores, and hyphens. |
| Data | Countries where the account is expected to operate. A non-empty array replaces the stored declaration; an empty or omitted array preserves it. |
| Data | Customer-defined key-value context stored on the account. |
| Data | Scope that isolates the multi-account graph. Accounts link only within the same group. |
| Data | List names to add during authentication; missing custom lists are created automatically. |
Response: Top level
Top-level fields provide the action, the primary risk measures, and identifiers for logging. The nested Session, Account, and Linked accounts objects are documented in their own sections.
Field | Label | Description |
|---|---|---|
| Data | Verisoul project that produced the response. |
| Data | Session evaluated by this request. |
| Data | Account evaluated by this request. |
| Data | Unique identifier for the API request. |
| Signal | Categorical recommendation derived from |
| Aggregate score | Overall fraud risk from |
| Score | Likelihood from |
| Aggregate score | Probability from |
| Aggregate score | Aggregate account-and-session risk score from |
| Data | Number of other accounts linked to this account. |
| Data | Current account list memberships. |
Response: Session
Session fields describe the client interaction being evaluated now. Raw data explains the environment, binary signals name detected conditions, and scores measure how strongly each risk dimension is present.
Session basics
Field | Label | Description |
|---|---|---|
| Data | SDK platform that produced the session. React Native and Flutter report their underlying platform; older sessions can be null. |
| Data | Native SDK version; web sessions return null. |
| Data | Time the session began. |
| Data | Verisoul's best estimate of the user's actual country; it falls back to the IP country when stronger evidence is unavailable. |
| Data | Device identifier associated with the session. |
Network
Network data describes the observed connection. The object is raw data, not a standalone network score; network risk appears in the Risk signals, Risk signal scores, and Risk signal details sections below.
Field | Label | Description |
|---|---|---|
| Data | Client IP observed for the session. |
| Data | ISP or network operator associated with the IP. |
| Data | Primary purpose or organization of the network. |
Location
Field | Label | Description |
|---|---|---|
| Data | Continent code associated with the IP. |
| Data | Country associated with the IP. |
| Data | State or region associated with the IP. |
| Data | City associated with the IP. |
| Data | Postal code associated with the IP. |
| Data | Timezone associated with the IP location. |
| Data | Latitude associated with the IP. |
| Data | Longitude associated with the IP. |
Browser
Field | Label | Description |
|---|---|---|
| Data | Browser family, such as Chrome or Safari. |
| Data | Reported browser version. |
| Data | Browser language setting, usually an IETF language tag. |
| Data | Raw user-agent string. |
| Data | Browser-reported timezone. |
Device
Field | Label | Description |
|---|---|---|
| Data | Broad device class. |
| Data | Detected device model or class. |
| Data | Reported operating system. |
| Data | Reported logical CPU cores. |
| Data | Reported device memory. |
| Data | Reported graphics renderer or GPU. |
| Data | Reported screen height. |
| Data | Reported screen width. |
Interaction events
These raw counts describe captured mouse, click, keyboard, touch, and clipboard activity. They support bot investigations, while the top-level bot score carries the automation judgment.
Field | Label | Description |
|---|---|---|
| Data | Number of mouse events captured. |
| Data | Number of click events captured. |
| Data | Number of keyboard events captured. |
| Data | Number of touch events captured. |
| Data | Number of clipboard events captured. |
Risk signal scores
Field | Label | Description |
|---|---|---|
| Score | Likelihood from |
| Score | Confidence from |
| Score | Confidence from |
| Score | Tor-detection score from |
| Score | Datacenter score from |
| Score | Recent-fraud-IP score from |
| Score | Impossible-travel score from |
| Score | Device-and-network inconsistency score from |
| Score | Location-spoofing score from |
The current schema does not include a session-level numeric spoofed_ip score, although Session > Risk signals includes the boolean and Account > Risk signal averages includes the time-decayed score.
Risk signal details
Risk signal details are available when the feature is enabled for the project. The arrays contain named reasons only when affirmative evidence exists, which makes them useful for explainability and specific rules.
Network reason codes
These codes identify concealed routing, network-and-device contradictions, or geographic conflicts that can weaken attribution. List-based detections can still reflect shared or changing infrastructure.
Value | Label | Description |
|---|---|---|
| Signal | Round-trip timing is unusually high for the claimed region and connection type, consistent with a distant tunnel. |
| Signal | Low-level network behavior conflicts with the claimed browser. |
| Signal | Operating system inferred from packet behavior disagrees with the claimed operating system. |
| Signal | Verisoul's resolved true country differs from the raw IP country. |
| Signal | IP appears in a known datacenter or cloud-hosting range. |
| Signal | Device timezone is geographically far from the IP location. |
| Signal | Device language implies a country inconsistent with the IP location after common benign variants are excluded. |
| Signal | IP country or resolved true country falls outside the account's declared expected countries. |
| Signal | One or more IP intelligence sources identify the IP as a proxy. |
| Signal | A network probe observed another IP that reveals a different network identity. |
| Signal | IP intelligence identifies the address as a VPN exit or known VPN service. |
| Signal | Native device configuration shows an active VPN tunnel interface. |
| Signal | Native operating-system settings contain an HTTP proxy. |
Device reason codes
These codes identify automation, virtualization, tampering, or integrity failure that can imitate genuine devices or scale abuse. Developer settings and manual configuration can be legitimate, while the two Chinese-device codes are descriptive unless a separate policy makes them relevant.
Value | Label | Description |
|---|---|---|
| Signal | Browser internals appear modified by anti-detect tooling or property manipulation. |
| Signal | Speech, audio, or media capabilities conflict with the claimed OS and browser. |
| Signal | Graphics evidence shows software rendering, a VM driver, or a device mismatch. |
| Signal | Rendering, worker, or permission evidence conflicts with the claimed OS. |
| Signal | Storage, geometry, timing, touch, or system-UI details resemble a VM, headless browser, or emulator. |
| Signal | CPU, memory, or low-level numeric behavior falls outside realistic ranges for the device type. |
| Signal | WebDriver, developer-protocol control, or another automation artifact is present. |
| Signal | Fonts or emoji rendering imply a different OS from the one claimed. |
| Signal | Minor environment probes are inconsistent or missing. |
| Signal | Android appears rooted, emulated, debug-signed, or exposes emulator network interfaces. |
| Signal | Android brand is inconsistent with the region or carrier context. |
| Signal | iOS appears simulated, jailbroken, debugged, location-simulated, or inconsistent with Apple hardware. |
| Signal | Google Play Integrity reports an app-recognition, licensing, or device-recognition failure. |
| Signal | iOS version, CPU, memory, thermal, battery, or usage evidence conflicts with genuine Apple hardware. |
| Signal | USB debugging or Android developer settings are enabled. |
| Signal | Automatic time or timezone is disabled on Android. |
| Signal | App runs inside a clone or virtual-app container. |
| Signal | A large share of device probes returned empty or placeholder values. |
| Signal | Boot history is unusually low, high, or inconsistent with device age. |
| Signal | Native device reports no locale or language configuration. |
| Signal | Device brand is an OEM restricted by US or European carrier policy and can appear regardless of score level. |
| Signal | Device brand is a mainland-Chinese manufacturer with limited US carrier presence, a descriptive property that can appear regardless of score. |
Mobile
Native iOS and Android sessions return these fields; web and WebView-only sessions return an empty object. Risk interpretations such as emulator, root, jailbreak, reset, and integrity failure appear in Device reason codes.
Field | Label | Description |
|---|---|---|
| Data | Native device brand, such as Apple, samsung, or google. |
| Data | Native device model; iOS reports the generic family such as iPhone or iPad. |
| Data | Total device RAM; currently null on Android. |
| Data | Number of device boots; iOS returns null because the platform leaves it unavailable. |
| Data | Days since the device last booted. |
| Data | Current battery charge; currently null on Android. |
| Data | Native device language preferences. |
| Data | Platform app-attestation verdict: Play Integrity on Android or App Attest on iOS. |
| Data | Platform device-attestation verdict: Play Integrity on Android or DeviceCheck on iOS. |
Response: Account
Account fields describe the stored identity and behavior accumulated across sessions. They answer whether the current result fits the account's history.
Stored identity
Field | Label | Description |
|---|---|---|
| Data | Stored account identifier. |
| Data | Stored email address. |
| Data | Stored phone number in E.164 format. |
| Data | Stored first name. |
| Data | Stored last name. |
| Data | Stored username. |
| Data | Stored two-letter countries where the account should operate. |
| Data | Stored customer-defined key-value context. |
| Data | Multi-account graph group assigned to the account. |
History
Field | Label | Description |
|---|---|---|
| Data | Total sessions associated with the account. |
| Data | First time the account was observed. |
| Data | Most recent time the account was observed. |
| Data | Most recent session ID for the account. |
| Data | Most recently associated account country. |
| Data | Distinct countries observed across the account's sessions, including resolved true countries. |
Unique devices
Field | Label | Description |
|---|---|---|
| Data | Unique devices observed in the last day. |
| Data | Unique devices observed in the last seven days. |
Unique networks
Field | Label | Description |
|---|---|---|
| Data | Unique networks observed in the last day. |
| Data | Unique networks observed in the last seven days. |
Email intelligence
Email enrichment completes asynchronously, so a null email_score means scoring is incomplete, commonly for about 3 to 5 seconds after an address is first observed. Verisoul repredicts the account when enrichment finishes.
Field | Label | Description |
|---|---|---|
| Data | Email address evaluated by email intelligence. |
| Data | Indicates a disposable email provider. |
| Data | Indicates a public or personal email provider. |
| Data | Verisoul's email-validity result. |
| Data | Classification of the email's apex domain. |
| Score | Unified email score from |
| Signal | Positive email or domain reason codes. |
| Signal | Risky email or domain reason codes. |
| Data | Real-time count of project accounts sharing the same apex domain; subdomains roll up to the apex. |
Domain type values
Value | Label | Description |
|---|---|---|
| Data | Email-forwarding or privacy-relay domain. |
| Data | Public consumer email provider. |
| Data | Temporary or throwaway email provider. |
| Data | Business-owned domain. |
| Data | Government-entity domain. |
| Data | Educational-institution domain. |
| Data | Domain lacks valid mail-routing support. |
| Data | Domain appears inactive or unused. |
Email risk reason codes
These codes explain what raised the email score. Identity Intelligence-only fields from the standalone Email Intelligence API are excluded because this guide is scoped to Authenticate.
Value | Label | Description |
|---|---|---|
| Signal | The address is not valid email syntax, which prevents dependable communication or ownership verification. |
| Signal | The local part contains more than five numbers, a pattern often associated with generated addresses used for bulk account creation. |
| Signal | The local part contains more than two periods, an unusual structure that can support generated-address or aliasing risk when other evidence agrees. |
| Signal | The local part contains more than one number block, a structure that can indicate automated address generation. |
| Signal | A business-domain local part contains numbers. This can indicate generated workforce-style identities, although legitimate company naming conventions can also produce it. |
| Signal | The local part contains a term associated with temporary or fraudulent use, which raises concern that the identity was created for abuse. |
| Signal | The address appears to use aliasing. Aliases can create many apparent identities that route to one mailbox, making promotion or duplicate-account abuse easier. |
| Signal | The address represents a role such as HR or sales. Shared role mailboxes weaken the link between the address and one person. |
| Signal | The local part indicates a no-reply mailbox, which is unlikely to be controlled by the user completing the flow. |
| Signal | The address cannot receive email, preventing email-based verification and reliable communication. |
| Signal | The address structure appears random or machine-generated, which can indicate automated signup or bulk account creation. |
| Signal | The email appears to be less than one year old. Limited tenure provides less evidence of a stable identity, especially in high-value flows. |
| Signal | The email has no known breach-based history. This provides less evidence that the address has existed over time, although absence of history is not proof of fraud. |
| Signal | The published definition says the email has no breach history, leaving its age unknown. Unknown age is missing trust evidence rather than direct proof of risk. |
| Signal | The email appears in more than 50 known breaches, which raises credential-exposure and account-takeover risk even when the user is legitimate. |
| Signal | The email appears in a high-risk breach, which can indicate elevated credential or identity risk. |
| Signal | The mailbox exists but is full. This weakens immediate deliverability, although it is operational evidence rather than strong fraud evidence. |
| Signal | The domain is a known relay provider. Relays can hide the underlying address and allow identity reuse, although trusted privacy relays can be legitimate. |
| Signal | The domain is a known disposable provider, making it easier to create short-lived identities and repeat signup or promotion abuse. |
| Signal | The business domain has low trust, which provides less evidence that the address belongs to an established organization. |
| Signal | The domain has no MX record. This can weaken deliverability, but it is not conclusive because mail can fall back to A or AAAA records. |
| Signal | The domain contains terms associated with temporary or throwaway use, which can indicate an address created for short-lived abuse. |
| Signal | The domain was registered less than one year ago, providing limited operating history and increasing risk in identity-sensitive onboarding. |
| Signal | The personal provider has higher observed risk relative to Gmail, raising the baseline risk for addresses on that domain without making any one user fraudulent. |
| Signal | The domain does not resolve to an IP, which makes the address operationally suspect and weakens its value as identity evidence. |
| Signal | The domain cannot receive mail because it lacks usable mail or address records, or publishes a null MX record, preventing dependable verification. |
Email trust reason codes
These codes explain what lowered the email score. Trust evidence can reduce risk, but current ownership still requires a separate verification method when that matters.
Value | Label | Description |
|---|---|---|
| Signal | The email was first seen more than three years ago, adding positive identity-tenure evidence that can reduce risk. |
| Signal | The email was first seen more than five years ago, adding stronger positive identity-tenure evidence. |
| Signal | The email was first seen more than ten years ago, providing substantial tenure evidence while leaving current ownership to separate verification. |
| Signal | The email was first seen more than fifteen years ago, providing high-tenure evidence while leaving account-takeover risk possible. |
| Signal | The email has known breach-based history, which supports that the address has existed over time but does not prove current ownership. |
| Signal | The email appears in high-trust historical sources, adding positive evidence of an established identity. |
| Signal | The domain is a trusted government or education type, adding positive organizational context. |
| Signal | The personal provider has higher observed trust relative to Gmail, lowering the domain baseline without replacing address-level checks. |
| Signal | The domain is a known high-trust business, adding positive evidence that the address belongs to an established organization. |
| Signal | The domain uses a known enterprise email provider, adding positive infrastructure trust without proving the user's identity. |
| Signal | The domain was registered more than five years ago, adding tenure evidence that can reduce domain risk. |
| Signal | The domain is a trusted forwarding service such as Apple Private Relay, reducing the risk that relay use alone represents abuse. |
Risk signal averages
These are time-decayed scores across the account's sessions, with recent sessions carrying more weight. They show whether a risk pattern persists beyond one interaction.
Field | Label | Description |
|---|---|---|
| Aggregate score | Time-decayed score from |
| Aggregate score | Time-decayed score from |
| Aggregate score | Time-decayed score from |
| Aggregate score | Time-decayed score from |
| Aggregate score | Time-decayed score from |
| Aggregate score | Time-decayed score from |
| Aggregate score | Time-decayed score from |
| Aggregate score | Time-decayed score from |
| Aggregate score | Time-decayed score from |
| Aggregate score | Time-decayed score from |
Response: Linked accounts
Linked accounts appear when the request uses accounts_linked=true. The pairwise score measures confidence that two accounts are connected; it does not measure the linked account's fraud risk.
Field | Label | Description |
|---|---|---|
| Data | Identifier of the linked account. |
| Score | Confidence from |
| Data | Email associated with the linked account. |
| Data | Phone associated with the linked account. |
| Data | First name associated with the linked account. |
| Data | Last name associated with the linked account. |
| Data | Username associated with the linked account. |
| Data | Declared operating countries for the linked account. |
| Data | First time the linked account was observed. |
| Data | Most recent time the linked account was observed. |
| Signal | Evidence categories that linked the two accounts. |
| Data | List memberships of the linked account. |
| Data | Customer-defined metadata stored on the linked account. |
Match types
Match confidence depends on the evidence type, number of matched sessions, fingerprint uniqueness, and time between sessions. Browser, email, phone, and username are published as full-strength matches; this glossary calls that full linkage weight.
Value | Label | Description |
|---|---|---|
| Signal | Deterministic browser match; the published guide says it produces a link score of |
| Signal | Probabilistic match based on hardware and software characteristics. A high pairwise score can connect accounts, while common device profiles reduce confidence. |
| Signal | Probabilistic match based on IP and network patterns. It can reveal coordinated access, but households, offices, schools, carriers, and VPNs can also share network traits. |
| Signal | Match based on normalized email similarity, including dots and plus aliases. Reuse can connect apparent identities to one mailbox and receives full linkage weight. |
| Signal | Exact match on the normalized E.164 phone number. Reuse strongly connects accounts and receives full linkage weight when phone ownership controls are reliable. |
| Signal | Exact normalized username match. Reuse strongly connects accounts and receives full linkage weight. |
| Signal | Exact normalized name match. It is moderate evidence because unrelated people can share names, so another match type improves confidence. |
| Signal | Mobile match type listed in the OpenAPI schema, but its public matching method is undefined. Confirm its meaning and safe threshold with Verisoul before using it in an automated rule. |
| Signal | Apple-device match type listed in the OpenAPI schema, but its public matching method is undefined. Confirm its meaning and safe threshold with Verisoul before using it in an automated rule. |
Error response
The current OpenAPI documents a 400 response for an invalid request or missing session. Other HTTP errors can occur at the platform level, but their bodies fall outside this endpoint schema.
Field | Label | Description |
|---|---|---|
| Data | HTTP status code in the documented error body. |
| Data | Human-readable error message, such as |
Current documentation caveats
The response nests stored identity inside Account > Stored identity, while enriched email intelligence appears in Account > Email intelligence.
The Session risk signals object and Account risk signal averages include
spoofed_ip; the Session risk signal scores object does not.OpenAPI defines device memory in GB, while the legacy glossary labels it MiB.
Current scoring documentation defines
Real,Suspicious, andFake, while the short API property description mentions only Real and Fake.Email score nullability is broader in runtime documentation than in OpenAPI, so treat null as incomplete intelligence.
OpenAPI leaves success-response requiredness undeclared, so handle absent, null, empty, and
unavailablevalues according to each field's collection conditions.Only Session > Source, Session > Device > Category, and Account > Email intelligence > Domain type are formal OpenAPI enums. Other documented value lists can expand, so integrations should tolerate future values.
The general scoring guide and Authenticate examples use
0to1forbot, while the Bot page says0to100and shows a decimal example. This glossary follows the general scoring guide and API representation.The Authenticate schema names the conditional detail array
linked_accounts, while one multi-accounting guide example usesaccounts_linked. This glossary follows the endpoint schema.
Start with the decision, then use repeated evidence for account-level restrictions
Use the configured decision as the baseline action, record account_score and the three component scores, and store named reasons for explainability. A single session anomaly on an established account usually supports session-level friction, while a high account score, repeated account averages, or strong linked-account evidence can support an account-level restriction. Review thresholds against confirmed fraud and good-user outcomes by platform and customer cohort.