Understanding `frequent_rate_limit` vs `rateLimit` in Holehe Results

frequent_rate_limit is a static metadata flag set by module authors at development time to indicate a service typically rate-limits aggressively, while rateLimit is a dynamic runtime flag that reports whether the current request was actually blocked.

Holehe, the open-source email OSINT tool by megadose/holehe, checks email addresses across hundreds of services using asynchronous modules. Each module returns a standardized dictionary with flags describing the outcome. Two similarly named but functionally distinct fields—frequent_rate_limit and rateLimit—often confuse users trying to interpret results.

What frequent_rate_limit Represents

frequent_rate_limit is a static Boolean constant defined by the module author when implementing a new service check. This flag serves as metadata warning that the target API tends to throttle or block requests after minimal activity.

In holehe/modules/transport/blablacar.py, the flag appears at module definition:

async def blablacar(email, client, out):
    name = "blablacar"
    domain = "blablacar.com"
    method = "register"
    frequent_rate_limit = True  # Static metadata flag

This value never changes during execution. The author's decision to set frequent_rate_limit=True reflects their experience that BlaBlaCar's API aggressively limits requests.

What rateLimit Represents

rateLimit is a dynamic Boolean determined per-request based on the actual HTTP response. It indicates whether this specific query triggered a rate-limit response from the service.

From blablacar.py, rateLimit gets set conditionally based on API behavior (lines 33-35 and 47-49):

# When rate limit is detected from response

out.append({
    "name": name,
    "domain": domain,
    "method": method,
    "frequent_rate_limit": frequent_rate_limit,  # Always True for this module

    "rateLimit": True,  # Dynamic: True only when actually blocked

    "exists": False,
    "emailrecovery": None,
    "phoneNumber": None,
    "others": None,
})

How the Two Flags Interact During Execution

The relationship between these fields follows a clear pipeline:

1. Module initialization — frequent_rate_limit is hardcoded based on the service's known behavior pattern
2. Request execution — The async function probes the service and sets rateLimit according to actual HTTP response status
3. Output generation — Both values appear in the result dictionary, but holehe/core.py uses only rateLimit for visual formatting

The core printing logic in holehe/core.py (lines 22-26) demonstrates this selective usage:

def print_result(data, args, email, start_time, websites):
    for results in data:
        if results["rateLimit"] and not args.onlyused:
            # Yellow "[x]" marker appears only for dynamic rateLimit

            print("[x] " + results["domain"])

The frequent_rate_limit metadata persists in structured outputs (JSON, CSV) but does not trigger any visual indicator. This design separates predictive metadata from observed outcomes.

Practical Example: Reading Holehe Output

Consider running Holehe against a service with frequent_rate_limit=True:

Scenario	frequent_rate_limit	rateLimit	Visual Output
First successful request	True	False	Normal result
Request throttled by API	True	True	[x] indicator appears
Rare: service changes behavior	False	True	[x] indicator appears (previously unknown throttling)

The static flag helps users understand why a service might fail intermittently, while the dynamic flag reports what actually occurred.

Where These Flags Are Defined

Key source locations for understanding this implementation:

• holehe/modules/transport/blablacar.py — Exemplary module setting both flags
• holehe/modules/social_media/xing.py and wattpad.py — Additional modules using identical patterns
• holehe/core.py — Orchestrates execution and renders output based on rateLimit

Summary

• frequent_rate_limit — Static module metadata indicating a service typically rate-limits; set by developers at implementation time
• rateLimit — Dynamic per-request flag reflecting actual API response; triggers [x] visual indicator in terminal output
• Design purpose — Separate predictive service characteristics from observed request outcomes
• Visual relevance — Only rateLimit affects terminal formatting; frequent_rate_limit aids post-processing and debugging

Frequently Asked Questions

Does frequent_rate_limit affect how Holehe makes requests?

No. frequent_rate_limit is purely informational metadata. It does not trigger request throttling, delays, or retry logic within Holehe's execution engine. The flag exists to document expected service behavior for users interpreting results.

Why would rateLimit be False when frequent_rate_limit is True?

This occurs when a request succeeds without triggering the service's rate-limiting mechanism. The static flag warns that throttling is common for this service, but any individual request may complete normally. Conversely, rateLimit can be True even when frequent_rate_limit is False if a previously permissive service begins limiting requests.

How do I identify which services have frequent_rate_limit enabled?

Examine the module source files in holehe/modules/ or check the JSON/CSV output where frequent_rate_limit appears as a top-level field in each result dictionary. The value is consistent across all queries to the same service.

Can I filter Holehe results to show only rate-limited queries?

Yes. Use the --only-used flag with appropriate output parsing, or post-process JSON results filtering where rateLimit equals True. Note that holehe/core.py handles the [x] marker display automatically in terminal output when rateLimit is detected.

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