Email fraud detection API: check signups by digital footprint

What an email fraud detection API sees in a thin footprint

Fraudulent signups share a trait that document checks miss: the email address was created for the occasion. It has no Spotify, no Instagram, no GitHub, no breach record from 2014, no forum post from 2019. A real customer’s address, by contrast, has been registered across a handful of the 887+ platforms we check, usually for years. The response below is what a freshly minted address looks like: matches: 0, socialMatches: 0, an empty breach list and no web mentions.

curl -X POST "https://api.digifootprint.dev/v1/lookup?wait=true" \
  -H "Authorization: Bearer dfp_your_key" \
  -H "Content-Type: application/json" \
  -d '{"query": "qx7t2mv9@example.com"}'

{
  "lookupId": "3b9e0c7a-...",
  "query": "qx7t2mv9@example.com",
  "platformsChecked": 887,
  "matches": 0,
  "socialMatches": 0,
  "servedFromCache": false,
  "results": [
    { "platform": "instagram", "registered": false, "method": "public_api", "checkedAt": "2026-08-30T08:41:12.004Z" },
    { "platform": "spotify",   "registered": false, "method": "public_api", "checkedAt": "2026-08-30T08:41:12.117Z" },
    { "platform": "github",    "registered": false, "method": "public_api", "checkedAt": "2026-08-30T08:41:12.230Z" },
    { "platform": "pinterest", "registered": false, "method": "public_api", "checkedAt": "2026-08-30T08:41:12.298Z" }
  ],
  "breaches": [],
  "webMentions": [],
  "phoneDetails": null
}

Nothing in this response is inferred. Every registered: false is a platform that answered and confirmed no account exists. A platform that could not be confirmed is left out of results entirely, which is why platformsChecked is not the same as the length of the array. Absence is never reported as a fact; see the response reference for the exact semantics.

Where the check fits in a fraud stack

Three integration patterns cover most teams. Inline at signup with ?wait=true is the simplest but waits for the slowest platform, so budget a few seconds. Asynchronous is more common: create the account, queue the lookup without wait, and gate the first withdrawal, listing or payout on the result. For manual review tooling, stream the results so an analyst sees the first matches in well under a second instead of staring at a spinner.

Requests are rate-limited per API key with the remaining budget in every response header, and lookups against the same input inside the freshness window are served from cache with servedFromCache: true so re-checking a returning user does not burn quota. Details are on the rate limits page. Keep the key on your backend: the terms prohibit exposing it to end users, and a browser-held key is itself a fraud vector.

Phone numbers, usernames and the other two inputs

The same endpoint accepts a phone number or a username, auto-detected from the query. Phone lookups are in beta with a limited set of platforms that register by number, so treat a phone footprint as a supplementary signal rather than the primary one; when a phone is queried, phoneDetails carries validity, carrier and line type where those could be established, and null where they could not. Username lookups reach the widest set of platforms and are useful when a signup handle is reused elsewhere; the fake account detection page covers that pattern in more depth.

What this API deliberately does not do

It does not return profile contents. No names, photos, bios, locations or posts are collected from any platform: the result is whether an account exists for the identifier, established how, at what time. It does not declare anyone a fraudster, and our terms are explicit that a result is one input to a decision that remains yours. Those boundaries are what make it usable at signup, in regulated onboarding (see KYC and AML) and under GDPR, where the identifier being checked is one the person handed you. There are free lookups to start and pricing is on the pricing section.