Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
An API specification can be correct and still omit an old endpoint that remains deployed. A useful API inventory compares declared routes with implementation and environment evidence, then makes every disagreement somebody’s review task.
Consider a fictional delivery service with a current customer API, an older partner version and a support-only endpoint. The current specification describes the customer API accurately. The risk is assuming that this document describes every exposed interface, including the partner deployment nobody has updated and the support route added during an incident.
API inventory needs several kinds of evidence
Start with specifications, source route definitions and authorised deployment records. Each answers a different question: what the interface promises, what the code can implement, and what an environment is configured to serve. Gateway configuration or approved observations can provide additional evidence, but they also have scope and freshness limits.
Do not silently combine those inputs into a list that loses their origin. Preserve whether a route is declared, implemented, configured or observed, and when that evidence was collected. A source route behind a disabled feature is not equivalent to a route recently served by a production gateway.
OWASP’s improper inventory management guidance highlights the need to understand API hosts, versions, environments and access expectations. An endpoint list without that surrounding context cannot reliably support a retirement decision or a testing plan. Use the inventory to expose uncertainty rather than to make it disappear.
Choose an identity that survives routine changes
For the delivery service, record the application, environment, API version, HTTP method and route template. A route named /deliveries/{id} in a test environment is not the same exposure as its production counterpart. A read operation and a state-changing operation also need separate treatment even when they share a path.
Normalise examples carefully. Replace specific object identifiers with a reviewed route template, but do not merge unrelated paths simply because they look similar. Preserve enough raw evidence in the appropriate restricted location for an engineer to check a disputed match.
Add the owner, expected audience and authentication requirements. “Internal” is not an access control by itself; record the boundary that is expected to enforce that designation. If the team cannot identify that boundary, flag the gap for review instead of using the label as proof that the route is protected.
Compare API inventory states before declaring drift
Create a small comparison table and agree what each state means. The aim is to route a discrepancy to a useful investigation, not to label every difference as a vulnerability. Some differences are legitimate, such as a future route committed to source but not yet released.
| Evidence state | Useful review question | Likely next owner |
|---|---|---|
| Declared and implemented | Is this version deployed where expected? | Application team |
| Implemented but undeclared | Is documentation missing or is the route unintended? | API owner |
| Deployed but marked retired | Which consumers and release records still depend on it? | Service owner |
| Declared but not observed | Is it unavailable, untested or outside observation scope? | Platform and application teams |
| Observed with no known owner | Which application and deployment account for it? | Inventory steward |
Apply the table to the support endpoint. Its presence in source and gateway configuration creates a review task. That evidence does not prove unauthorised access; it establishes that the endpoint must be explained and its expected access boundary tested.
Also record why two observations were considered a match. A gateway rewrite can change the visible path, and a version prefix can be introduced outside the application. Keeping that mapping explicit prevents the inventory from showing false duplicates or silently hiding an exposed alias.
Validate exposure inside the agreed scope
Use read-only configuration review and approved test requests to resolve uncertainty. Establish the hosts, accounts, rate limits and methods permitted for the exercise. State-changing routes require their own preparation; they should not be called against real customer records merely to prove that an inventory entry exists.
For the partner version, begin with its deployment and gateway records. Identify the responsible team and any current consumer agreement. Then use a controlled environment or approved diagnostic procedure to verify the expected behaviour. If verification is not possible, retain an explicit unknown state and assign a follow-up.
Testing authenticated routes also requires evidence that the session worked. The authenticated DAST guide shows how to separate login success, session continuity and reached routes. An unauthenticated crawl cannot settle whether a support-only endpoint is correctly implemented behind its access boundary.
Retire an endpoint through a recorded change
Retirement is a workflow, not a label in the inventory. Review consumers, decide the supported replacement, agree the change owner and update the relevant deployment configuration. Keep the evidence that the old route was removed or restricted under the intended policy.
In the delivery example, the older partner API may need a coordinated migration. Removing it without checking consumers could cause an outage; leaving it indefinitely without ownership creates a different operational risk. The inventory should make that decision visible, with its dependencies and review conditions.
After the change, collect fresh evidence and compare it with the previous record. Do not delete the historical route merely to make the current list look smaller. History helps explain past findings and distinguishes a deliberate retirement from a temporary observation gap.
Make inventory maintenance part of delivery
Assign responsibility for changes at the point where they enter the system. Application teams can review route and specification changes, while platform teams can review gateway and deployment changes. Neither group alone sees every path an API can take into an environment.
Include an inventory check in release review and a periodic reconciliation for existing services. Use explicit stale or unknown states when an input stops arriving. A record that still shows yesterday’s route may be useful history, but it should not silently claim to describe the current environment.
Measure whether the inventory supports real work: can a responder identify an exposed version’s owner, and can a developer locate the source and deployment behind a route? Those questions are more useful than celebrating a growing endpoint count without knowing what the entries mean.
Key takeaways
- Compare specifications, implementation and deployment evidence while preserving their source and age.
- Identify routes by environment, version, method and template rather than path text alone.
- Treat inventory disagreements as review tasks with an owner and an explicit uncertainty state.
- Retain retirement evidence and history instead of deleting inconvenient entries from the list.
How SecurityVault approaches this
SecurityVault’s API security workflow brings API inventory from specifications and source routes into application context, with analysis and drift tracking. Its purpose is to help teams investigate which interface a finding concerns and who owns the related application. An inventory entry should support that investigation rather than substitute for evidence of actual exposure or correct authorisation.
Connected source, artefact and workload context can help a team move from an API question to the relevant delivery records. Missing relationships remain questions to resolve. Organisations should confirm which inputs and integrations are available for their environment instead of assuming that every gateway or deployed route is automatically observed.
For an evaluation, choose one current API, one older version and one intentionally undocumented test route. Ask how the differences appear, who receives the review task and what evidence closes it. To discuss that scoped exercise with your application and platform teams, request a technical demonstration.