What is API Endpoint Discovery?

API endpoint discovery is the API equivalent of asset discovery: working out which API hosts and paths are actually reachable, rather than which ones the documentation lists. It matters because APIs are rarely inventoried as carefully as websites, and because an endpoint that nobody remembers is an endpoint nobody is patching, monitoring or reviewing for access control.

Where endpoints are found

• Subdomains — api., api-staging., gateway., mobile. and similar hosts surfaced by subdomain enumeration and CT logs
• Client-side code — JavaScript bundles and source maps contain the paths the front end calls, including ones behind feature flags
• Specification files — OpenAPI or Swagger documents, and their interactive UIs, left reachable in production
• Mobile applications — endpoint hosts and paths embedded in shipped binaries
• Introspection — for GraphQL services, a single query can return the whole schema; see GraphQL introspection
• Versioning patterns — a live /v3/ often implies a /v1/ and /v2/ that were never switched off

Why the forgotten ones are the risk

Deprecated versions are the recurring finding. A v1 endpoint kept alive for one legacy client typically predates the authorisation model, rate limiting and logging that the current version has, so it offers the same data with fewer controls. Staging and test API hosts are similar: real code, real-ish data, and hardening that was deferred because the host was “temporary”.

The externally checkable questions are which API hosts resolve and respond, whether specification documents are public, whether endpoints require authentication, and whether older versions still answer.

Related concepts

Undocumented and forgotten APIs are a form of shadow IT. See also reconnaissance, OSINT, DAST for testing what discovery finds, and attack surface reduction for retiring what should no longer answer.