Email OSINT Checker, Account Finder, Reverse Lookup, 210+ Sites

Give it 1 email address: it looks that address up on 210+ sites and returns 1 row per site it is registered on — without any password-reset email reaching the target. 210+ is the number of sites a lookup is sent to; not every site answers every lookup, and you are billed only for lookups that returned a confirmed answer. Find which accounts an email address has signed up for. This email lookup / email OSINT tool discovers which sites an email is registered on — Twitter, Spotify, Pinterest, Imgur, Tumblr, Adobe, and many more — without ever sending a password-reset notification to the target. A fast reverse email search powered by holehe (GPL-3.0, 5.6k+ stars), a widely used open-source email OSINT tool.

Free Apify plans get a sample, paid plans get the full result set. A run on a free plan looks the first address up on every site, shows the first 3 accounts in full (plus 1 extended-site account and one row of each extra layer) and counts the rest without naming them. It ends successfully and, once the address lookup has finished, adds a free-plan-preview record (3 of 10 shown-style counts per layer, the list-price cost of the locked rows, the estimated paid cost of the addresses left unchecked) — never an error — and adds a free-plan-cap record when something was held back. Any paid plan removes every limit (all modules, up to 500 addresses per run, every account found) and applies your plan's Store discount: Bronze 20%, Silver 35%, Gold and above 48% off. See Pricing.

What a lookup costs. One address is looked up on up to 211 sites (lookups sent; the number that come back with a confirmed answer is lower and changes from run to run). Each completed lookup is billed once: account-found when the address is registered on the site and, on runs whose price table lists the site-checked event, site-checked when the site confirms the address is not registered there. A lookup the site blocked, throttled or left unanswered is never billed. Before the first lookup the run log and the run's status message state the maximum for your run at your plan's prices; maxSitesPerEmail and the run's maximum cost let you choose how much to spend. See Pricing.

Free plan vs paid plan at a glance

What you get

Sample result

One dataset item per registered account found — not one per email. An address registered on 17 sites produces 17 rows.

{
  "email": "test@gmail.com",
  "platform": "codepen",
  "exists": true,
  "domain": "codepen.io",
  "method": "register",
  "emailRecovery": null,
  "phoneNumber": null,
  "rateLimit": false,
  "charged": true,
  "sitesChecked": 121
}

A live test of test@gmail.com returned 17 confirmed accounts across 121 sites checked.

Use Cases

• Security incident response — given a breached email, map exposure across SaaS
• Fraud investigation — confirm an email is a real online identity, not a throwaway
• Counterparty due diligence — confirm a business contact's email is registered on professional platforms
• KYC enhancement — supplement identity verification with online-account footprint
• OSINT pentesting — reconnaissance phase for authorized engagements
• Data-broker compliance — auditing your own organization's email exposure

Built for security researchers, fraud investigators, OSINT analysts, KYC teams, and trust & safety teams who need to verify online presence of a given email address with zero footprint.

Not a consumer reporting agency. Do not use results to make decisions about employment, credit, housing or insurance.

Input

{
  "emails": ["alice@example.com", "bob@example.org"],
  "timeout": 30,
  "maxEmails": 10
}

Output

Username layer (username-match rows)

For each address the Actor takes the local part (jane.doe+news@example.com → janedoe) and looks that username up on the 390+ sites Sherlock covers. Each public account found is one username-match row with matchBasis: "username-from-email", the sameUsername searched and the profileUrl.

A username match is not an identity match. The row says an account with the same username exists on that site. Different people share usernames, so read it as a lead and confirm it yourself; every row carries the note Same username; not verified as the same person.

The layer is skipped, with a free username-layer-skipped notice, when the local part is four characters or fewer, is a shared mailbox such as info@ or support@, or has characters usernames cannot contain. Turn the layer off with usernameLayer: false. Up to maxUsernameCandidates (default 3) forms are searched, the 2nd and 3rd only when the run has spare time; rows for candidates 2 and 3 are less certain matches (usernameCandidateRank). On a paid plan deepUsernameSearch: true also runs Maigret (top 500 sites) on the dot-less form. Only sites Sherlock did not already return are added, as username-match rows with matchSource: "maigret". Maigret takes minutes per address, so send few addresses and raise the run timeout.

Company domain layers (domain-record and domain-asset rows)

When the address is on a company domain, includeDomainInfo (on by default) adds one row per public record: the WHOIS registration, each MX host, the SPF policy and the DMARC policy. A domain is looked up once per run, however many of your addresses share it. includeDomainAssets (off by default) adds the subdomains, host IPs and same-domain addresses listed in public certificate and host records, up to maxDomainAssets per domain (default 200). It is off by default because a single domain can return hundreds of billed rows; turn it on when you want the footprint, and set the run's maximum cost before a large batch. These rows describe a domain, not an account: exists is false on them.

Extended sites layer (account-found rows with source: "user-scanner")

extendedSites (on by default) checks 90 more sites after the 120+ site check, one lookup per site and address. Each site where the address is registered is one row with exists: true, the same shape as the other account rows plus source: "user-scanner", profileUrl and siteCategory, and it is billed as the same account-found event and price — there is no separate price. A site holehe already reported is not repeated. Sites that error leave no row and no charge. On a run priced with site-checked, an extended site that confirms the address is not registered is one not-registered row billed as site-checked, exactly like a holehe site; a site both engines cover counts once. Set extendedSites: false to get exactly the 120+ site result and bill.

The same layer also asks 11 of the holehe sites a second time — Instagram, Pinterest, Spotify, Tumblr, Adobe, Atlassian, Quora, Patreon, CodePen, Firefox and Vivino — but only for an address where holehe got no answer from that site. These are not extra sites: the site counts once towards maxSitesPerEmail and the run's maximum, and its one answer is billed once. A site holehe answered, either way, is never asked again. If two lookups of one site still end with opposite confirmed answers, neither is delivered or billed and a free site-answer-conflict notice names the site.

When run time is short, the extended sites run before the username layer, so a tight run may return fewer username-match rows than the same run with extendedSites: false. An address that holehe finds nothing on but the extended sites do is billed by account-found alone (no email-checked, no no-match row). If the run has no time left to deliver those found rows, a layer-delivery-time-budget notice counts them and the address still gets no no-match row and no email-checked charge. Where a site's only link is a Google Play or App Store page, profileUrl carries that page and domain is empty.

FAQ — are the extended sites a separate product? No. They add rows to the same account list at the same per-account price; the list of 90 sites is fixed per release and comes from user-scanner (MIT, version 1.5.2.2).

Gravatar layer (profile row)

includeGravatar (on by default) looks up the address's public Gravatar profile. If one exists you get one profile row (display name, photo URL and public profile link on paid plans; on the free plan the first profile of the run is shown in full and later ones are locked); exists is true because the profile is registered with this email. If there is no profile there is no row and no charge.

All of these layers only use run time left over after the account checks, so they never reduce how many addresses a run checks. When a run has no spare time they are skipped with a free company-layers-time-budget notice.

A confirmed account on a site holehe flags as frequently rate-limiting — still billed, with rateLimit: true telling you the site is worth re-verifying:

{
  "email": "test@gmail.com",
  "platform": "anydo",
  "exists": true,
  "domain": "any.do",
  "method": "login",
  "emailRecovery": null,
  "phoneNumber": null,
  "rateLimit": true,
  "charged": true,
  "sitesChecked": 121
}

When an address is registered nowhere, you get a completed-check row instead (platform: null, exists: false, checkCompleted: true, matchStatus: no-match, foundCount: 0). A real engine or system failure is different: the address gets an error row with checkCompleted: false and no completed-check or account-found fee. If every address fails this way, no run-start, account or completed-check fee is charged (email-analysis rows already delivered keep their own charge once that event is active), the run ends SUCCEEDED, and the status message names the cause. To detect unfinished work, check rowType: error and checkCompleted: false rather than the run status. A billing failure that cannot be confirmed still ends the run FAILED.

You can download the dataset as JSON, HTML, CSV or Excel.

Email analysis row

emailAnalysis (on by default) adds one rowType: "analysis" row per input address, before the site check, including addresses whose format is invalid (formatValid: false). Invalid inputs share the run's address limit (maxEmails, the free-plan input limit and the run-time budget) with the valid ones, and valid addresses are counted first. It does not count against the free-plan result sample. Set emailAnalysis: false to skip it.

Pricing

Current active billing:

• $0.005 once per run (event: run-started, listed as "Charged once when a run starts and performs the email investigation"). It is charged when the first address actually completes its investigation, so a run where every address fails before completion is not charged.
• $0.02 per registered account delivered (event: account-found), including accounts on the 90 extended sites.

Completed-check fee pending activation: the Actor declares $0.01 per email whose completed site investigation found no account (event: email-checked). It applies only to that no-match answer: an address with one or more accounts is billed by account-found alone, so the same address is never billed twice. The code checks the run's effective price table and charges this event only after the platform activates it; until then no email-checked charge is attempted. Invalid input and an engine or system failure that prevents completion never incur this fee.

Completed "not registered" lookups — site-checked, charged only when the run's price table lists it. The Actor declares $0.02 per completed lookup of one address on one site whose answer is a confirmed "not registered" (event: site-checked, with the same plan discounts as account-found). One lookup is one event, never two:

A site covered by both engines counts once, and a site that reported an account is never also billed as site-checked. On a run priced with site-checked the email-checked fee is not charged: the same no-account answer is not billed twice. The code reads the run's effective price table and charges site-checked only when the event is listed there. On a run whose price table does not list it, billing and output are exactly as described under "Current active billing": no site-checked charge is attempted and no not-registered rows are written.

What it means for the cost of a run priced with site-checked: an address is looked up on up to 211 sites, so the site lookups of one address cost at most 211 × $0.02 = $4.22 at list price, and less whenever sites give no confirmed answer. In a measured run (2026-10-13) an address registered nowhere got 139 confirmed answers out of 211 sites, $2.785 at list price with the run start. Before the first lookup, the run log and the run's status message state addresses × sites and the maximum for your run at your plan's prices. To spend less:

• set maxSitesPerEmail (for example 40 caps the site lookups of one address at $0.80),
• set extendedSites: false to stay on the 121 holehe sites,
• set the run's maximum cost in Run options: the run stops there, keeps what it delivered and ends successfully with a Charging limit reached record.

Free Apify plans get no not-registered rows and no site-checked charge; the free-plan-preview record counts the confirmed "not registered" lookups of the sample and includes them in the estimated paid cost.

Email analysis row — not yet active. The email-analysis event is not yet active; the row is free until it is listed on the pricing tab.

Username layer pricing — pending registration. The username-match event ($0.005 proposed per match row) is declared in the Actor but is not yet registered in the Store price list, so no username-match charge applies until it is registered and its notice period has passed. Until then the rows are delivered at no charge (

usernameMatchBillingStatus: "inactive"

Company domain and Gravatar pricing — pending registration. The domain-record ($0.005 proposed per record row), domain-asset ($0.001 proposed per asset row) and profile-found ($0.005 proposed per profile) events are declared in the Actor but are pending registration: they start after the listed effective date, once they are in the Store price list and their notice period has passed. Until then the rows are delivered at no charge (domainRecordBillingStatus, domainAssetBillingStatus and profileBillingStatus read "inactive"). The Actor charges each event only when the run's own price table carries it, and this README will be updated with the effective date before that happens.

Free plans and paid plans

The sample limits are policy, not a failure: nothing is retried, nothing errors, and the rows already delivered are kept. Your run log names the plan and the discount tier it was priced at before the first lookup starts. Platform credits, maximum-cost settings, the 500-email hard cap and the run-time budget apply on every plan.

A live test of test@gmail.com returned 17 confirmed accounts. At current active billing that is $0.345 ($0.005 run + 17 × $0.02). After the completed-check event is activated, the same run costs the same $0.345, because a found address is billed by account-found only. The $0.01 completed-check fee applies to no-match addresses.

The legacy charged field continues to describe only the account-found event. A no-match is never relabeled as an account finding. The separate emailCheckedBillingStatus field reports the once-per-email completed-check event when it is active. Notices, including free-plan-preview, are not product findings and do not create extra product fees. The examples above show Actor event fees only. Apify platform usage is charged separately under the customer's current Apify plan and the platform's applicable rates. Set the run's maximum cost in Run options before a large batch.

Large batches and the run charge limit

Every Apify run has a maximum cost, which you set per run (or per schedule) in the Actor's Run options. This Actor accepts up to 500 email addresses in a single run, and a big batch can easily find more accounts than the default limit covers.

When a run reaches its charge limit, this Actor stops checking and finishes successfully with everything it found up to that point, plus a final Charging limit reached record explaining what happened. You are never charged past your limit, and the run is not reported as a failure.

To get the full batch, do one of the following:

• Raise the run's maximum cost in Run options before starting, or
• Split the email addresses across several runs — for example 25 emails per run instead of 500.

Quick Start

curl

curl -X POST "https://api.apify.com/v2/acts/ntriqpro~email-osint-search/runs?token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"emails": ["alice@example.com"]}'

Python (Apify Client)

from apify_client import ApifyClient
client = ApifyClient("YOUR_TOKEN")
run = client.actor("ntriqpro/email-osint-search").call(run_input={
    "emails": ["alice@example.com", "bob@example.org"]
})
items = list(client.dataset(run["defaultDatasetId"]).iterate_items())
for item in items:
    if not item.get("exists"):
        continue
    flag = " (site frequently rate-limits — re-verify)" if item.get("rateLimit") else ""
    print(f"{item['email']} -> {item['platform']} ({item['domain']}){flag}")

Technology

• holehe (GPL-3.0) — Email-based account existence checker, 5.6k+ stars
• user-scanner (MIT) — Email lookup modules for the 90 extended sites
• Sherlock (MIT) — Username lookup for the username layer
• Maigret (MIT) — Deeper username lookup (top 500 sites) for the deep username search
• dnspython (ISC) — MX, SPF and DMARC lookups for the company domain layer
• Public WHOIS servers, certificate-transparency records (crt.sh, Cert Spotter), HackerTarget host search and Gravatar's public profile API — queried only for the layers you turn on
• Apify SDK for Python (Apache 2.0) — Actor runtime
• httpx (BSD) — Async HTTP client

Limitations

Disclaimer

Legal Disclaimer: This Actor is an unofficial integration of holehe (megadose) and is not affiliated with or endorsed by the original project. Use only on email addresses you own or have explicit authorization to investigate. Comply with PIPA (KR), GDPR (EU), CCPA (US), and applicable privacy laws.

This Actor is an unofficial open-source wrapper around megadose/holehe. It is not affiliated with, sponsored by, or endorsed by the holehe project, its maintainers, or any of the platforms being probed. OSINT results are based on publicly observable account-existence signals and may produce false positives.

You are solely responsible for ensuring you have legal authorization to investigate any email address. Misuse may violate privacy laws (PIPA, GDPR, CCPA, etc.) and the terms of service of target platforms. This tool is intended for security research, fraud prevention, and authorized investigation use only.

Privacy & data responsibility

You are the data controller for every search you run with this Actor; ntriqpro is a data processor acting solely on your instructions. You are responsible for having a lawful basis and a legitimate, purpose-limited reason for each lookup, and for complying with GDPR, PIPA, CCPA, and other applicable privacy laws. We do not keep copies of your inputs or results outside your own Apify run; searched identifiers are masked in run logs. These roles are governed by the Standard Actor Contract (§5.2) that applies to this Actor on Apify. Public availability of a profile is not, by itself, a lawful basis — you need your own. Use this Actor only for lawful purposes and only on email addresses you own or are authorized to investigate.

🔗 Related Actors by ntriqpro

Running several of these by hand? OSINT Recon Suite takes one target — email, username, domain or phone — runs Maigret, Sherlock, holehe, theHarvester, WHOIS and dnstwist against it, then correlates everything into a single risk-scored report. One input, one report, instead of six separate runs to stitch together yourself.

Build your full OSINT stack:

• maigret-actor — Username OSINT across 3000+ sites (5.0★ rated)
• phoneinfoga-osint — Phone number OSINT — carrier, country & footprint
• dnstwist-osint — Typosquatting & phishing domain detector
• subfinder-osint — Subdomain finder for attack-surface mapping
• gitleaks-secret-scanner — Find leaked secrets in public repos

⭐ Rate this Actor

If this saves you investigation time, please leave a review — it helps other security researchers discover it.