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

# Google Service Networking API

Service Networking automates the network plumbing required for managed Google Cloud services that need private connectivity into a customer's VPC, like Cloud SQL, Memorystore, and AlloyDB. The API lets you create and manage VPC peerings between a producer service and a consumer VPC, allocate private IP ranges from the consumer side, manage DNS zones for the producer service, and configure VPC Service Controls. It is the control plane behind 'Private services access' in the GCP UI.

## For AI agents

Configure private VPC peerings, allocated IP ranges, and DNS zones between Google's managed services and a consumer VPC.

## Scope

Does not handle VPC creation, public load balancing, or general DNS administration - use for producer-consumer VPC peering, allocated ranges, and producer DNS for managed services only.

## Capabilities

- Create and update private VPC peering connections between a producer service and a consumer VPC
- Allocate, list, and delete private IP ranges that producer services can use
- Manage producer-side DNS zones and DNS records that resolve inside the consumer network
- Configure VPC Service Controls policies on a service connection
- Search and enable producer DNS routes for hybrid resolution
- Track long-running operations for asynchronous network provisioning

## Use cases

### Private Services Access for Managed Databases

Provision the VPC peering and reserved IP range that Cloud SQL, Memorystore, AlloyDB, and similar managed services need to reach customer workloads on private IPs. Service Networking creates the producer-side network, peers it with the consumer VPC, and tracks the allocated ranges so the same setup can host many service instances.

Example prompt: Call POST /v1/services/{serviceName}/connections with the consumer VPC network and reservedPeeringRanges set to the allocated range name.

### Network Range Lifecycle Management

Allocate, expand, and reclaim private IP ranges as your portfolio of managed services grows. The API exposes addRoles and removePrivateUsedIpRange-style operations under the connections resource, plus IP range management on the consumer side, so operators can extend ranges without manually editing route tables.

Example prompt: Call PATCH /v1/services/{serviceName}/connections/{connectionId} with reservedPeeringRanges updated to include the new range, then poll the long-running operation.

### Hybrid DNS Resolution

Configure producer-side DNS zones and records so that consumer workloads resolve managed-service hostnames inside the peered network without leaking through public DNS. Use the dnsRecordSets and dnsZones operations to add CNAMEs, manage forwarding behaviour, and audit records over time.

Example prompt: Call POST /v1/services/{serviceName}/projects/{projectNumber}/global/networks/{network}/dnsZones to create a private zone for the managed service domain.

### AI Agent Network Provisioner

An AI agent automates network setup for new managed-service deployments - picking a non-overlapping range, creating the peering, configuring DNS, and reporting back when the long-running operation finishes. Through Jentic the agent searches for the right operation by intent and never holds the customer's GCP service account credentials directly.

Example prompt: Allocate a /20 range that does not collide with existing subnets, call services/{service}/connections to create the peering, then verify with services/{service}/connections.list.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /v1/services/{serviceName}/connections | Create a VPC peering connection |
| GET | /v1/services/{serviceName}/connections | List existing connections |
| PATCH | /v1/services/{serviceName}/connections/{connectionId} | Update a connection's allocated ranges |
| POST | /v1/services/{serviceName}:addSubnetwork | Add a producer subnetwork to the connection |
| POST | /v1/services/{serviceName}/dnsZones:add | Add a producer DNS zone |
| POST | /v1/services/{serviceName}/dnsRecordSets:add | Add a DNS record set inside a producer zone |

## Key resources

- **services** — Manage producer services that participate in private services access
- **connections** — Create and update VPC peering connections to consumer VPCs
- **dnsZones** — Create and manage producer-side DNS zones
- **dnsRecordSets** — Add and update DNS records inside producer zones
- **vpcServiceControls** — Configure VPC Service Controls policy on a connection
- **operations** — Track long-running networking provisioning operations

## Why Jentic

- **Setup:** Wiring Google Service Networking by hand means configuring a service account, minting OAuth access tokens against servicenetworking.googleapis.com, and mapping its producer-consumer peering model yourself. Through Jentic you install once, import the Service Networking API from the API Directory, store the OAuth credential once, and your agent calls it.
- **Permission scoping:** Service Networking puts the service name in the URL path (/v1/services/{serviceName}/connections), so a rule can pin your agent to one peered service: it can create and read connections for that service and nothing else. You choose the operations it may call, so adding subnetworks or DNS zones is not included unless you add it.
- **Credential handling:** Your Service Networking 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 'create a private services access connection' or 'add an allocated range', and Jentic returns the matching Service Networking operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Google Compute Engine API** — Owns the consumer VPC networks and IP ranges that Service Networking peers into.
- **Google Cloud DNS API** — Manages broader DNS zones and records that complement Service Networking's producer-side DNS.
- **Google Service Management API** — Publishes the service definitions that then use Service Networking for private connectivity.
- **Google Service Usage API** — Manages whether services are enabled on a project, an alternative entry point for service-level admin.

## FAQ

### What authentication does the Service Networking API use?

It uses OAuth 2.0 with the cloud-platform or service.management scope and IAM permissions like roles/servicenetworking.networksAdmin on the consumer project. Through Jentic the credentials are stored encrypted in your Jentic One instance and a scoped token is provided at execution.

### Which Google services use Service Networking under the hood?

Cloud SQL private IP, Memorystore for Redis, AlloyDB, Filestore, and several other managed services rely on Service Networking peerings to reach customer VPCs. The same API provisions all of them through the servicenetworking.googleapis.com producer.

### What are the rate limits for the Service Networking API?

Google enforces a default per-project quota of 600 read requests per minute and 60 write requests per minute. Most write actions are long-running operations because peering and IP allocation involve VPC programming.

### How do I create a private services access connection through Jentic?

Run the Jentic search query 'create a service networking connection', load POST /v1/services/{service}/connections, and execute it with the consumer network and reservedPeeringRanges. Jentic handles the OAuth token and operation polling.

### Can I expand an allocated range without recreating the connection?

Yes. PATCH the connection with an updated reservedPeeringRanges list that includes the additional range. Service Networking widens the peering in place; existing service instances continue to work.

### Does the API support VPC Service Controls?

Yes. The vpcServiceControls subresource on a connection lets you read and write the VPC-SC policy that governs traffic between the producer and consumer networks for that managed service.

### Can I limit what my agent is allowed to do with the Service Networking API?

Yes. Because Service Networking puts the service name in the URL path, such as /v1/services/{serviceName}/connections, your self-hosted Jentic One instance can pin the agent to one peered service so it only creates and reads connections for that service. You decide which operations the agent may call, so actions like adding a subnetwork or a producer DNS zone stay off unless you allow them. The OAuth credential is stored encrypted by your own Jentic One and injected at execution, never entering the agent's prompt or logs.