API Inventory and Detection
API Inventory turns runtime traffic into an endpoint inventory. The sensor observes HTTP, HTTP/2, gRPC, and 5G SBI calls from the workload process itself, enriches the events with Kubernetes and process context, and the Console aggregates those events into an operator view for inventory, detections, and workload-to-destination topology.
This is useful when the API surface is larger than the OpenAPI file, ingress manifest, or service catalog. Telovix shows the routes that actually executed, the workload and namespace that produced them, the destination they reached, the capture method used, request volume, error rate, and the first and last time the endpoint was seen.
Where to find it
In the Console, navigate to Kubernetes > API Inventory for a cluster-scoped view.
The page is organized around three views:
| View | What it helps you answer |
|---|---|
| Inventory | Which API routes are active, which workload owns them, which protocol they use, how often they are called, and whether they return errors. |
| Detections | Which API routes deserve attention because they are new, sensitive, administrative, unusually noisy, or returning elevated server errors. |
| Topology | Which workloads call which API destinations, including service-to-service and external relationships. |
Use the cluster and time filters at the top of the page to narrow the view during an investigation. The inventory is designed for operational review, change validation, exposure management, and incident triage.
How the sensor builds the inventory
The sensor does not rely on ingress definitions or application framework instrumentation. It creates API evidence from runtime buffers already visible to the sensor.
| Observation mode | What it covers |
|---|---|
| Cleartext traffic | HTTP/1 and H2C traffic observed from process I/O activity. |
| TLS write path | Outbound request data observed before the workload encrypts it. |
| TLS read path | Inbound response data observed after the workload decrypts it. |
| Go services | Go TLS traffic from services that use the standard Go TLS stack. |
| OpenSSL, GnuTLS, and BoringSSL services | TLS traffic from common native TLS libraries when the required runtime symbols are available. |
For TLS 1.3 traffic, Telovix captures the plaintext at the TLS library boundary. The data is still encrypted on the wire. The sensor observes the buffer before the process gives it to the TLS library on the write path, or after the TLS library returns decrypted bytes on the read path. No private key, certificate export, proxy, sidecar, or man-in-the-middle position is required.
The sensor parses captured buffers as HTTP/1, HTTP/2, gRPC, or 5G SBI. When an HTTP/2 DATA frame is present, the body can also be captured up to the configured limit. For API Inventory, the long-term surface is the normalized endpoint metadata, not raw bodies.
Inventory fields
Each inventory row represents an observed endpoint aggregate.
| Field | Meaning |
|---|---|
endpoint | Normalized path. Numeric IDs, UUIDs, and long hex strings are collapsed into placeholders such as {id}, {uuid}, and {hex}. |
method | HTTP method, such as GET, POST, PUT, PATCH, or DELETE. |
protocol | Protocol classification: http1, http2, grpc, 5g_sbi, or h2c. |
workload | Best available service identity from Kubernetes workload name, pod name, workload ID, process executable, or node fallback. |
namespace | Kubernetes namespace, or node fallback when namespace data is not available. |
destination | HTTP authority or gRPC service, when present. |
source_process | Process executable that produced the API event. |
capture_method | Runtime source that explains how Telovix observed the traffic, such as cleartext process I/O or TLS read/write visibility. |
status_distribution | Response count grouped by 2xx, 3xx, 4xx, 5xx, or unknown. |
request_count | Number of request events in the selected window. |
error_rate | 4xx and 5xx responses divided by total responses. |
first_seen, last_seen | Observation window for the endpoint aggregate. |
Inventory rows are retained for long-term review so teams can compare current exposure with recently observed behavior.
API detections
API detections are generated from the aggregate inventory. They are designed to surface changes and sensitive paths without requiring the application to publish an API specification.
| Detection | Severity | Trigger |
|---|---|---|
| New endpoint exposed | medium | An endpoint appears in the current window but was not present in the recent baseline. |
| Administrative path accessed | high | A route matches administrative or management path patterns such as /admin, /manage, /debug, /actuator, or /phpmyadmin. |
| Sensitive route touched | high | A route matches credential, token, login, secret, key, password, reset, MFA, environment, or configuration path patterns. |
| Unexpected method | medium or high | A method was not observed for this endpoint in the baseline, or the method is especially risky, such as TRACE or CONNECT. |
| Server error spike | high | 5xx responses are elevated against the baseline for the same endpoint and method. |
| New external API destination | medium | An external destination appears in the current window but was absent from the baseline. |
| High request rate from one workload | medium | One workload generates a high request rate compared with its recent behavior. |
Detections include the endpoint, method, workload, namespace, destination, request count, error rate, first seen, last seen, severity, and reason.
TLS 1.3 visibility
API Inventory uses the same TLS visibility engine described in TLS Visibility and SBI Decryption. The important point is where observation happens.
TLS 1.3 protects bytes on the network. Telovix does not break that encryption on the wire. Instead, it instruments the process TLS library and observes plaintext at the moment the application hands data to the library or receives decrypted data from it. That allows API discovery to work for modern encrypted services, including HTTP/2 and 5G SBI, without asking operators to disable TLS or deploy an inline proxy.
The capture_method field tells operators which visibility path produced the row. This is useful when validating whether an endpoint was discovered from cleartext traffic, outbound TLS plaintext before encryption, or inbound TLS plaintext after decryption.
INFO
TLS visibility is designed for modern production workloads. Telovix covers common TLS implementations including OpenSSL, GnuTLS, Go TLS, and BoringSSL, and maps decrypted API activity back to workload and process context.
Kubernetes and telecom context
On Kubernetes nodes, API Inventory correlates API events with cluster name, namespace, workload identity, source process, and destination. The Console uses this to show API exposure per cluster and to build workload-to-destination topology.
For telecom deployments, HTTP/2 paths that match 3GPP SBI service patterns are classified as 5g_sbi. This lets the same inventory mechanism show application APIs, Kubernetes API access, gRPC services, and 5G Core service-based interface traffic in one model.
Operational notes
API discovery is enabled by default in the sensor. In most deployments, no application code changes, SDK, sidecar, proxy, certificate export, or service mesh integration is required.
Large environments should review the page by cluster and time window. A newly deployed service can legitimately produce many "new endpoint" detections until the baseline represents normal traffic.
Visibility Coverage
API Inventory is based on observed runtime traffic. This keeps the inventory accurate to what actually executes in production, including internal service calls, gRPC traffic, Kubernetes API access, and encrypted HTTP/2 or 5G SBI flows.
Telovix normalizes dynamic route segments such as numeric IDs, UUIDs, and long hex values so teams can review stable API surfaces instead of high-cardinality request paths. As traffic volume grows, the inventory becomes a reliable baseline for exposure review, change validation, and investigation.
For newly deployed services, "new endpoint exposed" detections are expected while Telovix learns the normal API surface. After the baseline settles, these detections become a clear signal for newly introduced or unexpected routes.