## 1. Project Overview & Quickstart (projectdiscovery/subfinder)

<h1 align="center">
  
  
</h1>

<h4 align="center">Fast passive subdomain enumeration tool.</h4>






---


`subfinder` is a subdomain discovery tool that returns valid subdomains for websites, using passive online sources. It has a simple, modular architecture and is optimized for speed. `subfinder` is built for
doing one thing only - passive subdomain enumeration, and it does that very well.

We have made it to comply with all the used passive source licenses and usage restrictions. The passive model guarantees speed and stealthiness that can be leveraged by both penetration testers and bug bounty
hunters alike.

# Features

<h1 align="left">
  </a>
  
</h1>

- Fast and powerful resolution and wildcard elimination modules
- **Curated** passive sources to maximize results
- Multiple output formats supported (JSON, file, stdout)
- Optimized for speed and **lightweight** on resources
- **STDIN/OUT** support enables easy integration into workflows

# Usage

```sh
subfinder -h
```

This will display help for the tool. Here are all the switches it supports.

```
/* Detailed source-code truncated for AI context efficiency. */
```

## Environment Variables

Subfinder supports environment variables to specify custom paths for configuration files:

- `SUBFINDER_CONFIG` - Path to config.yaml file (overrides default `$CONFIG/subfinder/config.yaml`)
- `SUBFINDER_PROVIDER_CONFIG` - Path to provider-config.yaml file (overrides default `$CONFIG/subfinder/provider-config.yaml`)

# Installation

`subfinder` requires **go1.24** to install successfully. Run the following command to install the latest version:

```sh
go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest
```

Learn about more ways to install subfinder here: https://docs.projectdiscovery.io/tools/subfinder/install.

## Post Installation Instructions

`subfinder` can be used right after the installation, however many sources required API keys to work. Learn more here: https://docs.projectdiscovery.io/tools/subfinder/install#post-install-configuration.

## Running Subfinder

Learn about how to run Subfinder here: https://docs.projectdiscovery.io/tools/subfinder/running.

## Subfinder Go library

Subfinder can also be used as library and a minimal examples of using subfinder SDK is available [here](examples/main.go)





### Resources

- [Recon with Me !!!](https://dhiyaneshgeek.github.io/bug/bounty/2020/02/06/recon-with-me/)

# License

`subfinder` is made with 🖤 by the [projectdiscovery](https://projectdiscovery.io) team. Community contributions have made the project what it is. See
the **[THANKS.md](https://github.com/projectdiscovery/subfinder/blob/main/THANKS.md)** file for more details.

Read the usage disclaimer at [DISCLAIMER.md](https://github.com/projectdiscovery/subfinder/blob/main/DISCLAIMER.md) and [contact us](mailto:contact@projectdiscovery.io) for any API removal.

## 2. Official Technical Reference & Guides (projectdiscovery/docs)

## File: README.md

# ProjectDiscovery Documentation

<h4 align="center">
    This is the source code for the ProjectDiscovery documentation located at https://docs.projectdiscovery.io
</h4>






---

## Development

1. Checkout this repository
1. Install mintlify with `npm i mintlify@latest`
1. Run `mintlify dev`

## Deploying 

To build the final product, we have a couple of additional steps:

1. Build the JS Protocol Docs

- `npm install jsdoc-to-markdown`
- `./bin/jsdocs.sh`

2. Build the PDCP API reference documentation

- Either download the latest `openapi.yaml` manually or run `./bin/download-api.sh`
- Run `./bin/generate-api.sh` to generate any new API files
- **OR** run `./bin/generate-filtered-api.sh` to generate API docs without internal/admin endpoints

3. Deployment

After those, Mintlify handles the deployment automatically.

---

## File: bin/README-auto-grouped-api.md

# Auto-Grouped API Documentation Generator

This script **automatically generates and maintains** API documentation with logical grouping based on OpenAPI tags. It combines the best of both worlds: auto-generation (no missing endpoints) and logical organization.

## Usage

```bash
# Use default source file (Downloads directory)
./bin/generate-auto-grouped-api.sh

# Use custom source file  
./bin/generate-auto-grouped-api.sh /path/to/your/openapi.yaml
```

## What it does

### 🤖 **Auto-Generation**
- Reads OpenAPI specification
- Filters out admin and internal APIs
- Generates MDX files for all public endpoints  
- **Never misses endpoints** - everything is included automatically

### 📁 **Logical Grouping** 
The script organizes endpoints into logical groups based on OpenAPI tags:

- **Assets** → `assets` + `enumerations` tags
- **Templates** → `templates` + `template/v2` tags  
- **Scans** → `scans` tag
- **Results** → `results` + `retests` tags
- **Configurations** → `configurations` tag
- **Users** → `users` + `user` tags
- **Logs** → `elog` + `scan_log` tags
- **Export** → `export` tag
- **Automations** → `automations` tag
- **Integration** → `oauth` tag  
- **Utilities** → `chaos`, `vulns`, `leaks`, `billing`, `usage` tags

### 🔄 **Auto-Updates Navigation**
- Automatically updates `mint.json` with new structure
- Maintains logical grouping
- Sorts endpoints alphabetically within groups
- Handles new endpoints automatically

## Benefits

✅ **No Manual Maintenance** - Add new endpoints to OpenAPI spec and they appear automatically  
✅ **Never Miss Endpoints** - All public endpoints are included  
✅ **Logical Organization** - Grouped by functionality, not alphabetically  
✅ **Consistent Naming** - Uses OpenAPI summaries and operation IDs  
✅ **Future-Proof** - Works with any OpenAPI specification changes

## Output Structure

After running, your `mint.json` will have clean navigation like:

```json
{
  "group": "API Reference",
  "pages": [
    "api-reference/introduction",
    {
      "group": "Assets", 
      "pages": [
        "api-reference/assets/get-asset-list",
        "api-reference/assets/upload-asset",
        "api-reference/enumerations/create-enumeration",
        "..."
      ]
    },
    {
      "group": "Templates",
      "pages": [
        "api-reference/templates/create-template",
        "api-reference/templates/get-template-list",
        "..."
      ]
    }
  ]
}
```

## Comparison with Manual Approach

| Feature | Manual (`generate-filtered-api.sh`) | Auto-Grouped (`generate-auto-grouped-api.sh`) |
|---------|--------------------------------------|-----------------------------------------------|
| **Missing Endpoints** | ❌ Requires manual addition to `mint.json` | ✅ Never - all endpoints auto-included |
| **Logical Grouping** | ✅ Full manual control | ✅ Smart tag-based grouping |
| **Maintenance** | ❌ High - update `mint.json` for new endpoints | ✅ Zero - fully automated |
| **Consistency** | ❌ Depends on manual updates | ✅ Always consistent |
| **New API Versions** | ❌ Manual review and updates needed | ✅ Automatically handles changes |

## When to Use

**Use Auto-Grouped when:**
- You want zero maintenance overhead
- You frequently add/remove API endpoints  
- You have a team that might forget to update navigation
- You want consistent organization based on API design

**Use Manual when:**
- You need very specific custom grouping that doesn't match tags
- You want to exclude certain public endpoints from docs
- You have complex navigation requirements

## Next Steps

After running this script:

1. **Preview:** `mintlify dev`
2. **Deploy:** Your CI/CD can run this script automatically when OpenAPI changes
3. **Customize:** Modify the `logicalGroups` mapping in the script if needed

---

## File: bin/README-filtered-api.md

# Filtered API Documentation Generator

This script generates API documentation from an OpenAPI specification while excluding internal and admin endpoints.

## Usage

```bash
# Use default source file (Downloads directory)
./bin/generate-filtered-api.sh

# Use custom source file
./bin/generate-filtered-api.sh /path/to/your/openapi.yaml
```

**Note:** The script will create a filtered `openapi.yaml` file in the current directory for Mintlify to use.

## What gets filtered out

The script automatically excludes:

1. **Admin APIs**: All paths starting with `/v1/admin/`
   - Examples: `/v1/admin/user/search`, `/v1/admin/team/change_owner`

2. **Internal APIs**: Endpoints tagged with `internal`
   - Any endpoint with `"internal"` in its tags array

## Output

- Creates filtered API documentation in the `api-reference/` directory
- Removes existing `internal/` and `admin/` folders before regenerating
- Uses Mintlify scraping to generate MDX files for each endpoint
- Provides detailed console output showing what was filtered

## Requirements

- Node.js and npm/npx
- Internet connection (to download @mintlify/scraping package)
- Valid OpenAPI 3.x specification file

## Integration with existing workflow

You can replace the existing `./bin/generate-api.sh` call in your build process with:

```bash
# Old way (includes internal/admin APIs)
./bin/generate-api.sh

# New way (excludes internal/admin APIs)  
./bin/generate-filtered-api.sh
```

## Troubleshooting

If you encounter errors:

1. **"OpenAPI source file not found"**: Ensure the file path is correct
2. **"Node.js is required"**: Install Node.js from https://nodejs.org
3. **Network errors**: Check internet connection for npm package downloads
4. **Permission errors**: Ensure the script is executable (`chmod +x bin/generate-filtered-api.sh`)