How to Find Hidden API Endpoints

Hidden API endpoints power modern web and mobile apps, but they are not always listed in public documentation. Routes leak through JavaScript bundles, archived URLs, GitHub repositories, mobile APKs, and traffic you capture in a proxy. This guide walks through authorized ways to find those endpoints and validate them without treating every string in a minified file as a live API.

I tested the command-line examples on Ubuntu 25.04. Use only targets you own or are allowed to assess—see the virtual penetration testing lab for safe practice.

Tested on: Ubuntu 25.04 (Plucky Puffin); kernel 6.14.0-37-generic.

What is a hidden API endpoint?

A hidden API endpoint is an API route that exists but is not obvious from the main UI, marketing site, or published API docs. The server may still accept requests to it even when no button or link exposes it in the browser.

Common examples include:

• undocumented API paths (/api/internal/reports)
• old or deprecated routes still reachable in production
• admin or internal-only handlers (/admin/api/users)
• mobile-app API bases not shown on the website
• routes discovered only inside JavaScript bundles
• forgotten staging or beta hosts (staging-api.example.com)
• URLs resurfacing from archived crawls

Hidden API vs hidden endpoint vs hidden URL

Readers often search for find hidden api, hidden endpoints, and find hidden urls together. The methods below cover all three, with emphasis on API-style routes you can map and validate.

Where hidden APIs are usually found

Jump to the method that matches your source:

After discovery, use Method 10 before reporting or fuzzing further. For directory brute forcing on paths you already found, see URL fuzzer tools.

Method 1: Find hidden APIs using browser DevTools

The fastest way to see which APIs a web app actually calls is to watch live traffic while you use the site.

1. Open the target web app in your browser (authorized scope only).
2. Press F12 or Ctrl+Shift+I to open DevTools.
3. Open the Network tab.
4. Enable Preserve log if you will navigate across pages.
5. Filter by Fetch/XHR (or XHR in older browsers).
6. Click through the application: login, search, settings, checkout, admin areas you are allowed to test.
7. Look for paths containing /api/, /graphql, /v1/, /v2/, /internal/, /ajax/, or JSON responses.
8. Inspect method, headers, cookies, query string, and request/response body for each interesting call.
9. Copy as cURL only for authorized testing and store notes in your engagement report—not in public channels.

This is not a scraping tutorial. You are learning which endpoints the legitimate client already uses. Those routes often become your highest-confidence hidden API list.

Method 2: Extract API endpoints from JavaScript files

Modern single-page apps ship large JavaScript bundles. Even when routes are not linked in HTML, strings inside .js files often reveal API bases, relative paths, and environment names.

Download or open JS files from your target (authorized scope), then search for API-like patterns:

/api/
/v1/
/v2/
graphql
admin
internal
debug
staging
token
client_id
redirect_uri

On a small lab file I used for testing, manual grep surfaced:

$ grep -oE '(/api/|/v[0-9]/|graphql|admin|internal|debug)' /tmp/sample-app.js | sort -u
admin
/api/
debug
graphql
internal

What to collect from JS:

• full URLs (https://api.example.com/v2/...)
• relative paths (/api/v1/users)
• API base URLs and version prefixes
• GraphQL endpoint paths
• feature-flag or environment strings (staging, beta)
• route names and internal keywords

Many strings are stale, third-party, or unreachable. Treat JS output as leads and validate each path in Method 10.

Method 3: Use LinkFinder to extract endpoints from JavaScript

LinkFinder parses JavaScript and reports URLs and path-like strings using regex—useful when reading minified bundles by hand is impractical.

Install from source on Ubuntu:

git clone https://github.com/GerbenJavado/LinkFinder.git
cd LinkFinder
pip3 install -r requirements.txt

Scan one file and print results to the terminal:

python3 linkfinder.py -i /tmp/sample-app.js -o cli

Output on my test file:

https://api.example.com/v2
/internal/orders
/api/v1/users
/graphql
/admin/debug/status

Filter results to your target domain before testing. For a remote JS URL, replace the path with -i https://example.com/static/app.js. Domain-wide mode (-d example.com) can pull many files—use only when scope allows and rate limits are respected.

Method 4: Use JSFScan for JavaScript recon

JSFScan.sh chains several JS recon steps: gather live .js URLs (often via gau and subjs), probe them with httpx, extract endpoints, optionally flag interesting strings, and build wordlists.

Typical workflow:

git clone https://github.com/KathanP19/JSFScan.sh.git
cd JSFScan.sh
chmod +x install.sh && ./install.sh

Then import JS URLs and run endpoint extraction:

bash JSFScan.sh -f ./targets.txt
bash JSFScan.sh -e

The import step must run before -e. JS URL lists should look like https://static.example.com/assets/app.bundle.js. JSFScan depends on tools such as gau and httpx—install those first (see Method 5). Keep the main goal endpoint discovery; treat any secret matches as evidence to report through authorized channels.

Method 5: Find hidden API URLs from archives using gau/getallurls

Archive sources (Wayback Machine, Common Crawl, AlienVault OTX, and others) store historical URLs that may no longer appear in the current sitemap. Old API paths often survive in crawls long after teams deprecate them.

gau (getallurls) fetches known URLs for a hostname from those sources. Install with Go:

go install github.com/lc/gau/v2/cmd/gau@latest
export PATH="$PATH:$HOME/go/bin"
gau --version

On my host:

gau version: 2.2.4

Collect URLs for an authorized domain and save them:

gau example.com --blacklist png,jpg,gif,css,woff,svg -o urls.txt

Trimmed live output:

time="..." level=warning msg="error reading config: Config file .../.gau.toml not found, using default config"
https://example.com/payloads/
https://example.com/daily/feed.csv
https://api.swarm.example.com/

Suggested workflow:

collect URLs
→ remove static files
→ filter API-like paths
→ deduplicate
→ validate status/method safely
→ keep only in-scope endpoints

Filter API-like paths from a saved list:

grep -iE '/api/|/graphql|/v[0-9]/|/internal/|/ajax/' urls.txt | sort -u > api-candidates.txt

Many archive hits point at third-party or out-of-scope hosts (cdn.example.com, old marketing subdomains). Drop anything outside your rules of engagement before sending traffic.

Method 6: Search GitHub and public code for API routes

Public repositories and gists often contain route names, OpenAPI specs, and staging URLs—not just secrets. Shift GitHub recon toward API discovery rather than credential hunting.

Useful angles:

• domain mentions in code or docs
• API base URLs and path constants
• swagger.json, openapi.yaml, Postman collections
• mobile client source with hard-coded API hosts
• staging, beta, internal hostnames in configs
• old commits that removed routes but left examples in history

Safer search patterns to try in GitHub search (replace example.com):

"example.com" "/api/"
"example.com" "swagger"
"example.com" "openapi"
"example.com" "graphql"
"api.example.com"
"staging.example.com"

Watch for scope creep: third-party SDKs, forks, and personal repos may mention your target without belonging to it. If you find exposed secrets, report them through the authorized channel—do not authenticate with leaked credentials.

Method 7: Check API documentation, Swagger/OpenAPI, and GraphQL

Teams sometimes leave specification files or developer portals reachable without linking them from the main site.

Paths worth checking on authorized targets:

• /swagger.json, /swagger/v1/swagger.json
• /openapi.json, /openapi.yaml
• /api-docs, /docs, /redoc
• /graphql (and introspection only when explicitly allowed by scope)
• Postman collection URLs referenced in JS or docs
• public developer portals (developers.example.com)

Send safe GET requests first. GraphQL introspection can be disabled or rate-limited; respect program rules before running schema dumps.

Method 8: Find hidden APIs in Android APKs

Mobile apps often embed API base URLs and path fragments that never appear on the marketing website. Analyze only APKs you own or are authorized to test (your app, a bounty program, or a lab build).

Install ApkLeaks on Ubuntu:

pip3 install apkleaks

Scan an authorized APK:

apkleaks -f /path/to/app.apk -o report.txt

Sample-style output (patterns only—your APK will differ):

v2.6.3
Scanning APK file for URIs, endpoints & secrets

[LinkFinder]
- https://api.example.com/v1/session
- /internal/config
- /graphql
- /mobile/telemetry

Compare mobile routes with web routes from Methods 1–5. A /api/v2/ path reachable only from the app is a common shadow API finding. Do not paste raw secret values from APK scans into reports—redact and hand off through secure channels.

Method 9: Use crawling and proxy tools for authenticated APIs

Static JS and archives miss APIs that appear only after login or with specific roles. Proxy and crawler workflows capture dynamic traffic.

Typical approach with Burp Suite:

1. Configure the browser to use Burp Proxy.
2. Browse the application as an authorized test user.
3. Review the Site map and HTTP history for /api/, JSON bodies, and GraphQL calls.
4. Repeat with another role only when scope allows (for example user vs admin).
5. Export interesting paths for validation and inventory updates.

PortSwigger’s API testing guidance covers discovering endpoints, hidden parameters, and versioning issues in line with this method. Crawlers and Burp complement gau and LinkFinder—they do not replace them.

Method 10: Validate discovered hidden APIs safely

Finding a string in JavaScript or an archive is not proof the endpoint is live, in scope, or exploitable. Validate carefully:

• confirm the hostname belongs to the target and engagement scope
• prefer safe GET requests before POST, PUT, or DELETE
• note whether authentication is required
• record status code, response length, and content type
• avoid destructive methods on production
• do not brute-force user IDs, tokens, or passwords from this step
• store evidence with secrets redacted

Example status checks against a public HTTP test service (replace with your in-scope target):

$ curl -s -o /dev/null -w 'GET /status/401 -> %{http_code}\n' https://httpbin.org/status/401
GET /status/401 -> 401

$ curl -s -o /dev/null -w 'GET /status/403 -> %{http_code}\n' https://httpbin.org/status/403
GET /status/403 -> 403

$ curl -s -X POST -o /dev/null -w 'POST /get -> %{http_code}\n' https://httpbin.org/get
POST /get -> 405

What to do after finding hidden APIs

• map the endpoint (host, path, method, auth)
• identify likely function or data type
• check whether it appears in official API inventory or docs
• compare against program scope and rules of engagement
• test access control only within authorization
• report shadow or zombie APIs that bypass governance
• add confirmed routes to the API inventory for defenders
• attach evidence (request line, status, redacted snippet)—not live secrets

Defenders use the same sources to find undocumented attack surface before attackers do.

Common mistakes when finding hidden APIs

• treating every JS string as a live API
• ignoring third-party CDN or analytics URLs
• testing hosts outside written scope
• relying only on search-engine dorks without JS or archive review
• skipping archived URL collection
• forgetting mobile APK or proxy traffic
• not filtering static assets out of gau output
• sending destructive methods before safe validation
• ignoring 401, 403, and 405 as “not found”
• using leaked secrets instead of reporting them

Should you cover Open Web Analytics dorks here?

Some searches, such as Open Web Analytics dorks, are product-specific exposure checks rather than hidden API discovery. They fit better in a separate authorized OSINT or defensive exposure-check article. Do not mix exploit-style dork lists into API endpoint discovery—it distracts from mapping routes and validating access control.

References

• LinkFinder
• gau (getallurls)
• JSFScan.sh
• ApkLeaks
• PortSwigger — API testing
• SecLists
• On-site: Virtual penetration testing lab, Burp Suite proxy tutorial, URL fuzzer tools

Summary

Hidden APIs are usually discovered through browser DevTools, JavaScript analysis, archived URLs, GitHub and code search, mobile APKs, and proxy traffic. JavaScript files and archive sources such as gau often return the highest-value leads. LinkFinder, JSFScan, gau, Burp Suite, and APK tools each cover a different part of the workflow. Every discovered endpoint still needs safe validation and must stay inside authorized scope before you fuzz, report, or add it to an inventory.