API Discovery

Glossary

## What is API discovery? API discovery is the process of identifying and cataloging all the APIs an organization has running, including ones that were never documented, formally approved, or tracked by a central team. It produces an API inventory: an ongoing record of endpoints, their methods, parameters, authentication requirements, and the services or data they expose. The term covers both the technical mechanisms used to find APIs — scanning code repositories, inspecting network traffic, parsing gateway configurations — and the resulting artifact those mechanisms produce. **Discovery is distinct from documentation.** An API can be documented in an OpenAPI spec and still be missing from an organization's actual inventory if that spec goes stale, or an API can run in production with no spec at all. The goal of discovery is to reconcile what security and platform teams believe exists with what is actually deployed, which is often a meaningfully larger and messier set. ## API discovery vs. API security testing: why you need both API security testing — dynamic scanning, fuzzing, penetration testing, authorization testing against frameworks like the OWASP API Security Top 10 — assumes a starting inventory of endpoints to target. Testing tools need a URL, a method, and a schema before they can send a single request. When discovery is incomplete, testing coverage is incomplete in exactly the same proportion: **an API missing from inventory is an API no scanner will ever touch**, no matter how mature the testing program is. This is the core argument for treating discovery and testing as sequential, dependent stages rather than interchangeable capabilities. Organizations that invest heavily in API security testing tools while neglecting discovery often report high confidence in APIs they know about and zero visibility into the ones they don't — which is precisely where attackers tend to look first, since undocumented endpoints frequently skip the review and hardening steps that known ones go through. ## How API discovery tools find APIs teams didn't know they had Discovery tools generally rely on one or more of three methods. **Traffic-based discovery** passively monitors network requests and responses, using pattern matching to identify request paths and parameters as they pass through a proxy or sensor — effective for catching what's actually being called, but blind to APIs with low or no traffic and unable to see anything before it's live. **Gateway-based discovery** reads configuration and routing rules from API gateways and service meshes, which is reliable for anything routed through a managed gateway but misses APIs that bypass it entirely, a common pattern in fast-moving microservice environments. **Code-based discovery** parses source repositories directly — route definitions, controller annotations, OpenAPI/Swagger files, GraphQL schemas — to identify endpoints as developers write them. This method is the only one of the three that can surface an API before it is deployed, which matters directly for [mitigating API risk during development](https://apiiro.com/blog/how-to-mitigate-api-risks-during-development/) rather than after the fact. Most mature programs combine all three, since each method's blind spot is roughly another method's strength. ## Why point-in-time API inventories go stale so quickly A manually maintained API inventory is accurate the day it's built and progressively less accurate after that. Development teams shipping through CI/CD pipelines add, modify, and retire endpoints continuously — a new microservice, a new route on an existing service, a parameter change that alters an API's risk profile — often multiple times per day across a large engineering organization. A quarterly or even monthly inventory refresh cycle cannot keep pace with that rate of change, which means the gap between "documented API surface" and "actual API attack surface" widens continuously between refresh cycles. This is the same dynamic that produces [shadow APIs](https://apiiro.com/glossary/shadow-apis): endpoints that exist and serve traffic without ever being formally tracked, often because they were spun up quickly for an internal tool, a partner integration, or a deprecated feature that was never fully decommissioned — a specific form of the broader [shadow IT](https://apiiro.com/glossary/shadow-it) problem. Continuous, automated discovery closes that gap by re-scanning as changes happen rather than on a fixed schedule. ## How Apiiro discovers APIs at the code level before they reach production [Apiiro's risk graph](https://apiiro.com/platform/data-fabric/risk-graph) correlates deep code analysis with identity, cloud, and pipeline context, and API discovery runs as part of that same continuous analysis rather than as a separate scan. By parsing code changes directly — route definitions, framework annotations, and schema files — Apiiro identifies new and modified APIs as they're introduced in a pull request, before they merge and reach production, which supports [shifting API security left](https://apiiro.com/blog/shift-left-api-security-protect-your-apis-before-releasing-to-the-cloud/) instead of relying solely on runtime detection. Because the same graph tracks material code changes, business context, and deployment context together, a newly discovered API is automatically assessed for authentication gaps, [sensitive data exposure](https://apiiro.com/glossary/sensitive-data-exposure), and ownership, rather than added to an inventory as an unscored line item.

What's the difference between API discovery and a shadow API?

API discovery is the process; a shadow API is one possible finding. Discovery is how organizations identify endpoints, and a shadow API is an endpoint discovery reveals that was never documented, approved, or tracked — often created outside formal development processes or left behind after a deprecation.

Can API discovery happen before an API is deployed, or only at runtime?

Both, depending on method. Traffic- and gateway-based discovery only see APIs after deployment, once they're generating requests. Code-based discovery parses source repositories and route definitions directly, so it can identify an API during development, before it ever reaches a production environment.

How often should an organization refresh its API inventory?

Continuously, not on a fixed schedule. Manual or periodic inventories go stale between refresh cycles as development teams ship new and modified endpoints daily. Automated discovery tied to code commits or deployment pipelines keeps the inventory current as changes happen.

Does API discovery cover internal, partner, and third-party APIs equally?

Coverage depends on method and vantage point. Code-based discovery is strongest for internal APIs an organization builds itself, while traffic- and gateway-based discovery can also surface partner and third-party integrations, provided that traffic passes through a monitored network path or gateway.