# What Does the 'others' Field Represent in Holehe's Return Schema?

> Understand the 'others' field in Holehe's return schema. Discover how it captures extra info like profile IDs or secondary contacts when services provide it, otherwise it's null.

- Repository: [Palenath/holehe](https://github.com/megadose/holehe)
- Tags: api-reference
- Published: 2026-08-31

---

**The `others` field in Holehe's return schema holds any additional information that a module retrieves beyond the predefined data slots, typically `null` when no extra data exists but populated with supplemental details like profile IDs or secondary contacts when services return them.**

Holehe is an open-source OSINT (Open Source Intelligence) tool that checks whether an email address is registered on various websites. Understanding its standardized output format is essential for building integrations or interpreting results programmatically. The `others` field serves as a flexible catch-all within this schema, accommodating service-specific data that doesn't fit into the core fields.

## Understanding Holehe's Standard Return Format

Every Holehe module returns a consistent dictionary structure. According to the [`README.md`](https://github.com/megadose/holehe/blob/main/README.md) in the `megadose/holehe` repository, the output contains these core keys:

- `name` – the service name
- `domain` – the service domain
- `method` – the verification method used
- `rateLimit` – whether rate limiting was detected
- `exists` – whether the email is registered
- `emailrecovery` – any recovered email address
- `phoneNumber` – any recovered phone number
- `others` – **any extra information**

The `others` field is explicitly defined in the documentation as "Any extra info," providing modules with extensibility without breaking the standardized schema.

## How the 'others' Field Is Used Across Modules

### Typical Case: Null Value

Most modules leave `others` as `None` because the service provides no additional retrievable data. In [`holehe/modules/social_media/twitter.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/twitter.py), for example, the Twitter module constructs its output dictionary with `others` set to `None`:

```python
out.append({
    "name": "twitter",
    "domain": "twitter.com",
    "method": "register",
    # ... other fields ...

    "others": None
})

```

This pattern appears consistently across services where only basic registration status is verifiable.

### Populated Case: Supplemental Service Data

When a service returns extra information—such as secondary usernames, profile identifiers, additional recovery contacts, or metadata—modules populate `others` with a dictionary containing these values:

```python

# Example: A module with extra retrieved data

out.append({
    "name": "example",
    "domain": "example.com",
    "method": "register",
    "frequent_rate_limit": False,
    "rateLimit": False,
    "exists": True,
    "emailrecovery": "ex****e@example.com",
    "phoneNumber": "0*******78",
    "others": {
        "profile_id": "12345",
        "nickname": "john_doe",
        "account_created": "2019-03-15"
    }
})

```

## Implementation in Holehe's Core Architecture

The aggregation of module outputs—including the `others` field—is handled in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py). This central component ensures all modules conform to the expected schema while preserving any supplemental data they provide. The flexibility of `others` allows contributors to extend Holehe's capabilities without requiring schema migrations for every new data type discovered.

## Complete Working Example

Below is a runnable example demonstrating how `others` appears in actual Holehe output. This queries Twitter and prints the full result structure:

```python
import trio
import httpx
from holehe.modules.social_media.twitter import twitter

async def check_email():
    email = "test@example.com"
    results = []
    
    async with httpx.AsyncClient() as client:
        await twitter(email, client, results)
    
    # Inspect the output structure

    for result in results:
        print(f"Service: {result['name']}")
        print(f"Exists: {result['exists']}")
        print(f"Others: {result['others']}")  # Typically None for Twitter

        print("---")

trio.run(check_email)

```

For services that do populate `others`, you would access extended data like:

```python
result = results[0]
if result["others"]:
    profile_id = result["others"].get("profile_id")
    nickname = result["others"].get("nickname")

```

## Summary

- The **`others`** field in Holehe's return schema captures **any supplemental information** retrieved beyond the standard data points.
- It is typically **`None`** when services provide only basic registration status.
- It contains a **dictionary** when modules extract extra data like profile IDs, nicknames, or additional contacts.
- The field is defined in **[`README.md`](https://github.com/megadose/holehe/blob/main/README.md)** and processed through **[`core.py`](https://github.com/megadose/holehe/blob/main/core.py)** to maintain schema consistency across all modules.

## Frequently Asked Questions

### When is the 'others' field populated instead of left as null?

The `others` field is populated when a service's response contains extractable data beyond the standard fields—such as profile identifiers, secondary email addresses, account metadata, or linked usernames. If a module cannot retrieve or does not attempt to retrieve such information, it sets `others` to `None` to maintain output consistency.

### Can I rely on specific keys existing inside the 'others' dictionary?

No. The `others` field has no fixed internal schema. Its contents vary by module and depend entirely on what each service exposes. Always check if `others` is not `None` and use `.get()` methods when accessing potential keys to avoid `KeyError` exceptions.

### How does Holehe's core processing handle the 'others' field?

In [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py), the central execution logic aggregates results from all modules without transforming the `others` value. This preserves whatever dictionary structure the module provides, enabling forward compatibility as new data types are discovered and added by contributors.