Digital Footprint: Email and Phone signals & categories

SEON checks whether an email address or phone number is registered on supported online platforms. Fraud, credit and risk teams use these signals to build rules, inform AI models and add context to individual investigations.

Coverage includes 350+ email and phone platform checks. There are two ways to receive this information: Standard mode returns aggregated category counts. Extended mode returns those same counts alongside individual platform results and additional profile fields where available.

A digital footprint check starts with a single identifier: an email address or phone number. Your application sends that identifier to SEON, for example when a customer creates an account or submits an application.

SEON checks supported online platforms for an account registered with that identifier. Each check can detect a registration, find no registration, or return no valid result.

Detected registrations are grouped by platform category, such as social media, entertainment or technology, and into personal and business totals. These classifications describe the services where registrations were found; they do not establish the identity or intent of the person using them. 

Standard mode returns the category and group totals. Extended mode also returns individual platform results and additional profile fields where available. Adult-site results remain category-only in both modes.

Use the results alongside other risk signals. A detected registration does not verify a person’s identity, and a small or missing footprint does not by itself establish fraud. Platform availability and timeouts can affect the results. 

Example: the same email address in both modes

In this example, SEON detects five registrations for one email address. Both modes report the same category totals. Extended mode also identifies the individual platforms.

Standard mode: category totals

Total: 5 registrations, including 4 personal and 1 business.

Extended mode: category totals plus individual results

Extended mode includes the category totals above, as well as these individual platform results. Here, true means SEON detected a registration.

This simplified example shows detected registrations only. Extended-mode API results can also include false and null, as explained in “Read account_details” under the 'Extended mode: individual platform results' section below. 

Standard mode returns account_aggregates in the API response. This object summarizes detected registrations by category and includes overall totals for the personal and business groups. It does not identify individual platforms. The same aggregate information is also available in Extended mode. 

Use category totals in decisions 

Use category totals when you need the number of detected registrations across a group of platforms, for example, in a rule evaluating social media registrations. New platforms automatically contribute to their category totals, reducing the need to maintain rules for individual platforms.

Changes in coverage or availability can change category counts. Monitor your thresholds as coverage changes, and consider the results alongside other risk signals, including the email and phone network scores. 

Category totals in the Admin Widgets

On the Transaction details page, the Email information and Phone information widgets show category totals under Digital footprint. The table below maps the displayed totals to fields inside account_aggregates in the API response.

The field paths below include the account_aggregates object name:

The widget displays categories with detected registrations. An absent category row does not confirm that every supported check returned a negative result. Review the API response and check availability when investigating gaps. 

Find results in the API response 

The response fragments in this guide omit the response envelope. The complete response places the objects at the paths below. account_details is returned with Extended mode enabled

Read account_aggregates

In the example, entertainment.registered is 2, meaning two platform checks detected a registration. entertainment.checked is 54, the number of checks recorded for that category. The category's catalog count describes supported coverage, rather than the results of this request.

Do not infer missing results solely by subtracting checked from the number of platforms in the catalog. Eligibility, configuration, availability and timeouts can affect the checks available for a request. A category object may be null when no registration is found; this is different from a platform-level registered value of null, which means no result was available.

Example category totals

This illustrative Email API v3 response fragment shows account_aggregates with four categories. It omits the response envelope and other fields. The five detected registrations match the example above. 

{
  "account_aggregates": {
    "total_registration": 5,
    "personal": {
      "total_registration": 4,
      "email_service": {
        "registered": 1,
        "checked": 10
      },
      "entertainment": {
        "registered": 2,
        "checked": 54
      },
      "social_media": {
        "registered": 1,
        "checked": 27
      }
    },
    "business": {
      "total_registration": 1,
      "technology": {
        "registered": 1,
        "checked": 47
      }
    }
  }
}

Extended mode adds account_details alongside account_aggregates. Results appear under platform-specific keys, so you can identify detected registrations and distinguish negative results from unavailable results. Some platforms also return additional profile fields.

Use platform results in decisions

Use individual results when platform identity or profile data adds useful context. For example:

• Add registration results and available profile fields as features in your own machine learning models. Handle null as missing data and evaluate these features alongside other risk signals.
• During a manual review, inspect registered platforms and compare available profile fields with the details the applicant submitted.
• Build a rule for a particular platform when a category total is too broad to express the condition you need.

Define how each rule or model handles missing data. A rule that depends on one platform can be affected by that check's availability. Evaluate platform results alongside category totals, network scores and other signals.

Registered profiles in the Admin Panel 

In Extended mode, the Email information and Phone information widgets retain the category totals and add Registered profiles. This section shows detected registrations and any available profile fields.

Registered profiles shows detected accounts. Use the API response to inspect platform results that are false or null. 

For the wider email, phone and IP widget documentation, see Digital Footprint widgets.

Read account_details 

Platform keys are case-sensitive. For example, Eventbrite appears as eventbrite and The New York Times as new_york_times. The field paths below are relative to account_details. Adult-site checks remain available as category totals only.

Platform-level registered is a boolean or null; category-level registered is an integer count. A detected registration does not guarantee additional profile data. Fields differ by platform and may be unavailable even when registered is true.

For supported checks, see Checks with additional profile fields section.

Interpret platform registration results 

Each platform check looks for an account registered with the submitted email address or phone number. In Extended mode, the platform-level registered field returns one of three values: 

A platform result can be null if a check fails or does not complete within the configured timeout. Treat this as unknown, rather than as a negative result. 

Example individual platform results 

This Extended-mode response fragment includes the same category totals as the Standard-mode example, plus individual platform results. It shows five detected registrations, one negative result and one unavailable result. 

{
  "account_aggregates": {
    "total_registration": 5,
    "personal": {
      "total_registration": 4,
      "email_service": {
        "registered": 1,
        "checked": 10
      },
      "entertainment": {
        "registered": 2,
        "checked": 54
      },
      "social_media": {
        "registered": 1,
        "checked": 27
      }
    },
    "business": {
      "total_registration": 1,
      "technology": {
        "registered": 1,
        "checked": 47
      }
    }
  },
  "account_details": {
    "discord": {
      "registered": true
    },
    "dropbox": {
      "registered": true
    },
    "eventbrite": {
      "email_verified": "false",
      "google_login_enabled": "false",
      "id": "123456789012",
      "registered": true
    },
    "figma": {
      "registered": false
    },
    "google": {
      "registered": true
    },
    "new_york_times": {
      "registered": true
    },
    "spotify": {
      "registered": null
    }
  }
}

In this example, figma.registered is false: SEON did not find a Figma account registered with the submitted email address. spotify.registered is null: no result was available, so do not treat it as false. In the Eventbrite result, email_verified and google_login_enabled are booleans that include the value false; preserve the API’s field types when parsing results.

Both Standard and Extended modes are available with Email API v3 and Phone API v2, called directly or through the Fraud API. Extended mode is enabled at the account level. Contact your account manager or support@seon.io to confirm availability and arrange access.

If your integration already uses Email API v3 or Phone API v2, Extended mode does not require an additional mode parameter in the request. Enablement is an account-level setting, separate from the configuration shown below.

If you use an older API version, first review Migrate from Email API v2 or Phone API v1.

1. Use Email API v3 or Phone API v2. If you use the Fraud API, configure the module versions as shown below.
2. Arrange Extended mode access in your sandbox environment with your account manager or support.
3. Send a test request and confirm that account_details is present alongside account_aggregates.
4. Verify that your integration handles null values and additional platform keys, then confirm production enablement with your account manager.

Example Fraud API configuration:

{
  "config": {
    "email_api": true,
    "phone_api": true,
    "email": {
      "version": "v3",
      "timeout": 5000
    },
    "phone": {
      "version": "v2",
      "timeout": 5000
    }
  }
}

How to adjust timeouts 

The results available for a request depend on the identifier, supported checks, account configuration, platform availability and timeout settings. A longer Email or Phone API timeout can improve coverage, but may increase the time spent collecting results. A timeout of 4,000 to 5,000 ms is recommended for better coverage; choose a setting that fits your workflow.

Your client-side integration timeout also includes network latency and SEON processing. Allow sufficient time for the configured enrichment timeout. Some checks require a minimum timeout or support only certain identifiers. See How to adjust Digital Footprint timeout for configuration guidance.

How to check platform availability 

Use the SEON enrichment status page to review operational updates and published restrictions, such as supported email domains, country codes or minimum timeouts.

A platform incident can affect the results returned for that check. A null result can also have other causes, so use the status page alongside your request configuration and the coverage information below. 

If you use Email API v2 or Phone API v1, your coverage is limited to 90 platform checks. Upgrade to Email API v3 or Phone API v2 to access the expanded catalog of 350+ email and phone checks.

The newer versions return category totals in Standard mode. With Extended mode enabled, they also return individual platform results and additional profile fields where available.

Available checks, platform keys and profile fields differ from the older versions. Review the fields used by your integration, rules and models before upgrading.

The tables below summarize platform-level changes. They do not cover every request or response change. Use the Email API v2 to v3 and Phone API v1 to v2 migration guide to plan the complete upgrade, including changes to request methods and other response fields. 

Removed platform checks 

The checks listed below are removed from the newer versions. Adult site checks are handled separately: their results are returned under account_aggregates.personal.adult_sites, rather than as individual entries in account_details in the API response.

Renamed platform key and fields

Update integrations that reference these renamed keys or fields. Paths in this table are relative to account_details.

Removed profile fields 

These platforms remain in the catalog, but the listed profile fields have been removed in newer versions.

Are category totals the same as network scores?

No. Category totals count detected registrations. Email and phone network scores combine registration-related features with other data to estimate fraud risk. See Email and phone network scores for the scoring explanation.

Why is account_details missing from the API response?

Check that your request uses Email API v3 or Phone API v2 and that Extended mode is enabled for the account and environment receiving the request. In the Fraud API response, look inside email_details or phone_details under data. Contact support if you still cannot locate the object.

Why does a platform return null? 

No platform result was available. Check the service status, applicable coverage restrictions and request timeout. A longer or priority timeout may help with slow checks, but will not resolve every unavailable result. Do not interpret null as false.

Why is a profile field empty when registered is true?

The check detected a registration, but the additional field may not be available. Platforms return different fields, and some return only registered. Build your integration to handle unavailable profile data.

How should models handle changes in coverage?

Support additional platform keys without treating them as errors. Before changing API versions, review removed checks, renamed keys and removed profile fields. Revalidate models and rules that depend on those inputs, and remap or retrain affected features where needed. 

Supported email platforms

The catalog below lists 293 email checks across 18 categories. Category keys are paths inside account_aggregates. These counts describe catalog coverage, rather than registrations or checks in an individual response. Available results depend on the conditions described above. 

Supported phone platforms

The catalog below lists 61 email checks across 14 categories in the same coverage snapshot. As with email checks, the category key is a path inside account_aggregates. Available results depend on the submitted number and the applicable coverage conditions.

Checks with additional profile fields

In Extended mode, the 22 email checks and 9 phone checks listed below can return profile fields in addition to registered. Available fields differ by platform, and some may be unavailable even when a registration is detected.