# Understanding `frequent_rate_limit` vs `rateLimit` in Holehe Results

> Clarify frequent_rate_limit vs rateLimit in holehe results. Understand the difference between static flags and dynamic runtime blocking to optimize your API interactions.

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

---

**`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`](https://github.com/megadose/holehe/blob/main/holehe/modules/transport/blablacar.py), the flag appears at module definition:

```python
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`](https://github.com/megadose/holehe/blob/main/blablacar.py), `rateLimit` gets set conditionally based on API behavior (lines 33-35 and 47-49):

```python

# 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`](https://github.com/megadose/holehe/blob/main/holehe/core.py) uses only `rateLimit` for visual formatting

The core printing logic in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) (lines 22-26) demonstrates this selective usage:

```python
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`](https://github.com/megadose/holehe/blob/main/holehe/modules/transport/blablacar.py)** — Exemplary module setting both flags
- **[`holehe/modules/social_media/xing.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/xing.py)** and **[`wattpad.py`](https://github.com/megadose/holehe/blob/main/wattpad.py)** — Additional modules using identical patterns
- **[`holehe/core.py`](https://github.com/megadose/holehe/blob/main/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`](https://github.com/megadose/holehe/blob/main/holehe/core.py) handles the `[x]` marker display automatically in terminal output when `rateLimit` is detected.