canonical: https://jentic.com/apis/googleapis.com/networkmanagement

# Google Network Management API

The Network Management API provides Google Cloud's network performance monitoring and diagnostics surface. It exposes connectivityTests as a primary resource - a saved test definition with source and destination endpoints - together with operations for create, list, rerun, and delete. Use it to verify reachability across VPCs, hybrid networks, and Network Connectivity Center hubs as part of change management or incident response.

## For AI agents

Run Google Cloud connectivity tests across VPCs and hybrid networks. Use to verify reachability after network changes or during incident response.

## Scope

Does not modify firewall rules, routes, or live traffic - use for Google Cloud reachability and connectivity diagnostics only.

## Capabilities

- Create a connectivity test between source and destination endpoints
- Rerun an existing connectivity test to refresh its results
- List all connectivity tests in a project and location
- Inspect detailed reachability traces showing each network hop
- Update or delete obsolete connectivity tests
- Track long-running test creation and rerun operations

## Use cases

### Pre-Change Reachability Verification

Before merging firewall or routing changes, platform teams run a saved suite of connectivity tests to confirm critical paths still work. The connectivityTests resource accepts source and destination endpoints by IP, instance, GKE cluster, or Cloud SQL instance, and returns a per-hop reachability trace for each test.

Example prompt: POST /v1/{parent}/connectivityTests with source.instance and destination.instance set, then POLL the operation until reachabilityDetails.result is REACHABLE.

### Incident Response Trace

When a service reports timeouts, on-call engineers create or rerun a connectivity test from the affected workload to its dependencies. The returned trace shows where packets are dropped - firewall rule, route, or peering - turning a vague 'network issue' into a specific config to fix.

Example prompt: POST /v1/{name}:rerun, then GET /v1/{name} and inspect reachabilityDetails.traces to identify the failing step.

### Hybrid Path Validation

After standing up a Network Connectivity Center hub or new VPN tunnel, hybrid teams validate reachability between on-premises CIDRs and cloud workloads. Connectivity tests support endpoints described by raw IP plus network, so the same test definition can compare expected versus observed reachability across an entire hybrid topology.

Example prompt: POST /v1/{parent}/connectivityTests with source.ipAddress (on-prem) and destination.instance (in-cloud), then surface trace steps that mention the VPN tunnel or hub.

### AI Agent Network Diagnostician

An AI agent reachable through Jentic owns post-change validation: when a deployment changes networking, the agent reruns the relevant connectivity tests and posts the trace summary back to the change ticket. Jentic isolates OAuth credentials and exposes the right Network Management operation per intent so the agent never sees Google service account keys.

Example prompt: Search Jentic for 'rerun a Google Cloud connectivity test', load projects.locations.global.connectivityTests.rerun, and execute with the test resource name.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /v1/{parent}/connectivityTests | List connectivity tests in a project and location |
| POST | /v1/{parent}/connectivityTests | Create a connectivity test |
| PATCH | /v1/{name} | Update a connectivity test |
| DELETE | /v1/{name} | Delete a connectivity test |
| POST | /v1/{name}:rerun | Rerun an existing connectivity test |
| POST | /v1/{name}:cancel | Cancel a long-running operation |

## Key resources

- **connectivityTests** — Saved network reachability test definitions and their latest results
- **operations** — Long-running operations covering test create and rerun

## Why Jentic

- **Setup:** Wiring the Network Management API by hand means setting up Google OAuth 2.0 with the cloud-platform scope, refreshing bearer tokens, and polling long-running connectivity-test operations yourself against the networkmanagement.googleapis.com host. Through Jentic you install once, import the Network Management API from the API Directory, store the OAuth credential once, and your agent calls it.
- **Permission scoping:** The Network Management API puts the connectivity-test name in the URL path (/v1/{parent}/connectivityTests and /v1/{name}...), so a rule can pin your agent to one project's connectivity tests: it can list, create, and rerun tests there and nothing else. You choose the operations it may call, so destructive ones like deleting a test are not included unless you add them.
- **Credential handling:** Your Google OAuth credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'rerun a Google Cloud connectivity test' or 'run a reachability diagnostic', and Jentic returns the matching Network Management operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Compute Engine API** — Manages the VPCs, instances, and firewall rules whose reachability you test
- **Network Connectivity API** — Builds the hub-and-spoke topology whose reachability you validate
- **Network Security API** — Manages firewall and security policies that often appear as failing hops
- **Cloud DNS API** — Resolves the names whose IPs are tested for reachability

## FAQ

### What authentication does the Network Management API use?

OAuth 2.0 with the https://www.googleapis.com/auth/cloud-platform scope (Oauth2 securitySchemes are declared in the spec). The caller needs networkmanagement IAM roles on the project. Jentic stores OAuth refresh tokens in your Jentic One instance and exposes only short-lived access tokens to the agent.

### Which endpoint types can a connectivity test target?

Source and destination endpoints accept IP address, GCE instance, GKE cluster master, Cloud SQL instance, App Engine version, Cloud Run service, and Cloud Function. Each type is set on the endpoint object in the connectivity test body.

### What are the rate limits for the Network Management API?

Per-project quotas are listed in Cloud Console under IAM and Admin > Quotas. Test runs are long-running operations; pace creates and reruns by polling the operation and backing off on 429 with exponential backoff.

### How do I rerun a connectivity test through Jentic?

Search Jentic for 'rerun a Google Cloud connectivity test', load projects.locations.global.connectivityTests.rerun, and execute with the test resource name. Jentic refreshes OAuth in the background and surfaces the long-running operation name.

### Does this API drop or change packets in production?

No. Connectivity tests perform passive reachability analysis using configuration, not live traffic. They do not modify firewall rules, routes, or workloads - they only return the configured-state trace and verdict.

### Can I limit what my agent is allowed to do with the Network Management API?

Yes. Because you self-host Jentic One and write its rules, you decide exactly which Network Management operations your agent may call and which OAuth credential it uses. Since the API carries the connectivity-test name in the URL path (/v1/{parent}/connectivityTests and /v1/{name}), you can pin the agent to one project's tests and allow only listing, creating, and rerunning them. Destructive operations such as deleting a connectivity test are left out unless you explicitly add them.