AccountFinder
Real-time reverse lookup of accounts by email
AccountFinder is a small, focused building block: you give it an email, it hits 130+ services in parallel (less than 10 seconds for all), and you get back a JSON blob describing where that email has accounts and what public profile data those sites expose.
Most big sites expose some kind of “does this email exist?” behavior in their login, signup, or password‑reset flows.
What happens under the hood
The backend looks like a conceptually easy architecture:
There is a catalog of “modules” – one per target site – that know how to ask “does this email exist here?” using login, signup or forgot‑password requests.
A coordinator spins up asynchronous HTTP calls to all these modules, with per‑site timeouts, proxies, and rate limits.
The raw HTTP responses are parsed into a common internal format and then serialized into the JSON you receive.
Holehe itself is a Python library/CLI that does this on your own machine; it checks an email across 120+ sites using exactly these flows and returns standard dicts.
Its GitHub repo at https://github.com/megadose/holehe is the canonical reference implementation for this pattern, and Account Finder basically turns the same class of logic into a hosted service with ongoing module maintenance and richer enrichment around 130+ services.
Huge respect to Megadose and the Holehe contributors – without that code and its ecosystem of forks and wrappers, many indie projects probably wouldn’t exist.
It is also fair to say that Holehe itself is now a bit outdated in places: websites ship new flows, add captchas, change HTML, so some modules break unless you keep patching them.
Operational concerns you don’t want to own
If you’ve ever tried to self‑host Holehe or similar scrapers at any volume, you know the real pain points:
Rate limits and bans: many services start throwing 429/403 or captchas after a handful of checks from one IP.
Regional behavior: some endpoints behave differently per geo or are only visible from specific regions.
Flaky flows: HTML and API responses change silently, and suddenly your “exists” check misclassifies or crashes.
To keep this running, someone has to manage rotating proxies, per‑site concurrency and custom headers, and keep chasing small HTML changes.
Account Finder’s value proposition for hackers is basically: “we’ll deal with the ugly parts (proxies, captchas, diffing DOMs), you just hit one HTTP endpoint and move on”.
Where this API fits in indie products
This is the interesting part for indie hackers: the primitive “email → set of accounts + metadata” is surprisingly composable. Some concrete use cases:
1. Antifraud: email “liveness” signals
In a signup or checkout flow, you can call Account Finder in the background and use simple heuristics on top of its response:
If email has no accounts on any mainstream services, treat it as high‑risk: maybe add extra verification, lower initial limits, or flag for review.
If email has a long‑standing, diverse footprint (major social, commerce, productivity services), bump the trust score.
You do not need anything fancy: a few lines of code to count services, look at account age and email‑verified flags are often enough to build a useful “email liveness” feature.
This is especially helpful for small fintechs, marketplaces, or SaaS that can’t afford big‑vendor fraud solutions but still want some basic defense against throwaway identities.
2. Account auditing in password managers/security tools
If you’re building a password manager, browser extension or security dashboard, you can offer a “Where is this email used?” feature:
User opts in, you call search with their email.
You show them a list of accounts they might have forgotten (old forums, trials, abandoned shops).
You push actions like “close account”, “rotate password”, “enable MFA” or “add this login to your vault”.
On the enterprise side, the same primitive helps IT and security discover unmanaged SaaS usage tied to corporate emails, without scraping everything manually.
3. Lead enrichment in marketing / sales tools
For B2B/B2C tools that only get an email on first contact, you can enrich leads cheaply:
Call AccountFinder once per new email.
Use the accounts and profile fields to:
Infer role/interest (developer tools vs design vs crypto, etc.).
Grab display names, usernames, maybe rough geo hints.
Tag/segment leads or pick the right outbound channel.
You are not scraping entire social graphs here – just using the fact that an email is or is not tied to certain platforms, and piggy‑backing on limited public profile fields to reduce cold‑start pain.
AI agents vs this kind of primitive
You might be tempted to wrap this whole thing into an AI agent (“go figure out where this email has accounts”), but for this specific task an LLM usually adds cost and latency without adding much value:
Planning and tool‑calling overhead increases response times.
Token costs stack up if you try to explain every step.
Hosted models are increasingly strict about targeted enumeration/Doxxing‑adjacent tasks, so they can randomly refuse or censor exactly the workflows you need.
The sane pattern is: use a small, boring API/MCP primitive like AccountFinder (or self‑hosted Holehe if you enjoy pain) to gather ground truth, then optionally feed the results into an LLM for softer tasks like writing reports, summarizing risk or suggesting next actions.
Comment