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

# Google Network Connectivity API

The Network Connectivity API manages Google Cloud's Network Connectivity Center - a hub-and-spoke service that interconnects on-premises networks, VPCs, and hybrid environments. It exposes hubs, spokes, route tables, internal ranges, and policy-based routes so platform teams can build, inspect, and govern transitive connectivity across global Google Cloud infrastructure. Pair it with Compute Engine networking and Cloud DNS for a full hybrid networking control plane.

## For AI agents

Provision and manage Google Cloud Network Connectivity Center hubs, spokes, and routes. Use to wire VPCs and on-premises networks into a single hub topology.

## Scope

Does not provision VPCs, run firewall rules, or perform reachability testing - use for Network Connectivity Center hub, spoke, and internal-range governance only.

## Capabilities

- Create a Network Connectivity Center hub and attach VPC or hybrid spokes
- Inspect and modify route tables and routes within a hub
- Reserve internal IP ranges to avoid VPC overlap
- Define policy-based routes that steer traffic by source or protocol
- Approve or reject pending spoke updates from peer accounts
- Track long-running operations for hub and spoke changes

## Use cases

### Hub-and-Spoke Network Build-Out

Platform teams wire dozens of VPCs and on-premises networks into one transitive topology using a Network Connectivity Center hub. The API supports POSTing hubs and then attaching spokes for VPC, VPN tunnels, interconnect attachments, and router appliances, replacing the manual mesh of VPC peerings with a single hub managed centrally.

Example prompt: POST /v1/{parent}/hubs to create the hub, then POST /v1/{parent}/spokes for each VPC attachment with linkedVpcNetwork.uri set.

### Cross-Project Spoke Approval

Spokes can come from other projects and may require explicit approval before joining the hub. The acceptSpoke and rejectSpoke endpoints let a platform team gate which peer projects join, with full audit logging on each decision. This enforces a clear governance boundary on shared infrastructure.

Example prompt: POST /v1/{name}:acceptSpoke or :rejectSpoke on each pending spoke, providing the requestId for idempotency.

### Internal Range Governance

VPCs that share a hub must avoid CIDR collisions. The internalRanges resource lets a platform team reserve named ranges, allocate them to projects, and detect overlaps before a new VPC is created. Combined with policy-based routes, this gives a deterministic IP plan across the estate.

Example prompt: POST /v1/{parent}/internalRanges with peering and a target CIDR, then GET to confirm allocation and surface overlaps to the requester.

### AI Agent Network Operator

An AI agent reachable through Jentic operates the connectivity hub: it lists pending spokes, approves those from allow-listed projects, reserves internal ranges from a planned pool, and reports on long-running operations. Jentic isolates the OAuth credentials and exposes the right Network Connectivity operation per intent.

Example prompt: Search Jentic for 'attach a VPC spoke to a Network Connectivity hub', load projects.locations.spokes.create, and execute with the linkedVpcNetwork.uri.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /v1/{name} | Get a hub, spoke, or other resource by name |
| DELETE | /v1/{name} | Delete a resource |
| PATCH | /v1/{name} | Update a resource |
| POST | /v1/{name}:acceptSpoke | Approve a pending spoke |
| POST | /v1/{name}:cancel | Cancel a long-running operation |
| GET | /v1/{name}/locations | List locations for the API |

## Key resources

- **hubs** — Network Connectivity Center hubs that interconnect spokes
- **spokes** — VPC, VPN, interconnect, or router appliance attachments to a hub
- **internalRanges** — Reserved CIDR ranges for VPC use
- **routeTables** — Route tables associated with a hub
- **operations** — Long-running operations covering hub and spoke changes

## Why Jentic

- **Setup:** Wiring the Network Connectivity API by hand means setting up Google OAuth 2.0 with the cloud-platform scope, minting bearer tokens, and polling long-running hub and spoke operations yourself against the networkconnectivity.googleapis.com host. Through Jentic you install once, import the Network Connectivity API from the API Directory, store the OAuth credential once, and your agent calls it.
- **Permission scoping:** The Network Connectivity API puts the hub or spoke name in the URL path (/v1/{name}...), so a rule can pin your agent to one Connectivity Center resource: it can read it and accept a spoke there and nothing else. You choose the operations it may call, so destructive ones like deleting or patching a resource 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 'attach a VPC spoke to a hub' or 'accept a network spoke', and Jentic returns the matching Network Connectivity 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, VPN tunnels, and interconnect attachments referenced as spokes
- **Cloud DNS API** — Provides DNS for the workloads connected over the NCC hub
- **Service Networking API** — Configures private services access used alongside hub spokes
- **Network Management API** — Runs connectivity tests across the topology that Network Connectivity built

## FAQ

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

OAuth 2.0 with the https://www.googleapis.com/auth/cloud-platform scope (the spec declares Oauth2 securitySchemes). The caller's principal needs networkconnectivity IAM roles on the project. Through Jentic the OAuth refresh token is held in your Jentic One instance and the agent only receives scoped access tokens.

### Can I attach an on-premises network as a spoke?

Yes. POST /v1/{parent}/spokes with linkedInterconnectAttachments or linkedVpnTunnels referencing the hybrid resources, and the on-premises traffic flows through the hub to other spokes that allow it.

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

Like most Google Cloud APIs the per-project quota is documented in Cloud Console under IAM and Admin > Quotas. Mutating calls return long-running operations; poll the operations resource and back off on 429 with exponential backoff.

### How do I attach a VPC spoke through Jentic?

Search Jentic for 'attach a VPC spoke to a Network Connectivity hub', load projects.locations.spokes.create, and execute with parent set to the hub's location and linkedVpcNetwork.uri set to the VPC self link. Jentic refreshes the OAuth token in the background.

### Does this API replace VPC peering?

Network Connectivity Center hubs provide transitive connectivity across many spokes, removing the N-squared peering mesh. VPC peering is still available for direct two-VPC scenarios and is configured via the Compute Engine API, not this one.

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

Yes. Because you run Jentic One yourself, your own rules decide which Network Connectivity operations and OAuth credentials the agent may use. Since the hub or spoke name sits in the URL path (/v1/{name}...), you can pin the agent to a single Connectivity Center resource, letting it read that hub and accept a pending spoke there and nothing else. Destructive operations such as deleting or patching a hub or spoke are excluded unless you explicitly grant them.