How do I check if an email has been in a data breach with an API?

Send the address to POST /v1/lookup. The breaches field of the response lists every known breach the address appeared in, each with the breach name and the date it occurred. The same response carries the platforms the address is registered on, so you do not need a second call.

Does appearing in a breach mean the email account is compromised?

No. It means the address was in a dataset exposed by a breach of that service on that date. Whether any password still works is unknown to us and not claimed. For risk scoring, breach history is mostly evidence that an address has existed for a long time.

What is the difference between breaches being empty and being null?

An empty array means breach data was checked and the address appears in no known breach. null means breach data is not enabled for your account, so nothing was checked. They are different facts and the API never blurs them.

Does the breach check work for usernames or phone numbers?

Breach data is keyed on email addresses. For a phone number query the breaches field is null. Send the email address when you have one; a username or number gives you the platform footprint but not breach history.

Email breach check API: has this address appeared in a breach?

Updated 2026-08-30

The lookup endpoint answers a second question alongside where an email address is registered: which known data breaches it has appeared in, by name and date. One request, one response, and a strict line between checked-and-empty and not-checked.

What the email breach check API returns

breaches is an array of records, one per known breach the address has appeared in. Each record carries the breach name - the service that was breached - and the date the breach occurred, as an ISO date. That is the whole record. The API does not return the exposed data itself, passwords or hashes, or anything from the breach dump beyond the fact of inclusion; it tells you the address was in the Adobe breach of October 2013, not what was in the row.

POST /v1/lookup?wait=true

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

Response (abridged)

{
  "query": "someone@example.com",
  "platformsChecked": 887,
  "matches": 3,
  "socialMatches": 2,
  "servedFromCache": false,
  "results": [
    { "platform": "linkedin", "registered": true, "method": "public_api", "checkedAt": "2026-08-30T08:41:12.004Z" },
    { "platform": "spotify",  "registered": true, "method": "public_api", "checkedAt": "2026-08-30T08:41:12.118Z" }
  ],
  "breaches": [
    { "name": "Adobe",    "date": "2013-10-04" },
    { "name": "LinkedIn", "date": "2012-05-05" },
    { "name": "Canva",    "date": "2019-05-24" }
  ],
  "webMentions": [],
  "phoneDetails": null
}

Records arrive in the same response as the platform footprint, so the address in the example is known on LinkedIn and Spotify today and was in three breaches between 2012 and 2019 - a decade of evidence that the address belongs to a person, from two independent sources, in one call.

Empty is not null: the rule that makes breach data usable

breaches: [] means breach data was consulted and the address appears in no known breach. breaches: null means breach data was not consulted - the source is not enabled for your account, or the query was a phone number, which breach data is not keyed on. A system that collapses those into one “no breaches” will score a brand-new throwaway address and a checked-and-clean address identically, which is exactly the mistake a fraud model cannot afford. Treat null as “unknown” in your code, and make it a distinct branch.

The same discipline runs through the rest of the response. A platform that could not be confirmed is omitted from results rather than reported as not registered, and webMentions follows the same empty-versus-null convention as breaches. The lookup reference spells out every field.

Using breach history in a risk score

The intuitive reading - breached address, therefore risky - is usually backwards for signup risk. An address that appears in a 2012 breach has existed since at least 2012. That is strong evidence of a real, long-lived identity, and it is precisely what a synthetic or disposable address cannot produce: you cannot backdate a breach. So for signup verification and KYC, breach history mostly moves a score toward “real person”, and the earliest date is the useful number: it is a lower bound on the address’s age.

The other reading matters for account protection rather than onboarding. An address in a recent breach is one whose credentials may be circulating, which is a reason to require a strong password or a second factor at signup, or to prompt a reset for an existing user. Both readings are yours to make; the API returns the names and dates and stays out of the judgement. It also does not claim anything about whether a particular password was exposed or still works, because it does not know.

Streaming breach results

On the streaming endpoint breach data arrives as its own named event, breach_result, independently of the per-platform platform_result events. Breach data usually lands early, so a UI can show the breach timeline while the platform sweep is still filling in, and a risk pipeline can start scoring before done.

Event stream (breach_result)

event: breach_result
data: {"breaches":[{"name":"Adobe","date":"2013-10-04"},{"name":"LinkedIn","date":"2012-05-05"}]}

Freshness, caching and what counts as a check

Breach history changes slowly - a breach from 2013 is still a breach from 2013 - so it is cached for longer than a registration result, and the caching page says how long. A response that reused anything says so with servedFromCache: true. A cached breach list counts as a lookup the same as a fresh one; caching exists to make repeat queries fast and consistent, not to change what you pay for. The rest of what a lookup returns for an email - the platform footprint, derived handles and web mentions - is on the reverse email lookup guide. Free lookups to start - see pricing.

Frequently asked questions

How do I check if an email has been in a data breach with an API?: Send the address to POST /v1/lookup. The breaches field of the response lists every known breach the address appeared in, each with the breach name and the date it occurred. The same response carries the platforms the address is registered on, so you do not need a second call.
Does appearing in a breach mean the email account is compromised?: No. It means the address was in a dataset exposed by a breach of that service on that date. Whether any password still works is unknown to us and not claimed. For risk scoring, breach history is mostly evidence that an address has existed for a long time.
What is the difference between breaches being empty and being null?: An empty array means breach data was checked and the address appears in no known breach. null means breach data is not enabled for your account, so nothing was checked. They are different facts and the API never blurs them.
Does the breach check work for usernames or phone numbers?: Breach data is keyed on email addresses. For a phone number query the breaches field is null. Send the email address when you have one; a username or number gives you the platform footprint but not breach history.

Start free Try a lookup