# Holehe Account Detection Methods: How the Email OSINT Tool Checks 150+ Services

> Discover Holehe account detection methods. Learn how this OSINT tool checks 150+ services by analyzing HTTP responses to find existing email accounts.

- Repository: [Palenath/holehe](https://github.com/megadose/holehe)
- Tags: deep-dive
- Published: 2026-08-17

---

**Holehe detects email registrations across hundreds of online services by executing a dedicated async function for each platform, analyzing HTTP responses to determine if an account exists.**

Holehe is an open-source **email OSINT (Open Source Intelligence)** tool maintained by `megadose/holehe` that performs bulk account enumeration. Unlike simple aggregators, Holehe implements **service-specific detection logic** for each platform it supports. This article breaks down the architectural patterns, detection techniques, and module organization that power Holehe's account detection capabilities.

## Core Architecture: Modular Async Functions

Every detection method in Holehe follows a standardized contract. As implemented in `megadose/holehe`, each service module exposes a single async function with this signature:

```python
async def <service_name>(email: str, client, out: dict) -> dict:
    ...

```

The **orchestration engine** in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) discovers and invokes these functions dynamically. It iterates over a registry of module names, imports each submodule, and executes the detection logic concurrently.

```python

# From holehe/core.py – the main execution loop

async def run(email: str, client: httpx.AsyncClient) -> dict:
    out = {}
    for module_name in sorted(import_module_names()):
        mod = import_module(f"holehe.modules.{module_name}")
        detection_func = getattr(mod, module_name)
        result = await detection_func(email, client, out)
        if result:
            out[module_name] = result
    return out

```

This design decouples the **core engine** from **service-specific implementations**, allowing contributors to add new detection methods without modifying central code.

## Detection Pattern: HTTP Response Analysis

Holehe account detection methods follow a consistent four-step pattern across all services:

1. **Request preparation** – Construct `GET` or `POST` requests with headers, including randomized **User-Agent strings** from [`holehe/localuseragent.py`](https://github.com/megadose/holehe/blob/main/holehe/localuseragent.py)
2. **HTTP execution** – Send requests via the shared `httpx.AsyncClient` instance
3. **Response interpretation** – Analyze **status codes** (`200`, `404`, `409`, `422`), **JSON payloads**, or **redirect behavior**
4. **Result emission** – Return a standardized dictionary indicating `found`, `not_found`, or `unknown`

Each service requires custom logic due to differing endpoint structures, CSRF protections, and rate-limiting strategies.

## Social Media Detection Methods

The `holehe/modules/social_media/` directory contains the highest concentration of detection implementations. These modules target platforms where email-to-account mapping is particularly valuable for OSINT investigations.

| Service | Source File | Detection Technique |
|---------|-------------|-------------------|
| **Instagram** | [`holehe/modules/social_media/instagram.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/instagram.py) | Checks registration endpoint for email existence |
| **Facebook** | [`holehe/modules/social_media/facebook.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/facebook.py) | Validates against account recovery flows |
| **Twitter/X** | [`holehe/modules/social_media/twitter.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/twitter.py) | API endpoint analysis for email association |
| **Discord** | [`holehe/modules/social_media/discord.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/discord.py) | Registration form validation |
| **Pinterest** | [`holehe/modules/social_media/pinterest.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/pinterest.py) | Email availability check via signup flow |
| **Snapchat** | [`holehe/modules/social_media/snapchat.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/snapchat.py) | Account lookup endpoint probing |
| **Strava** | [`holehe/modules/social_media/strava.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/strava.py) | Password reset flow analysis |
| **Wattpad** | [`holehe/modules/social_media/wattpad.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/wattpad.py) | Direct email verification endpoint |
| **VSCO** | [`holehe/modules/social_media/vsco.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/vsco.py) | User existence via API responses |

Additional social platforms include **XING**, **Plurk**, **MySpace**, **Odnoklassniki**, **Bitmoji**, **Fanpop**, **Parler**, **Patreon**, **Tellonym**, and **Taringa!** — each with dedicated detection logic in the same directory.

## E-Commerce and Shopping Platforms

The `holehe/modules/shopping/` package implements account detection for retail and service platforms where purchase history may be linked to email addresses.

- **Amazon** ([`holehe/modules/shopping/amazon.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/shopping/amazon.py)) – Tests against account creation and password reset endpoints
- **eBay** ([`holehe/modules/shopping/ebay.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/shopping/ebay.py)) – Registration validation flow
- **Vivino** ([`holehe/modules/shopping/vivino.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/shopping/vivino.py)) – Email existence check via API

Extended coverage includes **Domino's**, **Deliveroo**, **Garmin**, **Naturabuy**, and numerous regional e-commerce platforms.

## Developer and Programming Platforms

For technical target profiling, Holehe includes detection methods in `holehe/modules/programing/`:

| Platform | Implementation File |
|----------|---------------------|
| **GitHub** | [`holehe/modules/programing/github.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/programing/github.py) |
| **Replit** | [`holehe/modules/programing/replit.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/programing/replit.py) |
| **Codecademy** | [`holehe/modules/programing/codecademy.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/programing/codecademy.py) |
| **CodePen** | [`holehe/modules/programing/codepen.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/programing/codepen.py) |
| **TeamTreehouse** | [`holehe/modules/programing/teamtreehouse.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/programing/teamtreehouse.py) |
| **DevRant** | [`holehe/modules/programing/devrant.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/programing/devrant.py) |

These modules often exploit **public API endpoints** or **signup validation** routes that leak account existence without authentication.

## Music, Entertainment, and Media Services

The `holehe/modules/music/` and `holehe/modules/medias/` directories handle streaming and content platforms:

- **Spotify** ([`holehe/modules/music/spotify.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/music/spotify.py)) – Email check via registration endpoint
- **SoundCloud** ([`holehe/modules/music/soundcloud.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/music/soundcloud.py)) – Account existence via password reset
- **Last.fm** ([`holehe/modules/music/lastfm.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/music/lastfm.py)) – User lookup API
- **TuneFind** ([`holehe/modules/music/tunefind.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/music/tunefind.py)) – Registration validation
- **Flickr** ([`holehe/modules/medias/flickr.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/medias/flickr.py)) – Yahoo-derived account system probing
- **Ello** ([`holehe/modules/medias/ello.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/medias/ello.py)) – Email availability endpoint

## Product Brand Accounts and Loyalty Programs

Major consumer brands maintain account systems targeted in `holehe/modules/products/`:

- **Samsung** ([`holehe/modules/products/samsung.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/products/samsung.py)) – Samsung Account validation
- **Nike** ([`holehe/modules/products/nike.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/products/nike.py)) – NikePlus/Member account check
- **Eventbrite** ([`holehe/modules/products/eventbrite.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/products/eventbrite.py)) – Organizer and attendee account detection

## Payment and Financial Services

Limited but critical coverage exists for financial platforms:

- **Venmo** ([`holehe/modules/payment/venmo.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/payment/venmo.py)) – PayPal-owned peer-to-payment account enumeration

## Communication and Email Providers

Holehe can verify accounts on email services themselves via `holehe/modules/mails/`:

| Provider | Detection Module |
|----------|----------------|
| **Gmail/Google** | [`holehe/modules/mails/google.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/mails/google.py) |
| **Yahoo Mail** | [`holehe/modules/mails/yahoo.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/mails/yahoo.py) |
| **ProtonMail** | [`holehe/modules/mails/protonmail.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/mails/protonmail.py) |
| **Mail.ru** | [`holehe/modules/mails/mail_ru.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/mails/mail_ru.py) |

These modules test whether an email address is **already registered** as a primary account on the respective service, distinct from third-party platform associations.

## Additional Service Categories

Holehe's modular structure extends account detection to specialized domains:

**Learning Platforms** (`holehe/modules/learning/`)
- **Duolingo** – Language learning account existence
- **Quora** – Q&A platform registration status
- **Diigo** – Social bookmarking service

**Medical and Health** (`holehe/modules/medical/`)
- **SevenCups** – Mental health support community
- **CaringBridge** – Health journey sharing platform

**Job Boards** (`holehe/modules/jobs/`)
- **Freelancer** – Gig economy platform
- **SEOclerks** – Digital services marketplace
- **Coroflot** – Creative portfolio and recruitment

**Transportation**
- **BlaBlaCar** ([`holehe/modules/transport/blablacar.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/transport/blablacar.py)) – Ridesharing service

**OSINT Enrichment**
- **RocketReach** ([`holehe/modules/osint/rocketreach.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/osint/rocketreach.py)) – Professional contact database

## Developer Workflow: Adding Custom Detection Methods

To implement a new service detection method, create a file in the appropriate `holehe/modules/` subdirectory:

```python

# Example: holehe/modules/custom/example_service.py

import httpx

async def example_service(email: str, client: httpx.AsyncClient, out: dict):
    """
    Detect if email is registered on ExampleService.
    Returns dict with status: 'found', 'not_found', or 'unknown'.
    """
    headers = {
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.0"
    }
    
    # Service-specific endpoint and payload

    response = await client.post(
        "https://example.com/api/check-email",
        json={"email": email},
        headers=headers
    )
    
    # Interpret response based on service behavior

    if response.status_code == 200:
        data = response.json()
        if data.get("exists") is True:
            return {"status": "found", "url": f"https://example.com/user/{email}"}
        return {"status": "not_found"}
    
    return {"status": "unknown"}

```

Register the module by ensuring the filename matches the function name, then add it to [`holehe/__init__.py`](https://github.com/megadose/holehe/blob/main/holehe/__init__.py) if not using automatic discovery.

## Key Files in Holehe's Detection System

| File Path | Purpose |
|-----------|---------|
| [`holehe/__init__.py`](https://github.com/megadose/holehe/blob/main/holehe/__init__.py) | Public API exposure and module registration |
| [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) | Orchestration engine for running all detection methods |
| [`holehe/localuseragent.py`](https://github.com/megadose/holehe/blob/main/holehe/localuseragent.py) | Randomized User-Agent generation for request fingerprinting |
| `holehe/modules/*/*.py` | Individual service detection implementations |

## Summary

- Holehe uses **dedicated async functions** for each of 150+ services, all following a standardized signature
- Detection relies on **HTTP response analysis**: status codes, JSON bodies, and redirect patterns
- The **modular architecture** in `holehe/modules/` organizes methods by service category (social_media, shopping, programing, etc.)
- **Core orchestration** in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) dynamically discovers and executes detection functions concurrently
- Each implementation handles **service-specific quirks** including CSRF tokens, rate limits, and endpoint variations
- The tool supports **direct module import** for testing individual services or building custom workflows

## Frequently Asked Questions

### How does Holehe avoid being blocked when checking hundreds of services?

Holehe rotates **User-Agent strings** via [`holehe/localuseragent.py`](https://github.com/megadose/holehe/blob/main/holehe/localuseragent.py) and uses the shared `httpx.AsyncClient` for connection pooling. However, aggressive enumeration may still trigger rate limits — the tool is designed for **targeted OSINT investigations** rather than bulk untargeted scanning.

### Can I run Holehe detection methods for just one specific service?

Yes. Import the module directly and call its async function with an `httpx.AsyncClient` instance:

```python
from holehe.modules.social_media import instagram
import httpx

async with httpx.AsyncClient() as client:
    result = await instagram("target@example.com", client, {})
    print(result)  # {'status': 'found'|'not_found'|'unknown', ...}

```

### What determines whether Holehe returns "found", "not_found", or "unknown"?

Each service module implements custom logic based on **documented API behavior** and **empirical testing**. A **"found"** result requires confident confirmation of account existence (e.g., explicit "email already registered" message). **"Unknown"** indicates ambiguous responses, network failures, or protections that prevent reliable determination.

### Does Holehe require API keys for any detection methods?

The vast majority of Holehe detection methods operate against **public, unauthenticated endpoints** — registration pages, password reset flows, and email validation APIs. No API keys are required for core functionality, though some services implement protections (CAPTCHA, IP blocking) that may limit effectiveness.