Google Service Control API

Name: Service Control API
Brand: Service Control API
Availability: InStock

✓ Official Vendor SpecCloud InfrastructureNetworkingoauth23 Endpoints

Install Jentic One Beta

Connect the Service Control API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Service Control 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.

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 | sh

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 instance

Jentic 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 Service Control API.

Run a pre-request check to validate that the consumer has the service enabled and is within policy

Allocate quota against per-consumer metric buckets before serving an operation

Report telemetry — operation name, consumer, labels, metric values — for billing and audit

GET STARTED

Start building with Service Control API

Explore with Jentic

View OpenAPI Document

For Agents

Run admission checks, allocate quota, and report usage telemetry for services built on Google's Service Infrastructure.

Use for: Check whether a consumer is allowed to call my managed service, Allocate 1 unit of read quota for a consumer before processing a request, Report a successful operation with its latency and consumer metadata, Batch report 100 buffered operations to reduce API calls

Not supported: Does not handle end-user authentication, service definition publishing, or general logs ingestion — use for runtime admission control, quota allocation, and telemetry reporting only.

Use Cases

Patterns agents use Service Control API for, with concrete tasks.

★ Managed Service Admission Control

Producers running a managed service on GCP call services.check before each request to confirm the consumer project has the service enabled, billing is healthy, and the call is policy-compliant. This replaces hand-rolled IAM and billing checks with the same control plane Google's own services use, returning structured errors that map cleanly to HTTP status codes.

Call POST /v1/services/{serviceName}:check with the consumer project id and operation name; deny the inbound request if the response contains a checkError.

Metered Quota Enforcement

For metered or rate-limited operations, call services.allocateQuota with the metric and quantity before processing the request, then services.report after to confirm the allocation was used. Service Control handles per-consumer counters across regions and exposes RESOURCE_EXHAUSTED when the consumer hits their limit.

Call POST /v1/services/{serviceName}:allocateQuota with quotaMetrics including 'reads/min' set to 1 for the consumer, then proceed only if the response has no allocationErrors.

Usage and Audit Telemetry Reporting

After serving each request, call services.report with operation metadata so billing, audit logs, and SLO reporting see the call. The report endpoint accepts batches of operations with metric values and labels, and integrates with Cloud Billing and Cloud Audit Logs without additional plumbing.

Buffer up to 1,000 operations, then call POST /v1/services/{serviceName}:report with the batch and a unique operationId per entry.

AI Agent Service Operator

An AI agent that fronts a managed-service request handler uses Service Control to enforce policy and emit telemetry without each request handler having to embed the logic. Through Jentic the agent invokes check, allocateQuota, and report as discrete operations and never touches the producer's service account credentials directly.

On each inbound request, call services:check, then allocateQuota, run the underlying business logic, and finally call services:report with the captured metric values.

Key Endpoints

3 endpoints — service control is the runtime admission-control and telemetry-reporting endpoint for services integrated with google's service infrastructure.

METHOD

PATH

DESCRIPTION

POST

/v1/services/{serviceName}:check

Run a pre-request admission check

POST

/v1/services/{serviceName}:allocateQuota

Allocate quota against per-consumer metrics

POST

/v1/services/{serviceName}:report

Report usage and audit telemetry

POST

/v1/services/{serviceName}:check

Run a pre-request admission check

POST

/v1/services/{serviceName}:allocateQuota

Allocate quota against per-consumer metrics

POST

/v1/services/{serviceName}:report

Report usage and audit telemetry

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Producer service account credentials are stored encrypted in the Jentic MAXsystem vault. Agents call Service Control with a short-lived scoped access token, and never see the long-lived service account key material that signs check, allocateQuota, and report calls.

Intent-based discovery

Agents search Jentic by intent (e.g. 'check whether a consumer can call my service') and Jentic returns the matching services:check operation with its consumer and operation schema, so the agent can construct payloads without navigating the producer SDK.

Time to first call

Direct integration: 1-3 days to wire check/allocateQuota/report into the request path with sane batching and retry. Through Jentic: under 1 hour — search, load, execute.

FAQs

Specific to using Service Control API through Jentic.

What authentication does the Service Control API use?

Service Control uses OAuth 2.0 with the cloud-platform or servicecontrol scope, called by the producer's service account that holds roles/servicemanagement.serviceController. Through Jentic the credentials are stored encrypted in MAXsystem and exchanged for a scoped token at execution.

Does the Service Control API perform IAM authorization for end users?

No. services:check validates service activation, billing, and policy at the consumer-project level, not end-user IAM. End-user authorization should be enforced separately in the producer service before the call.

What are the rate limits for the Service Control API?

Google enforces high per-service quotas (tens of thousands of QPS) for check and report because they are designed to sit on the request hot path. Practical limits depend on the consumer project and are surfaced as RESOURCE_EXHAUSTED in checkErrors.

How do I report telemetry through Jentic?

Run the Jentic search query 'report telemetry to service control', load POST /v1/services/{serviceName}:report, and execute it with a list of Operation objects. Jentic handles the producer service account token so the agent only constructs the operation payloads.

Why does check sometimes return success with checkErrors populated?

Check returns a 200 with structured checkErrors so the caller can decide whether to deny the request, surface a billing-disabled message, or fall back. Only treat the response as 'allowed' when checkErrors is empty.

Can I use the v2 Service Control endpoints?

Yes — a v2 surface exists for newer integrations. This enrichment covers v1, which is still the default for most producer integrations and exposes the check, allocateQuota, and report operations directly.

Google Service Control API

Connect the Service Control API to your agent

Capabilities

Start building with Service Control API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs