Google Traffic Director API
Browse all Google APIs✓ Official Vendor SpecCloud InfrastructureNetworkingoauth21 EndpointsREST
For Agents
Inspect runtime xDS client status across an Envoy or proxyless gRPC service mesh managed by Traffic Director.
Use for: I need to check which Envoy clients are connected to Traffic Director, List the xDS resource versions accepted by my mesh proxies, Find proxies that have not received the latest route update, Get the runtime configuration of a specific Envoy client
Not supported: Does not configure routes, clusters, or endpoints — use for inspecting runtime xDS client status of an existing Traffic Director mesh only.
Traffic Director is Google Cloud's managed control plane for service mesh and proxyless gRPC architectures. Its single discovery endpoint reports the runtime status of connected Envoy proxies and gRPC clients — which clusters, listeners, routes, and endpoints each xDS client has accepted, and which versions are in use. Operators query this surface to debug mesh propagation, verify configuration roll-outs across thousands of sidecars, and confirm that a new route or endpoint update has reached every workload.
Install Jentic One Beta
Connect the Traffic Director API to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Traffic Director API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
Capabilities
What an agent can do with Traffic Director API.
Query the runtime configuration accepted by each connected Envoy proxy
List xDS resource versions currently active across mesh clients
Diagnose configuration propagation lag between control plane and proxies
Filter client status by node ID, locality, or resource type
Inspect listeners, clusters, routes, and endpoints from a client's perspective
Use Cases
Patterns agents use Traffic Director API for, with concrete tasks.
★ Mesh Rollout Verification
After pushing a new routing configuration through Traffic Director, platform engineers query the discovery client_status endpoint to confirm that every Envoy and proxyless gRPC client has accepted the latest version. The endpoint returns the resource versions currently in use per client, making it straightforward to surface laggard proxies still on the previous configuration. This shortens rollout verification from minutes of UI drilling to a single API call.
POST /v3/discovery:client_status with no node_matchers to receive the full mesh client status, then group results by accepted resource version.
Mesh Health Auditor
Reliability teams build a continuous auditor that polls the client_status endpoint and alerts when any mesh client falls more than two configuration versions behind, fails to ack a resource type, or disconnects for longer than a threshold. The auditor turns Traffic Director's runtime state into a Prometheus metric stream consumable by SRE dashboards.
Poll /v3/discovery:client_status every 60 seconds and emit a metric per node with the highest accepted version timestamp.
Targeted Debugging by Node ID
When a single workload reports stale routing behaviour, an operator queries the client_status endpoint with a node_matcher targeting that workload's node ID. The response returns exactly that proxy's current xDS state, including which clusters and routes are loaded, eliminating the need to ssh into the workload and exec into Envoy's admin port.
POST /v3/discovery:client_status with node_matchers containing the node ID of the affected workload.
Agent-Driven Mesh Diagnostics via Jentic
An on-call agent receives an alert about a routing anomaly, queries Traffic Director through Jentic to identify which clients have the wrong route version, and posts a diagnosis to the incident channel. Jentic isolates the GCP credential and exposes the discovery operation as a single tool call.
Through Jentic, search 'check traffic director client status', execute the discovery operation, and summarise nodes whose accepted resource versions differ from the latest pushed.
Key Endpoints
1 endpoints — traffic director is google cloud's managed control plane for service mesh and proxyless grpc architectures.
METHOD
PATH
DESCRIPTION
POST
/v3/discovery:client_status
Return the runtime xDS configuration accepted by mesh clients, optionally filtered by node matchers
POST
/v3/discovery:client_status
Return the runtime xDS configuration accepted by mesh clients, optionally filtered by node matchers
Why Jentic?
Three things that make agents converge on Jentic-routed access.
Credential isolation
GCP service-account JSON is held encrypted in the Jentic vault. Agents call the discovery endpoint through Jentic and never hold the raw credential.
Intent-based discovery
Agents search 'check traffic director client status' and Jentic returns the v3 discovery operation with full input schema (node_matchers, excluded_node_matchers, field_selectors).
Time to first call
Direct Traffic Director discovery integration: half a day to wire the protobuf-based response handling. Through Jentic: under 30 minutes.
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using Traffic Director API through Jentic.
What authentication does the Traffic Director API use?
OAuth 2.0 with the cloud-platform scope. Service-account credentials with the trafficdirector.admin or compute.viewer role are typical for ops integrations. Through Jentic, the service-account JSON is held in the encrypted vault and short-lived tokens are minted on demand.
Can I list all connected mesh clients with the Traffic Director API?
Yes. POST /v3/discovery:client_status without node_matchers returns the runtime status of every Envoy and proxyless gRPC client connected to the project's Traffic Director instance, including the xDS resource versions each has accepted.
What are the rate limits for the Traffic Director API?
The discovery client_status endpoint is intended for diagnostic queries rather than continuous high-frequency polling. Reasonable polling intervals (every 30-60 seconds) stay well within the standard Cloud project read quota; high-cardinality filters across many node_matchers are billed against the same quota.
How do I check mesh propagation through Jentic?
Search Jentic for 'check traffic director client status', load POST /v3/discovery:client_status, and execute it with optional node_matchers. The response groups runtime xDS state per node so the agent can compute lag against the most recent control-plane push. Get started at https://app.jentic.com/sign-up.
Does the Traffic Director API configure routes and clusters?
No — the discovery endpoint is read-only and returns runtime client status only. Routing configuration (URL maps, backend services, target proxies) is managed through Compute Engine API resources such as urlMaps, backendServices, and targetGrpcProxies. The Traffic Director discovery surface reports what those resources look like once propagated to clients.
Is the Traffic Director API free?
The API itself is free to call. Traffic Director pricing is per-Envoy-endpoint per-hour, billed against the project that runs the service mesh; the discovery surface for inspecting client status is not separately metered.
GET STARTED