# What Does the Others Field in Holehe Results Contain?

> Understand the optional others field in Holehe results. Discover how it stores supplemental data like full names and error messages when standard schemas dont fit.

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

---

**The `others` field in Holehe results is an optional dictionary that stores supplemental information—such as full names, account creation dates, and error messages—when service modules extract data that does not fit the standard result schema.**

The `others` field serves as a flexible container within the megadose/holehe repository's result structure. When a target service returns metadata beyond basic account existence checks, individual modules populate this field to preserve valuable context for OSINT investigations.

## Structure of the Others Field

Each Holehe module returns a standardized dictionary containing primary keys: `exists`, `emailrecovery`, `phoneNumber`, `rateLimit`, and `error`. The **`others`** key operates as an optional extension mechanism.

- When additional data is available, `others` contains a **nested dictionary** with service-specific keys.
- When no supplemental information exists, `others` is explicitly set to **`None`**.

This design allows the core framework to process results uniformly while accommodating unique data points from disparate platforms.

## Common Data Types in the Others Field

Modules leverage `others` to capture non-standard metadata. The following keys frequently appear within this nested structure:

### FullName

Social media modules often extract the display name associated with an email address. When available, this value appears under the **`FullName`** key inside `others`.

### Account Creation Timestamps

Historical metadata such as **`Date, time of the creation`** indicates when the target account was registered. This timestamp provides temporal context for digital footprint analysis.

### Error Messages

When a request fails but the module captures a specific error response from the service, it stores this diagnostic information under **`errorMessage`**. This facilitates debugging and helps distinguish between non-existent accounts and technical failures.

## Implementation in holehe/core.py

The result-printing logic in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) explicitly handles the `others` field to conditionally display supplemental data.

According to the source code, the **`print_result`** function inspects `others` before rendering output:

- **Lines 41–45**: The printer checks for `FullName` and account creation dates within the `others` dictionary before adding them to the terminal output.
- **Lines 27–31**: During error handling, the code extracts `others["errorMessage"]` to provide detailed failure context to the user.

This implementation demonstrates that consumers must verify `others` is not `None` before attempting key access.

## How to Process the Others Field

When building tools atop Holehe, always implement null-checks before accessing nested keys. The following pattern safely extracts optional metadata:

```python

# Processing Holehe results with defensive coding

for result in results:
    if result["exists"]:
        print(f"[+] {result['domain']} – account found")
    
    # Safely check for supplemental data

    if result["others"]:
        full_name = result["others"].get("FullName")
        if full_name:
            print(f"    Full name: {full_name}")
        
        created = result["others"].get("Date, time of the creation")
        if created:
            print(f"    Created on: {created}")
        
        err_msg = result["others"].get("errorMessage")
        if err_msg:
            print(f"    Error: {err_msg}")

```

Service-specific implementations, such as [`holehe/modules/social_media/odnoklassniki.py`](https://github.com/megadose/holehe/blob/main/holehe/modules/social_media/odnoklassniki.py), demonstrate how modules populate these fields during platform-specific parsing routines.

## Summary

- The **`others`** field is an optional dictionary within Holehe result objects that captures supplemental data not covered by standard fields.
- It returns **`None`** when no extra information is available, requiring null checks in consumer code.
- Common contents include **`FullName`**, account creation timestamps, and **`errorMessage`** values.
- The processing logic in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) (lines 27–31 and 41–45) demonstrates the field's integration into the output pipeline.

## Frequently Asked Questions

### Is the others field always present in Holehe results?

Yes, the key always exists in the result dictionary, but its value is set to **`None`** when a module has no supplemental data to report. You must check for truthiness before accessing nested keys.

### What types of data can appear in the others field?

The field typically contains **string values** mapped to descriptive keys such as `FullName`, `Date, time of the creation`, or `errorMessage`. Because the structure is extensible, individual service modules may include additional platform-specific metadata.

### How do I check if the others field contains data?

Always use an explicit truthiness check: `if result["others"]:`. Attempting to access keys like `result["others"]["FullName"]` without first verifying the dictionary exists will raise a `TypeError` when the field is `None`.

### Which Holehe modules populate the others field?

Social media modules such as **[`odnoklassniki.py`](https://github.com/megadose/holehe/blob/main/odnoklassniki.py)** frequently populate the field with profile metadata. Any module that extracts data beyond the standard `exists` boolean may leverage this container to preserve additional OSINT indicators.