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 886+ platforms we check, usually for years. The response below is what a freshly minted address looks like: footprint.matches: 0, footprint.socialMatches: 0, an empty breach list and no web mentions.

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

{
  "lookupId": "3b9e0c7a-...",
  "input": { "email": "qx7t2mv9@example.com", "phone": null, "username": null, "ip": null },
  "risk": null,
  "footprint": { "platformsChecked": 887, "matches": 0, "socialMatches": 0, "derivedMatches": 0, "hits": [], "servedFromCache": false, "results": [], "breaches": [], "webMentions": [], "phoneReserved": null },
  "email": null,
  "phone": null,
  "ip": null,
  "meta": { "tier": "standard", "modules": ["footprint:email"], "instant": false, "footprintComplete": true, "deadlineMs": null, "platformsPending": null }
}

Nothing in this response is inferred. An empty footprint.results means no platform confirmed an account, and a registered: false row only ever appears when a platform answered and confirmed none exists. A platform that could not be confirmed is left out of footprint.results entirely, which is why footprint.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 footprint.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, sent as phone or username instead of email. A phone number is checked on the messaging and social apps that register by number, such as WhatsApp and Telegram, and the phone module adds validity, carrier, line type, VOIP class and a risk score; when it is requested with checks: { phone: true }, phone carries those facts where they 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.