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:

  1. Start with decision and account_score.

  2. Read bot, multiple_accounts, and risk_signals to find the main risk category.

  3. Open Session > Risk signal scores and Session > Risk signals to measure and name the current-session issue.

  4. Use Session > Risk signal details, Account > Email intelligence, and Linked accounts > Match types to explain the evidence.

  5. 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

x-api-key

Data

Required. Server credential that authorizes the request.

accounts_linked

Data

Requests the linked_accounts[] detail array when true.

Request body

Field

Label

Description

session_id

Data

Required. Session identifier created by the client SDK.

Account

Field

Label

Description

id

Data

Required. Your unique identifier for the account.

email

Data

Email address associated with the account.

phone

Data

Phone number stored for the account and normalized to E.164 before matching.

first_name

Data

First name used with any available last name for normalized name matching.

last_name

Data

Last name used with any available first name for normalized name matching.

username

Data

Username associated with the account. Matching lowercases the value and preserves letters, digits, periods, underscores, and hyphens.

expected_countries[]

Data

Countries where the account is expected to operate. A non-empty array replaces the stored declaration; an empty or omitted array preserves it.

metadata

Data

Customer-defined key-value context stored on the account.

group

Data

Scope that isolates the multi-account graph. Accounts link only within the same group.

lists[]

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

project_id

Data

Verisoul project that produced the response.

session_id

Data

Session evaluated by this request.

account_id

Data

Account evaluated by this request.

request_id

Data

Unique identifier for the API request.

decision

Signal

Categorical recommendation derived from account_score and the project's thresholds. Suspicious and Fake indicate increasing fraud risk, while Real indicates the lowest-risk band.

account_score

Aggregate score

Overall fraud risk from 0 to 1, combining multi-accounting, risk signals, and bot detection. A higher value means the combined evidence is less consistent with a genuine user.

bot

Score

Likelihood from 0 to 1 that the interaction is automated. A high score is risky when the action is intended for a person because software can scale credential attacks, scraping, and incentive abuse.

multiple_accounts

Aggregate score

Probability from 0 to 1 that the account is part of multi-accounting. A high value is risky when one person is not allowed to operate many accounts, such as promotion, survey, or marketplace abuse.

risk_signals

Aggregate score

Aggregate account-and-session risk score from 0 to 1. A high value means one or more modeled risk dimensions show strong evidence of abuse, evasion, or an inconsistent environment.

accounts_linked

Data

Number of other accounts linked to this account.

lists[]

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

source

Data

SDK platform that produced the session. React Native and Flutter report their underlying platform; older sessions can be null.

source_version

Data

Native SDK version; web sessions return null.

start_time

Data

Time the session began.

true_country_code

Data

Verisoul's best estimate of the user's actual country; it falls back to the IP country when stronger evidence is unavailable.

device_id

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

ip_address

Data

Client IP observed for the session.

service_provider

Data

ISP or network operator associated with the IP.

connection_type

Data

Primary purpose or organization of the network.

Location

Field

Label

Description

continent

Data

Continent code associated with the IP.

country_code

Data

Country associated with the IP.

state

Data

State or region associated with the IP.

city

Data

City associated with the IP.

zip_code

Data

Postal code associated with the IP.

timezone

Data

Timezone associated with the IP location.

latitude

Data

Latitude associated with the IP.

longitude

Data

Longitude associated with the IP.

Browser

Field

Label

Description

type

Data

Browser family, such as Chrome or Safari.

version

Data

Reported browser version.

language

Data

Browser language setting, usually an IETF language tag.

user_agent

Data

Raw user-agent string.

timezone

Data

Browser-reported timezone.

Device

Field

Label

Description

category

Data

Broad device class.

type

Data

Detected device model or class.

os

Data

Reported operating system.

cpu_cores

Data

Reported logical CPU cores.

memory

Data

Reported device memory.

gpu

Data

Reported graphics renderer or GPU.

screen_height

Data

Reported screen height.

screen_width

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

mouse_num_events

Data

Number of mouse events captured.

click_num_events

Data

Number of click events captured.

keyboard_num_events

Data

Number of keyboard events captured.

touch_num_events

Data

Number of touch events captured.

clipboard_num_events

Data

Number of clipboard events captured.

Risk signal scores

Field

Label

Description

device_risk

Score

Likelihood from 0 to 1 that the device or browser environment is associated with fraud. Higher values mean stronger evidence of automation, tampering, virtualization, or integrity failure.

proxy

Score

Confidence from 0 to 1 that traffic uses a proxy. Higher values mean the visible IP and location are less reliable for attribution and geographic controls.

vpn

Score

Confidence from 0 to 1 that traffic uses a VPN. Higher values mean the visible network or location may be intentionally masked, although legitimate privacy and enterprise use remains possible.

tor

Score

Tor-detection score from 0 to 1. Higher values mean origin attribution is weaker because traffic is leaving through the Tor network.

datacenter

Score

Datacenter score from 0 to 1. Higher values indicate hosting or cloud infrastructure that can support automated abuse at scale, while legitimate service traffic remains possible.

recent_fraud_ip

Score

Recent-fraud-IP score from 0 to 1. Higher values indicate stronger association with IP infrastructure recently observed in abuse, with shared and reassigned IPs remaining a caveat.

impossible_travel

Score

Impossible-travel score from 0 to 1, based on distance, elapsed time, GeoIP confidence, and account history. Higher values increase the likelihood of account sharing, takeover, or location masking.

device_network_mismatch

Score

Device-and-network inconsistency score from 0 to 1. Higher values mean the reported device is less consistent with network fingerprint evidence, which can indicate relaying or spoofing.

location_spoofing

Score

Location-spoofing score from 0 to 1. Higher values mean several location clues disagree or the implied displacement is larger, increasing confidence in deliberate geo-evasion.

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

network_latency_anomaly

Signal

Round-trip timing is unusually high for the claimed region and connection type, consistent with a distant tunnel.

network_fingerprint_anomaly

Signal

Low-level network behavior conflicts with the claimed browser.

network_device_os_mismatch

Signal

Operating system inferred from packet behavior disagrees with the claimed operating system.

true_country_mismatch

Signal

Verisoul's resolved true country differs from the raw IP country.

ip_on_datacenter_list

Signal

IP appears in a known datacenter or cloud-hosting range.

ip_device_timezone_mismatch

Signal

Device timezone is geographically far from the IP location.

ip_device_lang_country_mismatch

Signal

Device language implies a country inconsistent with the IP location after common benign variants are excluded.

outside_expected_countries

Signal

IP country or resolved true country falls outside the account's declared expected countries.

ip_on_proxy_list

Signal

One or more IP intelligence sources identify the IP as a proxy.

true_ip_leak

Signal

A network probe observed another IP that reveals a different network identity.

ip_on_vpn_list

Signal

IP intelligence identifies the address as a VPN exit or known VPN service.

mobile_vpn_tunnel_detected

Signal

Native device configuration shows an active VPN tunnel interface.

mobile_proxy_configured

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

browser_tampering_detected

Signal

Browser internals appear modified by anti-detect tooling or property manipulation.

voice_or_audio_anomaly

Signal

Speech, audio, or media capabilities conflict with the claimed OS and browser.

gpu_anomaly

Signal

Graphics evidence shows software rendering, a VM driver, or a device mismatch.

os_claim_inconsistent_with_evidence

Signal

Rendering, worker, or permission evidence conflicts with the claimed OS.

vm_or_emulator_indicators

Signal

Storage, geometry, timing, touch, or system-UI details resemble a VM, headless browser, or emulator.

uncommon_hardware_profile

Signal

CPU, memory, or low-level numeric behavior falls outside realistic ranges for the device type.

automation_framework_detected

Signal

WebDriver, developer-protocol control, or another automation artifact is present.

font_or_emoji_anomaly

Signal

Fonts or emoji rendering imply a different OS from the one claimed.

environment_probe_anomaly

Signal

Minor environment probes are inconsistent or missing.

android_emulator_or_rooted

Signal

Android appears rooted, emulated, debug-signed, or exposes emulator network interfaces.

android_device_anomaly

Signal

Android brand is inconsistent with the region or carrier context.

ios_simulator_or_jailbreak

Signal

iOS appears simulated, jailbroken, debugged, location-simulated, or inconsistent with Apple hardware.

android_app_integrity_failed

Signal

Google Play Integrity reports an app-recognition, licensing, or device-recognition failure.

ios_hardware_or_version_anomaly

Signal

iOS version, CPU, memory, thermal, battery, or usage evidence conflicts with genuine Apple hardware.

android_developer_mode_enabled

Signal

USB debugging or Android developer settings are enabled.

android_manual_time_settings

Signal

Automatic time or timezone is disabled on Android.

android_clone_or_virtual_app

Signal

App runs inside a clone or virtual-app container.

data_collection_blocked

Signal

A large share of device probes returned empty or placeholder values.

android_abnormal_boot_profile

Signal

Boot history is unusually low, high, or inconsistent with device age.

mobile_device_locale_null

Signal

Native device reports no locale or language configuration.

chinese_sanctioned_device

Signal

Device brand is an OEM restricted by US or European carrier policy and can appear regardless of score level.

chinese_device

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

brand

Data

Native device brand, such as Apple, samsung, or google.

model

Data

Native device model; iOS reports the generic family such as iPhone or iPad.

system_memory_gb

Data

Total device RAM; currently null on Android.

boot_count

Data

Number of device boots; iOS returns null because the platform leaves it unavailable.

system_uptime_days

Data

Days since the device last booted.

battery_level

Data

Current battery charge; currently null on Android.

languages[]

Data

Native device language preferences.

oem_app_integrity

Data

Platform app-attestation verdict: Play Integrity on Android or App Attest on iOS.

oem_device_integrity

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

id

Data

Stored account identifier.

email

Data

Stored email address.

phone

Data

Stored phone number in E.164 format.

first_name

Data

Stored first name.

last_name

Data

Stored last name.

username

Data

Stored username.

expected_countries[]

Data

Stored two-letter countries where the account should operate.

metadata

Data

Stored customer-defined key-value context.

group

Data

Multi-account graph group assigned to the account.

History

Field

Label

Description

num_sessions

Data

Total sessions associated with the account.

first_seen

Data

First time the account was observed.

last_seen

Data

Most recent time the account was observed.

last_session

Data

Most recent session ID for the account.

country

Data

Most recently associated account country.

countries[]

Data

Distinct countries observed across the account's sessions, including resolved true countries.

Unique devices

Field

Label

Description

1_day

Data

Unique devices observed in the last day.

7_day

Data

Unique devices observed in the last seven days.

Unique networks

Field

Label

Description

1_day

Data

Unique networks observed in the last day.

7_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

email

Data

Email address evaluated by email intelligence.

disposable

Data

Indicates a disposable email provider.

personal

Data

Indicates a public or personal email provider.

valid

Data

Verisoul's email-validity result.

domain_type

Data

Classification of the email's apex domain.

email_score

Score

Unified email score from -1 for highest trust to 1 for highest risk. Positive values reflect riskier address or domain evidence, while negative values reflect stronger tenure, reputation, or infrastructure trust; null means scoring is incomplete.

trust_signals[]

Signal

Positive email or domain reason codes.

risk_signals[]

Signal

Risky email or domain reason codes.

num_account_from_domain

Data

Real-time count of project accounts sharing the same apex domain; subdomains roll up to the apex.

Domain type values

Value

Label

Description

relay

Data

Email-forwarding or privacy-relay domain.

personal

Data

Public consumer email provider.

disposable

Data

Temporary or throwaway email provider.

business

Data

Business-owned domain.

government

Data

Government-entity domain.

education

Data

Educational-institution domain.

invalid

Data

Domain lacks valid mail-routing support.

not_active

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

email_invalid

Signal

The address is not valid email syntax, which prevents dependable communication or ownership verification.

email_high_number_count

Signal

The local part contains more than five numbers, a pattern often associated with generated addresses used for bulk account creation.

email_high_period_count

Signal

The local part contains more than two periods, an unusual structure that can support generated-address or aliasing risk when other evidence agrees.

email_high_number_numeric_blocks

Signal

The local part contains more than one number block, a structure that can indicate automated address generation.

email_business_with_numbers

Signal

A business-domain local part contains numbers. This can indicate generated workforce-style identities, although legitimate company naming conventions can also produce it.

email_suspicious_keyword

Signal

The local part contains a term associated with temporary or fraudulent use, which raises concern that the identity was created for abuse.

email_alias

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.

email_role_keyword

Signal

The address represents a role such as HR or sales. Shared role mailboxes weaken the link between the address and one person.

email_no_reply

Signal

The local part indicates a no-reply mailbox, which is unlikely to be controlled by the user completing the flow.

email_not_deliverable

Signal

The address cannot receive email, preventing email-based verification and reliable communication.

email_likely_generated

Signal

The address structure appears random or machine-generated, which can indicate automated signup or bulk account creation.

email_young_age

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.

email_no_online_history

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.

email_unknown_age

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.

email_too_many_breaches

Signal

The email appears in more than 50 known breaches, which raises credential-exposure and account-takeover risk even when the user is legitimate.

email_risky_online_history

Signal

The email appears in a high-risk breach, which can indicate elevated credential or identity risk.

email_mailbox_full

Signal

The mailbox exists but is full. This weakens immediate deliverability, although it is operational evidence rather than strong fraud evidence.

domain_relay_type

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.

domain_disposable_type

Signal

The domain is a known disposable provider, making it easier to create short-lived identities and repeat signup or promotion abuse.

domain_low_trust_business

Signal

The business domain has low trust, which provides less evidence that the address belongs to an established organization.

domain_no_mx_record

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.

domain_suspicious_keywords

Signal

The domain contains terms associated with temporary or throwaway use, which can indicate an address created for short-lived abuse.

domain_whois_less_than_1_year

Signal

The domain was registered less than one year ago, providing limited operating history and increasing risk in identity-sensitive onboarding.

domain_risky_personal

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.

domain_does_not_resolve

Signal

The domain does not resolve to an IP, which makes the address operationally suspect and weakens its value as identity evidence.

domain_invalid

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

email_age_greater_than_3_years

Signal

The email was first seen more than three years ago, adding positive identity-tenure evidence that can reduce risk.

email_age_greater_than_5_years

Signal

The email was first seen more than five years ago, adding stronger positive identity-tenure evidence.

email_age_greater_than_10_years

Signal

The email was first seen more than ten years ago, providing substantial tenure evidence while leaving current ownership to separate verification.

email_age_greater_than_15_years

Signal

The email was first seen more than fifteen years ago, providing high-tenure evidence while leaving account-takeover risk possible.

email_known_online_history

Signal

The email has known breach-based history, which supports that the address has existed over time but does not prove current ownership.

email_trusted_online_history

Signal

The email appears in high-trust historical sources, adding positive evidence of an established identity.

domain_trusted_type

Signal

The domain is a trusted government or education type, adding positive organizational context.

domain_trusted_personal

Signal

The personal provider has higher observed trust relative to Gmail, lowering the domain baseline without replacing address-level checks.

domain_high_trust_business

Signal

The domain is a known high-trust business, adding positive evidence that the address belongs to an established organization.

domain_high_trust_email_provider

Signal

The domain uses a known enterprise email provider, adding positive infrastructure trust without proving the user's identity.

domain_whois_greater_than_5_years

Signal

The domain was registered more than five years ago, adding tenure evidence that can reduce domain risk.

domain_trusted_relay

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

device_risk

Aggregate score

Time-decayed score from 0 to 1 across the account's sessions, with recent sessions weighted more heavily. Higher values mean the pattern is more persistent. Repeated device-integrity or automation risk is more concerning than one isolated device anomaly.

proxy

Aggregate score

Time-decayed score from 0 to 1 across the account's sessions, with recent sessions weighted more heavily. Higher values mean the pattern is more persistent. Repeated proxy use can show persistent origin masking rather than a one-time privacy choice.

vpn

Aggregate score

Time-decayed score from 0 to 1 across the account's sessions, with recent sessions weighted more heavily. Higher values mean the pattern is more persistent. Repeated VPN evidence can show persistent location or network masking, while established legitimate use remains possible.

tor

Aggregate score

Time-decayed score from 0 to 1 across the account's sessions, with recent sessions weighted more heavily. Higher values mean the pattern is more persistent. Repeated Tor access persistently weakens origin attribution for the account.

spoofed_ip

Aggregate score

Time-decayed score from 0 to 1 across the account's sessions, with recent sessions weighted more heavily. Higher values mean the pattern is more persistent. Repeated spoofed-IP evidence suggests a durable attempt to conceal the account's network origin.

datacenter

Aggregate score

Time-decayed score from 0 to 1 across the account's sessions, with recent sessions weighted more heavily. Higher values mean the pattern is more persistent. Repeated hosting-origin access can indicate persistent automation or provisioned infrastructure.

recent_fraud_ip

Aggregate score

Time-decayed score from 0 to 1 across the account's sessions, with recent sessions weighted more heavily. Higher values mean the pattern is more persistent. Repeated exposure to recently fraudulent IP infrastructure is stronger evidence than one isolated session.

impossible_travel

Aggregate score

Time-decayed score from 0 to 1 across the account's sessions, with recent sessions weighted more heavily. Higher values mean the pattern is more persistent. Repeated impossible travel increases concern about account sharing, takeover, or location masking.

device_network_mismatch

Aggregate score

Time-decayed score from 0 to 1 across the account's sessions, with recent sessions weighted more heavily. Higher values mean the pattern is more persistent. Repeated device-and-network inconsistency suggests a persistent relay or spoofing pattern.

location_spoofing

Aggregate score

Time-decayed score from 0 to 1 across the account's sessions, with recent sessions weighted more heavily. Higher values mean the pattern is more persistent. Repeated location-spoofing evidence is more consistent with durable geo-evasion than an isolated mismatch.

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

account_id

Data

Identifier of the linked account.

score

Score

Confidence from 0 to 1 that the two accounts are connected. A high link score matters when multiple accounts are restricted, but it does not by itself mean either account is fraudulent.

email

Data

Email associated with the linked account.

phone

Data

Phone associated with the linked account.

first_name

Data

First name associated with the linked account.

last_name

Data

Last name associated with the linked account.

username

Data

Username associated with the linked account.

expected_countries[]

Data

Declared operating countries for the linked account.

first_seen

Data

First time the linked account was observed.

last_seen

Data

Most recent time the linked account was observed.

match_type[]

Signal

Evidence categories that linked the two accounts.

lists[]

Data

List memberships of the linked account.

metadata

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

browser

Signal

Deterministic browser match; the published guide says it produces a link score of 1. It is strong evidence that two accounts used the same browser, which matters when shared access is not allowed.

device

Signal

Probabilistic match based on hardware and software characteristics. A high pairwise score can connect accounts, while common device profiles reduce confidence.

network

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.

email

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.

phone

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.

username

Signal

Exact normalized username match. Reuse strongly connects accounts and receives full linkage weight.

name

Signal

Exact normalized name match. It is moderate evidence because unrelated people can share names, so another match type improves confidence.

mobile_id

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.

apple_device_check

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

statusCode

Data

HTTP status code in the documented error body.

message

Data

Human-readable error message, such as Session ID not found.

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, and Fake, 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 unavailable values 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 0 to 1 for bot, while the Bot page says 0 to 100 and 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 uses accounts_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.

Primary sources