Updated 2026-08-30
A phone number lookup API takes a number and returns what can be verified about it: whether it is registered on the platforms that accept a phone, and its validity, carrier and line type when those are available. Phone coverage here is in beta, and this guide is candid about what that means.
Two things. First, for each platform that accepts a phone number, whether an account is registered to it (registered) and the exact moment that was established (checkedAt) - the same row shape every other input gets. Second, a phoneDetails object with valid, carrier, lineType and countryCode. Each of those is null when it could not be established, and the whole object is null when the number was not checked at all - it is only ever populated for a phone query. Breach data and web mentions are keyed on addresses and handles, so they come back null for a phone.
curl -X POST "https://api.digifootprint.dev/v1/lookup?wait=true" \
-H "Authorization: Bearer dfp_your_key" \
-H "Content-Type: application/json" \
-d '{"query": "+2348012345678"}'{
"query": "+2348012345678",
"platformsChecked": 887,
"matches": 1,
"socialMatches": 1,
"derivedMatches": 0,
"servedFromCache": false,
"results": [
{ "platform": "telegram", "registered": true, "method": "public_api", "checkedAt": "2026-08-30T12:05:31.870Z" }
],
"breaches": null,
"webMentions": null,
"phoneDetails": {
"valid": true,
"carrier": "MTN Nigeria",
"lineType": "mobile",
"countryCode": "NG"
}
}Send the number in international format with the country code. The query type is detected automatically, so the same endpoint and the same key serve email, username and phone lookups; see the lookup reference for every field.
Because the honest number is small. Of the 887 platforms in the registry, 864 accept a username, 27 accept an email address and 1 accepts a phone number - Telegram alone. Most platforms expose nothing about a number, and the ones that once did have mostly stopped. We could pad that list with guesses, and we will not: a platform appears in a response only when we can confirm the answer, and a platform we cannot confirm is omitted rather than reported as registered: false. Beta means the registration side of a phone lookup is real but narrow, that phoneDetails is the part most callers get the most out of today, and that platforms are added as and when they can be confirmed rather than announced ahead of time. The social hub and each platform page state plainly which inputs reach them, so there is never a gap between what is advertised and what comes back.
It will not tell you who the number belongs to. No name, no address, no employer, no photos, and nothing from inside any account - a reverse phone lookup here is a registration and validity check, not a directory. It will not tell you the number is unused: with so few platforms answering for a phone, an empty results array is close to meaningless as evidence of absence, and should not be read as one. It will not tell you the number is fraudulent: lineType is a fact about the line, not a verdict about the person holding it. And where the underlying data is missing, the field is null - a carrier that could not be determined stays blank rather than being filled with a plausible name. Verified or omitted, never guessed, applies to a phone exactly as it does to an email.
On its own, a phone lookup is a validity and line-type signal. At signup that is worth having: an invalid number ends the conversation, and a valid number on a non-mobile line, or from a country that does not match the rest of the application, is the kind of marker fraud prevention teams weight into a risk score. In KYC and AML review it corroborates a submitted country of residence. The stronger picture comes from pairing it. Send the applicant's email for the accounts and breach history it is registered with, their handle for the widest footprint, and the number for validity and the platforms it reaches - three responses in one shape, combined without translation. The thin digital footprint guide covers how to read the three together, and the username search API guide covers the handle side. OSINT workflows use the registration row the same way they use any other: as a confirmed place to look next, not a conclusion.
The streaming endpoint works for a phone the same way it works for an email or a username. A platform_result event arrives for each platform that answers, a phone_details_result event carries the phoneDetails object when it is ready, and done closes the stream with the summary counts. Because so few platforms answer for a number, a phone stream is short - which makes it a good fit for an inline check in a signup form, where the validity answer is the one the form is waiting on. There are free lookups to start; the pricing section has the rest.