# Why Do Some Holehe Modules Use Login While Others Use Register?

> Discover why Holehe modules use login or register methods. Learn how the metadata dictates service integration for efficient email verification.

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

---

**Holehe modules use "login" for services with public credential-validation endpoints and "register" for services that only expose email existence checks through their account creation flows, as dictated by the `method` metadata field in each module.**

Holehe is an open-source OSINT tool that verifies whether an email address is registered across hundreds of third-party services. In the `megadose/holehe` repository, each service is implemented as a separate module that declares a `method` value—either `"login"` or `"register"`—which tells the core orchestrator which HTTP flow to execute based on the target service's available public APIs.

## The Method Metadata Field Defines the Strategy

Every module in Holehe begins with a standardized metadata block that configures how the email verification should proceed. This block includes the service name, domain, rate limiting flags, and the critical `method` field that determines the verification strategy.

In [`holehe/modules/social_media/snapchat.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/snapchat.py), the metadata specifies the login approach:

```python
name = "snapchat"
domain = "snapchat.com"
method = "login"
frequent_rate_limit = False

```

Conversely, [`holehe/modules/transport/blablacar.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/transport/blablacar.py) uses the register approach:

```python
name = "blablacar"
domain = "blablacar.com"
method = "register"
frequent_rate_limit = False

```

The `method` value is not arbitrary—it reflects the specific public endpoint architecture each service exposes for email validation.

## Login Method vs Register Method

Holehe supports two distinct verification patterns based on how services expose email existence data.

**Login Method**

Modules with `method = "login"` post the target email to the service's login endpoint or a dedicated credential-validation API. These endpoints typically return explicit flags—such as `exists`, `hasAccount`, or similar JSON fields—that directly reveal registration status.

This approach works for services with public login APIs that validate credentials before authentication, including:
- **Snapchat** ([`holehe/modules/social_media/snapchat.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/snapchat.py))
- **eBay** ([`holehe/modules/shopping/ebay.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/shopping/ebay.py))
- **Amazon** ([`holehe/modules/shopping/amazon.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/shopping/amazon.py))

**Register Method**

Modules with `method = "register"` simulate the account creation flow. They first fetch a temporary token or session ID by visiting the registration page, then submit the email to an availability-check endpoint that returns whether the address is already taken.

This approach is necessary when services only expose email validation through their registration pipeline, including:
- **Blablacar** ([`holehe/modules/transport/blablacar.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/transport/blablacar.py))
- **Domino's FR** ([`holehe/modules/shopping/dominosfr.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/shopping/dominosfr.py))
- **Bitmoji** ([`holehe/modules/social_media/bitmoji.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/bitmoji.py))

## How holehe/core.py Orchestrates Both Approaches

The central driver in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) reads the `method` field from each module's metadata and constructs the appropriate HTTP request pipeline automatically.

- When `method == "login"`, the module constructs a POST request to the service's login endpoint with the target email.
- When `method == "register"`, the module first executes a GET request to obtain registration tokens, then submits the email to the validation endpoint.

This architecture allows Holehe to uniformly manage approximately 300 different modules while respecting each service's unique verification flow and endpoint requirements.

## Practical Implementation Examples

The following examples demonstrate how both methods function programmatically using the Holehe core client.

**Checking an email with a login-based module (Snapchat):**

```python
import asyncio
from holehe.modules.social_media.snapchat import snapchat
from holehe.core import client, out

async def check_snapchat(email: str):
    await snapchat(email, client, out)  # method is "login"

    return out[-1]  # returns result dict with 'exists' key

```

**Checking an email with a register-based module (Blablacar):**

```python
import asyncio
from holehe.modules.transport.blablacar import blablacar
from holehe.core import client, out

async def check_blablacar(email: str):
    await blablacar(email, client, out)  # method is "register"

    return out[-1]  # returns result dict with 'exists' key

```

Both functions return a standardized dictionary containing `name`, `domain`, `method`, `exists`, and other metadata fields that the core aggregates into the final report.

## Summary

- Holehe modules declare a `method` metadata field that is either `"login"` or `"register"` based on the target service's API architecture.
- **Login modules** query credential-validation endpoints directly, while **register modules** simulate account creation flows to check email availability.
- The central orchestrator in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) parses this metadata to build the correct HTTP pipeline for each service.
- This design allows the tool to support diverse verification strategies across approximately 300 services using a uniform interface.

## Frequently Asked Questions

### Can I change a module's method from register to login?

No, the `method` value is hardcoded in each module to match the service's actual API capabilities. Changing this value without modifying the underlying HTTP logic would cause the module to fail, as services expose email existence data through specific endpoints that cannot be arbitrarily swapped.

### Why don't all services use the login method for verification?

Many services do not expose public login endpoints that reveal email existence before password entry, or they implement anti-enumeration protections on their login forms. The register method is required when the registration pipeline is the only public interface that returns definitive email availability data.

### Which method is more reliable for detecting registered accounts?

Both methods are equally reliable when implemented correctly, though login-based checks often require fewer HTTP requests and are less complex. Register-based modules may fail if services change their token acquisition flows or implement additional bot detection on registration pages.

### How can I determine which method a specific Holehe module uses?

Check the metadata block at the top of the module file in `holehe/modules/`. The `method` variable is explicitly declared alongside the `name` and `domain` fields, allowing you to verify the verification strategy without reading the full implementation logic.