# How Holehe Uses HTTP POST Requests to Detect Account Existence: Register vs Login vs Password Recovery

> Discover how Holehe uses HTTP POST requests for registration login and password recovery to detect account existence by analyzing server responses.

- Repository: [Palenath/holehe](https://github.com/megadose/holehe)
- Tags: internals
- Published: 2026-08-19

---

**Holehe determines whether an email address is registered on a service by issuing HTTP POST requests that mimic registration, login, or password-recovery workflows, then parsing server responses for existence indicators like "already registered" or "incorrect password."**

Holehe is an open-source OSINT tool that checks email address usage across hundreds of online services without requiring valid credentials. To infer account existence, the tool exploits behavioral differences in how platforms respond to HTTP methods during the register, login, and password-recovery phases, as implemented in the megadose/holehe repository.

## The Core Detection Mechanism: HTTP POST Requests

While individual modules may issue preliminary GET requests to fetch CSRF tokens or session metadata, the definitive account existence check is always performed via HTTP POST requests. Each service module defines a `method` attribute—set to either `"register"` or `"login"`—that dictates which endpoint receives the probe. This architecture allows holehe to distinguish between "account exists" and "account not found" states by analyzing error messages and response patterns rather than authentication success.

### Register-Based Detection

Modules configured with `method = "register"` submit the target email to the service's registration endpoint alongside required form fields (such as passwords, birth dates, or hidden CSRF tokens). When a server responds with messages like "email already registered" or "account already exists," holehe marks the email as found.

In [`holehe/modules/transport/blablacar.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/transport/blablacar.py), the module sets `method = "register"` and POSTs to the registration URL:

```python

# Register-style check (Blablacar)

payload = {"email": target_email, ...}
response = await client.post(
    "https://www.blablacar.fr/register",
    headers=headers,
    data=payload,
)
if "already registered" in response.text:
    result = "found"

```

### Login-Based Detection

For modules using `method = "login"`, holehe POSTs the target email paired with an invalid password to the sign-in endpoint. A response indicating "incorrect password" or "wrong password" confirms the account exists, whereas "email not found" or "invalid user" indicates it does not. This technique avoids successful authentication while reliably revealing account presence through error differentiation.

The [`holehe/modules/social_media/snapchat.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/snapchat.py) module demonstrates this approach by declaring `method = "login"`:

```python

# Login-style check (Snapchat)

payload = {"email": target_email, "password": "invalid"}
response = await client.post(
    "https://accounts.snapchat.com/accounts/login",
    headers=headers,
    data=payload,
)
if "incorrect password" in response.text:
    result = "found"

```

### Password Recovery Detection

Although less commonly implemented as a distinct method in the current codebase, password recovery detection follows the identical POST-based pattern. The module submits the email to the "forgot password" endpoint and inspects responses for confirmations that a reset link was sent—indicating the email is registered. Modules utilizing this flow typically adhere to the same `method = "register"` or `method = "login"` conventions rather than implementing a dedicated recovery method.

## Module Architecture and Orchestration

The detection workflow is coordinated in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py), which loads each module and interprets its `method` attribute to execute the appropriate request type. The orchestrator handles asynchronous HTTP client sessions, ensuring that each module can perform preliminary GET requests to endpoints like `/?__a=1` to extract dynamic tokens (such as `fb_dtsg` in [`holehe/modules/social_media/facebook.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/facebook.py)) before issuing the decisive POST request that determines account existence.

## HTTP Method Patterns Across Service Types

- **Register checks**: Always use POST to `/signup`, `/register`, or `/create-account` endpoints with email and dummy data
- **Login checks**: Always use POST to `/login`, `/signin`, or `/auth` endpoints with email and placeholder password
- **Token fetching**: Occasional GET requests to retrieve CSRF tokens or session cookies, but never for final existence determination

## Summary

- Holehe relies exclusively on HTTP **POST** requests to detect account existence across services.
- Each module declares a `method` attribute (`"register"` or `"login"`) that determines which endpoint receives the probe.
- **Register** methods detect accounts by triggering "already registered" error messages during signup attempts.
- **Login** methods detect accounts by analyzing "incorrect password" versus "email not found" responses during authentication attempts.
- Preliminary GET requests may fetch tokens, but the existence verdict always derives from POST response analysis.

## Frequently Asked Questions

### Does holehe use GET or POST to check if an account exists?

Holehe uses **POST** requests as the definitive HTTP method for account existence checks. While some modules issue preliminary GET requests to extract CSRF tokens or session metadata (as seen in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) and various social media modules), the actual detection occurs when the tool POSTs to register, login, or password-recovery endpoints and parses the response.

### How does holehe distinguish between an existing account and a non-existing one without valid credentials?

Holehe exploits error message differentiation inherent in web application design. When POSTing to a **login** endpoint with a fake password, a response containing "incorrect password" indicates the email exists, while "email not found" indicates it does not. For **register** endpoints, a response stating the email is "already registered" confirms existence. This pattern matching allows inference without valid authentication.

### What is the difference between the register and login detection methods in holehe?

The **register** method (`method = "register"`) POSTs to signup endpoints and looks for "account exists" errors, which works well for services that prevent duplicate registrations. The **login** method (`method = "login"`) POSTs to authentication endpoints with invalid credentials and looks for "wrong password" errors, which is necessary for platforms that do not expose registration status publicly. The choice depends on which endpoint provides clearer existence indicators for that specific service.

### Is password recovery checking implemented as a separate HTTP method in holehe?

Password recovery checking is not implemented as a distinct `method` type in the current codebase. However, modules may utilize password-recovery endpoints within the existing framework by treating them as either register or login checks. The same POST-based pattern applies: sending the email to a "forgot password" URL and parsing the response for text indicating the email is recognized by the system.