Difference Between register, login, password recovery, and other Methods in Holehe

The register, login, password-recovery, and other method classifications in Holehe indicate which type of endpoint or workflow each module uses to verify whether an email address exists on a target platform.

Holehe is an asynchronous OSINT tool that enumerates email addresses across hundreds of online services. Each service module defines a method variable that categorizes the verification strategy employed. Understanding the difference between these four method types helps interpret results accurately and develop custom enumeration modules.

How Holehe Categorizes Email Verification Methods

Every service module follows a consistent async pattern implemented in files like holehe/modules/social_media/twitter.py. The method variable specifies the verification approach:

register Method

Modules using the register method check if an email is already associated with an existing account by probing registration endpoints. These implementations typically query URLs that return "email taken" or "already registered" responses when an account exists.

In holehe/modules/social_media/twitter.py, the Twitter module uses the register method to query the endpoint /i/users/email_available.json:

async def twitter(email, client, out):
    name = "twitter"
    domain = "twitter.com"
    method = "register"
    # ...

login Method

The login method attempts verification using authentication-style endpoints to determine if the email can be used to sign in. This approach leverages login flows or session validation rather than registration availability checks.

The Snapchat module in holehe/modules/social_media/snapchat.py demonstrates this pattern:

async def snapchat(email, client, out):
    name = "snapchat"
    domain = "snapchat.com"
    method = "login"
    # ... logic using /accounts/login flow

password-recovery Method

Modules classified as password-recovery invoke password reset workflows to confirm email existence. When a service returns a "reset link sent" or similar success message, Holehe interprets this response as confirmation that the email is registered to an active account.

other Method

The other classification captures non-standard verification techniques that do not fit the previous three categories. This includes API endpoint probing that returns user IDs, page scraping for personalized welcome banners, or specialty checks for niche platforms and forums.

Practical Usage and Output Inspection

Viewing Method Types via CLI

While the standard CLI output displays only existence status using symbols ([+], [-], [x], [!]), the JSON output includes the method classification for each service checked:

# Basic check shows colored summary

holehe email@example.com

# JSON output includes the method field

holehe -j email@example.com | jq '.[] | {domain, method, exists}'

Accessing Methods Programmatically

When invoking modules directly in Python, the method type is explicitly returned in the output list along with the existence boolean:

import httpx
import asyncio
from holehe.modules.social_media.twitter import twitter

async def main():
    async with httpx.AsyncClient() as client:
        out = []
        await twitter("target@example.com", client, out)
        print(out)
        # [{'name': 'twitter', 'domain': 'twitter.com',

        #   'method': 'register', 'exists': True, ...}]

asyncio.run(main())

Key Implementation Files

The verification orchestration occurs in holehe/core.py, which loads modules and aggregates results. Individual method implementations are distributed throughout the modules directory:

• holehe/modules/social_media/twitter.py – Implements register type checking
• holehe/modules/social_media/snapchat.py – Implements login type checking
• holehe/modules/shopping/amazon.py – Uses register method for e-commerce platforms
• holehe/modules/learning/quora.py – Demonstrates other type for non-standard flows

Each module sets the method variable at the beginning of its async function, determining how the verification result should be categorized in final reports.

Summary

• The four method types classify which verification endpoint or workflow each Holehe module exploits
• register probes registration endpoints for "email taken" or availability responses
• login uses authentication flows to check if the email can sign in
• password-recovery exploits password reset workflows to confirm account existence
• other handles custom implementations for specialty services and non-standard APIs
• Method metadata appears in JSON CLI output (-j flag) and Python programmatic results but not in the standard colored terminal summary

Frequently Asked Questions

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

Inspect the source file in holehe/modules/ for the target service. The method variable is defined at the beginning of the async function (e.g., method = "register"). Alternatively, run holehe -j email@example.com and parse the JSON output to see the method field for each result.

Why does the standard Holehe CLI output hide the method classification?

The CLI displays only existence status symbols ([+], [-], [x], [!]) for brevity and readability. The method metadata is preserved in the JSON output structure (-j flag) intended for programmatic consumption and advanced analysis.

Which method type is most reliable for confirming email existence?

register checks are generally most direct because they explicitly query account availability endpoints. However, login and password-recovery methods may bypass rate limiting on some platforms. Each method has different reliability characteristics depending on the target service's security controls and error handling.

Can I contribute a module using a custom verification technique?

Yes. When developing modules for the holehe/modules/ directory, set the method variable to "register", "login", "password-recovery", or "other" based on which endpoint type your verification logic targets. The "other" classification is appropriate for techniques that do not fit the standard three categories, such as scraping user IDs from public APIs.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}