Updated 2026-08-30
Candidate email verification has one legitimate job in a hiring pipeline: confirming that the identifiers a candidate supplied are real and have a history, so a fabricated application is caught before anyone spends an hour interviewing it. A pre-employment digital footprint check here is exactly that narrow, and this page sets out what it returns, what our terms permit, and how to run it fairly.
Application fraud is a hiring problem before it is a security one. Remote roles attract fabricated candidates: a CV with a real person’s name and a stranger’s photo, an email address created the same morning, a GitHub handle that does not exist. A lookup on the identifiers the candidate typed into the form answers the only question that matters at that stage: are these real? The example below checks a handle listed on a CV and finds it registered on GitHub, Stack Overflow and Dribbble, consistent with the portfolio the candidate described.
curl -X POST "https://api.digifootprint.dev/v1/lookup?wait=true" \
-H "Authorization: Bearer dfp_your_key" \
-H "Content-Type: application/json" \
-d '{"query": "mariam-builds"}'{
"lookupId": "5d0b3c8e-...",
"query": "mariam-builds",
"platformsChecked": 887,
"matches": 3,
"socialMatches": 3,
"servedFromCache": false,
"results": [
{ "platform": "github", "registered": true, "method": "public_api", "checkedAt": "2026-08-30T11:18:36.720Z" },
{ "platform": "stackoverflow", "registered": true, "method": "public_api", "checkedAt": "2026-08-30T11:18:36.804Z" },
{ "platform": "dribbble", "registered": true, "method": "public_api", "checkedAt": "2026-08-30T11:18:36.911Z" },
{ "platform": "twitch", "registered": false, "method": "public_api", "checkedAt": "2026-08-30T11:18:36.977Z" }
],
"breaches": null,
"webMentions": [],
"phoneDetails": null
}The response says the handle exists on those platforms. It does not say what is on them and it does not say the candidate owns them; the latter is a question to ask the candidate, who can demonstrate it in a minute. The same request with the candidate’s email address reports which of the 887+ platforms have an account registered to it and lists known breaches with dates, which bound how long the address has existed. Field semantics are in running a lookup.
The terms of service draw a line that this page repeats because it decides whether a recruiting integration is permitted at all. Digital Footprint is not a consumer reporting agency, and a response is not a consumer report, investigative consumer report or background check as defined by the US Fair Credit Reporting Act or its equivalents elsewhere. You must not use the service, in whole or in part, as a factor in establishing anyone’s eligibility for employment. That restriction applies whatever purpose was declared at signup, and using results to decide employment on any basis prohibited by applicable law is separately listed as unlawful discrimination.
What remains is narrow and useful: recruitment screening in the sense of protecting the process. Confirming that an application is genuine, that contact details are real before outreach, that a claimed portfolio handle exists, and that a candidate identity has not been reused across a batch of applications. If a check would change whether a person is hired rather than whether an application is real, it is the wrong tool, and an FCRA-compliant provider is the right one.
Candidates are data subjects with the same rights as anyone else, and the check is processing of their personal data. Under the GDPR, the UK GDPR and comparable laws you need a lawful basis for every lookup, you must inform candidates about the processing, and where the law requires an assessment before processing you must complete it. The terms are explicit that these obligations are yours and cannot be discharged by us. In practice this means a clear statement in the application privacy notice, or explicit consent where your jurisdiction expects it, recorded before the first lookup runs.
Proportionality is the second principle. Check only the identifiers the candidate supplied, never identifiers you found. Do not run a username search to discover accounts the candidate did not mention; the investigative use of the API is for a different context with a different lawful basis. Keep the result for as long as the application is live and no longer, and give candidates a route to ask what was checked.
The response is a set of observations with provenance: registered for each platform that answered confidently, method for how that was established and checkedAt for when. A platform that could not be confirmed is omitted, so a handle missing from results is unknown, not absent, and a thin footprint is not evidence of anything. Plenty of excellent candidates keep no public accounts; a privacy-conscious engineer with an empty footprint is not a fabricated one. Treat zero matches as a prompt for a friendly verification step, such as a short call, never as a rejection.
Two fields deserve care. socialMatches excludes accounts that came with a mailbox, so a candidate’s current employer provisioning a work account never counts as their personal activity. And breaches is a list of breaches the address appears in, which says the address is old, not that the candidate was careless; it is null for username queries because breach data is keyed on email.
First, state the check in the application privacy notice and, where your jurisdiction requires it, collect consent. Second, run the lookup on the email address and any handle the candidate listed, from your backend, using ?wait=true or a queued lookup as described in the docs. Third, use the result for one decision only: does this application need a verification step before it proceeds? Fourth, when something does not line up, ask the candidate; a handle they can log into settles the question in seconds. Fifth, delete the result when the application closes. Run that way, the check confirms identifiers and stays inside the terms. There are free lookups to start; pricing is on the pricing section.