Runtime API discovery best practices: How to turn API traffic into security action

Runtime API discovery identifies APIs by observing activity and infrastructure in deployed environments. It uses sources such as API traffic, logs, runtime telemetry, Kubernetes resources, and dynamic scan activity to validate inventories, detect unknown or deprecated APIs, and identify endpoints that need security testing.

Runtime API discovery best practices at a glance

An effective runtime API discovery program should:

1. Establish an approved API inventory baseline.
2. Collect and protect signals from multiple runtime layers.
3. Normalize raw requests into stable API operations.
4. Reconcile runtime observations with static records.
5. Classify unknown and mismatched APIs.
6. Assign ownership and business context.
7. Validate exposure, authentication, and data sensitivity.
8. Prioritize APIs according to risk.
9. Move relevant APIs into dynamic security testing.
10. Verify remediation and decommissioning.
11. Monitor continuously for inventory drift.

These practices form an iterative operating model rather than a one-way pipeline. New information about ownership, exposure, dependencies, or testing results can change an API’s classification and priority. Here’s how the process might work:

Before applying the model, however, teams need to establish three things: why runtime evidence is necessary, how it complements the approved inventory, and which runtime signals are relevant to their architecture. The following sections set out that foundation before the step-by-step implementation guidance.

Why runtime API discovery matters

Most organizations already maintain information about their APIs, including:

• OpenAPI specifications
• API catalogs
• Developer portals
• Gateway configurations
• Service registries
• Cloud inventories
• Configuration management databases
• Existing dynamic application security testing targets

These sources show what teams intended to build, document, and govern. They do not always show what is still deployed, reachable, or receiving traffic. Documentation can drift from reality for many reasons:

• A team deploys an endpoint without completing registration.
• An old API version remains active after clients migrate.
• A service becomes reachable directly at its origin.
• A test or staging endpoint is exposed unintentionally.
• An infrastructure change moves an internal API across a trust boundary.
• An acquired product introduces APIs outside existing governance.
• A mobile or partner client continues using a deprecated endpoint.

Runtime discovery provides evidence of what is active or reachable now. That evidence can reveal shadow APIs, zombie APIs, direct-origin exposure, missing ownership, gaps in testing coverage, and differences between documented and deployed authentication controls.

However, runtime evidence is not a replacement for documentation or governance records. Its value comes from comparing what teams expect to exist with what the environment actually exposes.

Runtime discovery and static inventory serve different purposes

An effective API inventory needs both an intended view and an observed view:

• Static records describe what teams have designed, approved, or documented.
• Runtime discovery provides evidence of what is deployed, reachable, or active.

These views are complementary. A mature program continuously compares them and investigates discrepancies rather than treating either one as complete or automatically authoritative.

A runtime-only route may be new, undocumented, misclassified, or incorrectly normalized, while an inventory-only route may be dormant, restricted to a workflow not yet observed, or already retired but never removed from the catalog.

Here’s how static inventory and runtime discovery compare:

Reconciling these two views defines the inventory problem, but it does not yet define the scope of runtime discovery. Before selecting data sources, teams should distinguish discovery from adjacent runtime monitoring and protection activities.

Runtime discovery is not the same as monitoring or protection

“Runtime” can be an ambiguous term when it comes to APIs, and it’s important to be clear on the differences between discovering APIs at runtime and actually monitoring running APIs to detect performance and security issues:

• Runtime API discovery identifies APIs, operations, and changes in deployed environments.
• Runtime API monitoring tracks ongoing activity, performance, policy events, or suspicious behavior.
• Runtime API protection detects or blocks malicious traffic while the API is operating.

API discovery may use data generated by monitoring systems, but its primary output is an inventory and classification of API exposure. It does not replace runtime threat detection, gateway controls, or dynamic security testing. Once this scope is clear, teams can choose the combination of runtime and supporting data sources that best matches their architecture.

Choose runtime data sources based on architecture

No single API discovery source provides a complete view, so you always need some combination of them that matches your specific environment:

Static sources such as specifications and code repositories also play a role, but they provide additional correlation inputs rather than runtime evidence – they help explain whether an observed route is expected and provide context that may not be visible in traffic.

Your choice of starting point depends on the architecture:

• For centralized external APIs, begin with gateway, CDN or WAF, and DAST observations.
• For Kubernetes and microservices, add ingress, service mesh, and cluster runtime data.
• For direct-origin detection, compare gateway records with DNS, load balancer, and network observations.
• For authenticated application workflows, combine dynamic scanning with application-level logging.

Runtime API discovery best practices step-by-step

With the purpose, scope, and source mix established, the next task is to turn those inputs into a governed operating process. The following practices move from building the initial baseline through normalization, reconciliation, classification, testing, remediation, and continuous drift monitoring.

1. Establish the best available baseline

Gather the API information the organization already maintains:

• Specifications and catalogs
• Gateway and routing records
• Service registries
• Cloud and Kubernetes assets
• Existing scan targets
• Ownership and lifecycle records
• Data classifications
• Architecture diagrams
• Known external and partner integrations

The baseline does not need to be perfect – its purpose is to give runtime observations something to be compared with.

Record the source of each entry. Source attribution helps resolve conflicts and shows which processes repeatedly produce stale or incomplete records.

2. Collect and protect signals from multiple runtime layers

Gateway logs alone show only governed traffic. Network observations show active calls but can miss dormant APIs. Kubernetes visibility may reveal internal services without proving whether they are externally reachable. To minimize gaps, combine sources that cover different boundaries:

• Internet-facing traffic
• Internal service communication
• Cloud services
• Containers and clusters
• Application workflows
• Dynamic security testing

The source mix should reflect the architecture rather than the tool stack – discovery is incomplete when it only mirrors the visibility of one control.

Runtime discovery can process paths, headers, parameters, identities, and payload metadata, so apply data minimization from the start:

• Collect only the information needed for route discovery and classification.
• Redact credentials, session tokens, API keys, and personal data.
• Avoid storing full payloads unless necessary and approved.
• Define retention periods and access controls.
• Encrypt discovery data in transit and at rest.
• Account for regional and regulatory requirements.

Discovery should improve visibility without creating a new repository of sensitive traffic data.

3. Normalize endpoints before comparing them

Raw traffic rarely maps cleanly to an API inventory. A single route may appear as thousands of unique paths because requests contain different user IDs, order numbers, tenant names, or timestamps. For inventory purposes, you need to normalize these observations so they can be compared reliably. Here are some examples of normalization:

API versions should usually remain distinct inventory attributes because different versions can have different exposure, authentication, and vulnerability profiles.

At minimum, a normalized API operation should account for:

• Host or service
• HTTP method
• Normalized path
• Relevant query parameters
• API version
• Environment
• Protocol or API type
• GraphQL operation, where applicable

Poor normalization creates inflated inventories and noisy drift alerts. Overly aggressive normalization can combine distinct operations and hide security-relevant differences.

Preserve representative raw observations so analysts and application owners can see why requests were grouped. Do not discard parameters simply because they are excluded from route identity. They may still represent inputs that require security testing.

4. Reconcile runtime observations with approved records

Compare normalized runtime operations with the approved baseline. Flag:

• Runtime APIs missing from the inventory
• Inventory entries not observed at runtime
• Differences in method, path, version, environment, or hostname
• APIs reached outside approved gateway paths
• Authentication behavior that differs from documentation
• Production APIs missing from security testing scope

Treat discrepancies as classification work rather than immediate vulnerabilities.

An observed mismatch may reflect:

• A legitimate new deployment
• An undocumented API
• A deprecated version
• A partner or third-party dependency
• A test route
• An inventory error
• A normalization problem
• An incomplete observation period

The authoritative inventory should result from reconciliation across technical evidence, ownership data, and approved governance records, not by treating any single data source as authoritative.

5. Classify unknown APIs before deciding what to do

Terminology for discovered APIs varies across organizations and vendors. The following working definitions should be mapped to your internal taxonomy where necessary:

Zombie APIs may retain access to the same data and business functions as current versions while receiving fewer patches, tests, and reviews. That combination makes continued traffic to deprecated versions worth prioritizing.

Explicit versioning policies, deprecation windows, sunset dates, client migration tracking, and named owners reduce zombie API risk by making retirement an expected lifecycle activity rather than a discovery-driven cleanup exercise.

6. Assign ownership and operating responsibility

Runtime discovery only becomes actionable when responsibility is clear. At minimum, each API should have:

• An application or service owner
• A business owner where appropriate
• A lifecycle status
• An environment classification
• A documented exposure model
• A security testing status

A workable operating model often divides responsibility as follows:

Define service-level expectations for assigning owners, classifying unknown APIs, testing externally exposed APIs, addressing direct-origin exposure, retiring deprecated versions, and resolving exceptions. Without these expectations, discovery backlogs quickly become another source of unmanaged security data.

7. Validate reachability, authentication, and data sensitivity

Discovering the existence of a route doesn’t establish how an attacker could reach it or what the API exposes. Determine whether each API is:

• Accessible from the internet
• Restricted to an internal network
• Available through a partner connection
• Reachable only through an approved gateway
• Directly reachable at its origin
• Authenticated or unauthenticated
• Limited to specific roles or tenants
• Exposed in production, pre-production, or both

Also identify the broader context:

• Sensitive data handled or returned
• Administrative or high-impact operations
• Write, delete, payment, or account-management functions
• Business criticality
• Compliance relevance

Pay particular attention to any contradictions. An API described as internal but actually reachable from the internet is more urgent than a missing catalog tag.

Direct-origin access can expose an IP address or alternate hostname that bypasses hostname-based routing, SNI-dependent controls, and protections applied only at the gateway, CDN, or WAF. It may also create TLS configuration problems if clients connect outside the intended hostname.

8. Prioritize APIs according to risk

Discovery order should not determine response priority. Use a consistent set of factors:

• External reachability
• Authentication requirements
• Authorization model
• Sensitive data exposure
• Critical or state-changing operations
• Business importance
• Lifecycle status
• Known vulnerabilities
• Testing coverage
• Ownership status
• Gateway and WAF coverage

An illustrative response model could look like this:

The scoring method does not need to be complex, as long as it supports repeatable decisions that security and application teams can explain.

9. Move discovered APIs into security testing

Discovery establishes that an API exists or is active – it can’t tell you whether the API is secure. APIs selected for security assessment should enter a dynamic testing workflow, but not every discovered endpoint is immediately scan-ready. Authentication, application state, data dependencies, and business workflows often require configuration before meaningful testing can begin.

Moving to testing may require:

• Locating or generating an API definition
• Identifying authentication material
• Configuring user roles and tenant contexts
• Supplying valid IDs and test data
• Building request sequences
• Handling state-changing operations safely
• Selecting an appropriate test environment
• Adding the API to DAST and API testing scope
• Routing findings to the responsible team
• Retesting after remediation

Dynamic application security testing (DAST) is a key method for assessing discovered APIs because it evaluates the running application and can identify vulnerabilities that depend on deployed behavior, configuration, authentication, and application responses. For vulnerabilities that can be safely confirmed, Invicti’s API DAST can provide proof that the issue is exploitable. This helps developers distinguish validated findings from issues that still require manual investigation.

10. Verify remediation and decommissioning

Closing a ticket does not prove that exposure is gone. After a fix, configuration change, or retirement decision:

• Retest the original request and exploit path.
• Run an authenticated regression scan using the same role and tenant context.
• For authorization changes, repeat tests across relevant users, roles, objects, and tenants.
• Confirm that restricted endpoints are no longer externally reachable.
• Verify that direct-origin access has been blocked.
• Confirm that deprecated versions no longer accept traffic.
• Update inventory and lifecycle records.
• Ensure replacement APIs are included in testing.

Runtime discovery can show that a supposedly retired endpoint is still receiving requests, while dynamic testing can verify whether a remediation addressed the underlying security issue.

11. Monitor continuously for inventory drift

API estates change whenever teams deploy software, modify infrastructure, onboard partners, release mobile applications, or migrate services. Run discovery continuously or at least frequently enough to match the rate of change. Focus alerts on changes that require a decision:

• A new externally reachable API
• A route missing from the approved inventory
• A deprecated API receiving traffic
• A new direct-origin path
• A production API without testing coverage
• A change in authentication behavior
• An API moving across an exposure boundary
• A sensitive operation with no owner

The purpose of continuous discovery is not continuous interruption, so tune alerts around material changes rather than every raw observation.

Metrics that show whether API discovery is reducing risk

Endpoint counts provide some context, but they do not show whether the program is working. The following metrics are useful for tracking the performance and effectiveness of discovery:

Track trends rather than isolated totals. A rising API count may be caused by genuine environment growth but also by improved discovery. A shrinking unknown backlog and increasing testing coverage are stronger indicators of program maturity.

Common runtime API discovery mistakes

• Relying on one discovery source: No single method provides the full picture. Gateway data, which is a common source, is useful but incomplete – direct-origin, internal, acquired, and independently deployed APIs may remain invisible.
• Treating every path as a different API: Dynamic identifiers can inflate an inventory dramatically. Normalize routes before comparing, counting, or alerting.
• Normalizing too aggressively: Combining distinct methods, versions, GraphQL operations, or input patterns can hide meaningful security differences.
• Assuming observed traffic equals complete coverage: Runtime data can miss dormant, seasonal, role-specific, and low-volume APIs.
• Collecting APIs without assigning owners: An unowned inventory becomes another reporting system rather than a security control.
• Stopping after discovery: Knowing that an API exists does not show whether it contains exploitable vulnerabilities. Following triage, discovery should feed dynamic testing.
• Treating discovery as an annual audit exercise: Inventory drift begins as soon as the audit ends. Continuous deployment requires continuous or frequently repeated reconciliation.

How Invicti connects API discovery to security testing

Invicti combines multilayered API discovery with dynamic API security testing. Discovery signals from scanning, code, gateways, network traffic, and runtime infrastructure can be correlated into a unified view of the API attack surface.

Relevant APIs can then be prepared for authenticated API DAST. For vulnerabilities that can be safely confirmed, proof-based scanning can provide evidence of exploitability, helping teams move from discovery to prioritized remediation with less manual validation.

The result is a continuous connection between API visibility, vulnerability validation, remediation, and retesting.

Next steps

• Learn more about the mechanics, strengths, and blind spots of different API discovery methods.
• Read our guide to finding hidden REST API endpoints.
• Request a demo to see API discovery and API DAST working in tandem in your environment.