Google Service Control API
Browse all Google APIs✓ Official Vendor SpecCloud InfrastructureNetworkingoauth23 EndpointsREST
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.
Service Control is the runtime admission-control and telemetry-reporting endpoint for services integrated with Google's Service Infrastructure. Service producers call check before serving a request to enforce per-consumer policy, allocateQuota to debit metered quota buckets, and report to push usage and audit telemetry into the GCP control plane. It is what powers the per-consumer enforcement and billing for Google's own and partner-managed APIs.
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.
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 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
Batch multiple operations into a single report call to reduce overhead
Surface check errors (SERVICE_NOT_ACTIVATED, BILLING_DISABLED, RESOURCE_EXHAUSTED) for clear caller feedback
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.
Related APIs
Alternatives and complements available in the Jentic catalogue.
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.
GET STARTED