Ask an engineering team how many APIs they run and you get a confident number. Ask a discovery tool and you get a larger one. The difference is the part that matters.
The short answer
API discovery is the process of finding every API an organisation actually exposes, rather than every API it believes it exposes. It builds an inventory from observed traffic, infrastructure and code instead of from documentation, because documentation reflects intention at the time it was written and an API estate changes every sprint.
It is the first step of API security for an unglamorous reason: no control can be applied to an endpoint nobody knows exists.
On this page
The three kinds you did not know about
Unknown endpoints are not one problem. They arrive three different ways, and each needs a different response.
| How it happens | A concrete example | What to do about it |
|---|---|---|
| Never written down Shadow API | An engineer adds an internal endpoint to unblock a launch. It goes to production and never reaches the docs, the gateway or the spec file | Find it through traffic, then bring it under the same protection as everything else |
| Never switched off Zombie API | You ship v2 and announce v1 as deprecated, but one partner integration still calls v1, so nobody turns it off | Confirm from traffic whether anything still calls it, migrate the caller, then retire it properly |
| Nobody left who knows Orphaned API | The engineer who built it has gone. There is no ticket and no owner, but something clearly calls it, so it stays | Assign an owner first. An endpoint with no owner produces findings nobody actions |
How API discovery works
No single method finds everything. The useful tools combine several and reconcile the results.
| Method | What it finds | What it misses |
|---|---|---|
| Traffic analysis | Anything actually being called, including undocumented endpoints and real parameters | Endpoints nobody has called yet during the observation window |
| Specification import | Everything the team wrote down | Everything they did not, which is the whole problem |
| Gateway configuration | Endpoints registered with the API gateway | Anything deployed outside it |
| Code and repository scanning | Route definitions, including endpoints not yet deployed | Runtime behaviour, and anything in a repo nobody connected |
| Cloud inventory | Load balancers, functions and services in connected accounts | Assets in accounts you did not know about |
| External probing | Internet-reachable endpoints with no credentials, the attacker’s view | Internal and service to service APIs |
A specification is a claim, not evidence
An OpenAPI file describes what the API was meant to do on the day it was last edited. Discovery based on observed traffic describes what it does now, including the parameter a developer added under deadline and the field that returns more than the client asked for. When the two disagree, the traffic is right. This is why specification import alone is the weakest form of API discovery and the one most often mistaken for the complete answer.
What a useful inventory records
| Field | Why it earns its place |
|---|---|
| Endpoint and method | The minimum unit of policy. GET and DELETE on one path are not the same risk |
| Parameters observed | What validation should actually allow, rather than what the spec claims |
| Authentication in use | Reveals the unauthenticated endpoint nobody intended to leave open |
| Sensitive data in responses | Flags endpoints returning personal or payment data, which changes their PCI DSS and DPDP scope |
| Internal or external | Decides whether it belongs behind private access or in front of a protection layer |
| Last seen | Separates an active endpoint from a zombie, which is the only way to retire one safely |
| Owning team | Determines who fixes it. An inventory with no owners produces findings nobody actions |
API discovery, EASM and the gateway
| API discovery | EASM | API gateway | |
|---|---|---|---|
| Unit it finds | Endpoints, methods and parameters | Hosts, domains, certificates and services | Nothing. It lists what was registered |
| Depth | Inside the application | The perimeter | Its own configuration |
| Sees internal APIs | Yes, through traffic | No | Only those routed through it |
| Best question for it | What does this endpoint accept and return? | What do we expose to the internet? | How should this request be routed? |
EASM finds the host. API discovery finds what that host will answer. The two are sequential rather than alternative, and a gap in either produces the same outcome, which is a control applied to something other than the thing being attacked.
How Osto handles API discovery
Discovery is built into the web and API protection layer rather than sold as a separate scanning exercise. Applications and APIs are identified automatically from live traffic, and protection is applied once they are found, so the output is a control rather than a spreadsheet row.
The engine learns URLs, parameters and HTTP methods per application and generates a positive security policy from that observed behaviour. This is the practical difference from specification-led tooling: validation reflects what the API accepts today, and policy recommendations continue as the application changes rather than going stale between releases. Discovered endpoints feed into vulnerability management and correlate in the same SIEM as identity and endpoint activity, which is what turns an inventory into something a lean team can act on. It also produces the asset record that ISO 27001 and the Identify function of NIST CSF both ask for.
Platform walkthrough
An inventory that protects itself
APIs found from live traffic, then brought under a positive security policy learned from real parameters and methods. Not a spreadsheet. One owner, one dashboard.
Book a demoDiscovery to protection in one step · No spec required · One platform, everything
Frequently asked questions
What is API discovery?
The process of building an inventory of every API an organisation actually exposes, using observed traffic, infrastructure and code rather than documentation. It exists because documentation describes intent while traffic describes reality.
What are shadow, zombie and orphaned APIs?
Shadow APIs were shipped and never documented. Zombie APIs are deprecated versions still answering requests. Orphaned APIs have no remaining owner who knows why they exist. Zombies tend to be the most dangerous because they hold real data and stopped receiving fixes.
Is an OpenAPI specification enough?
No. A specification records what the API was meant to do when it was last edited. It will not contain the endpoint added under deadline or the parameter that was never written up. When the spec and observed traffic disagree, the traffic is correct.
How is API discovery different from EASM?
EASM finds internet-facing hosts, domains and services from outside. API discovery works at the application layer and finds endpoints, methods and parameters, including internal ones. EASM finds the host, discovery finds what it will answer.
How often should discovery run?
Continuously. An API estate changes every release, so a point-in-time inventory is out of date within a sprint. Continuous discovery is also what makes retiring a zombie endpoint safe, because you can see whether anything still calls it.