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

# Google Cloud Run Admin API

The Cloud Run Admin API v2 deploys and manages user-supplied container images that scale automatically based on incoming requests, aligned with Google Cloud AIP-based API standards. It exposes operations to deploy services, run jobs, manage revisions, list operations, export metadata and images, and cancel or wait on long-running operations. Cloud Run is the serverless container platform on Google Cloud and is the v2 successor to the Knative Serving API surface used by v1.

## For AI agents

Deploy container images as autoscaling Cloud Run services and jobs, manage revisions, and run jobs with overrides programmatically.

## Scope

Does not build container images, route DNS, or sign TLS certificates - use for managing Cloud Run services, jobs, revisions, and operations only.

## Capabilities

- Deploy a container image as an autoscaling Cloud Run service with custom CPU, memory, and concurrency
- Trigger one-off Cloud Run job executions with parameter overrides for batch workloads
- List, get, and delete revisions to roll back or audit deployment history
- Wait on or cancel long-running operations associated with deploys and updates
- Export image metadata, project metadata, and operation status for compliance and inventory
- Patch service and job configuration to adjust scaling, concurrency, environment variables, or service account

## Use cases

### GitOps-driven service deployment

A deployment agent watches a container registry for new tags, calls the Cloud Run service create or replace endpoint to roll forward to the new image, waits on the long-running operation, and reports success back to the GitOps controller. The Admin API v2 returns operation handles that the agent can poll or cancel deterministically.

Example prompt: Call the Cloud Run service create endpoint with an image reference, then call /v2/{+name}:wait until the long-running operation reports done.

### Scheduled job execution

A batch agent triggers nightly Cloud Run jobs with environment-variable overrides - for example, the date partition to process - and monitors the resulting executions for completion or failure. POST /v2/{+name}:run launches the job execution and returns an operation that the agent waits on.

Example prompt: POST /v2/{+name}:run on the nightly-etl job with overrides setting RUN_DATE=2026-06-09, then poll the operation until done.

### Safe rollback on incident

When a release agent detects elevated 5xx rates, it lists revisions for the affected service, identifies the previous healthy revision, and patches the service traffic configuration to send 100% of traffic back to it. This contains incidents in seconds without redeploying the previous image.

Example prompt: List revisions under the affected service, then PATCH the service to set traffic.percent=100 on the prior revision name.

### Agent-driven container deploys through Jentic

An AI agent built on Jentic deploys and updates Cloud Run services on behalf of developers. It searches for the deploy operation by intent, loads the schema, executes the call, and waits on the operation. OAuth tokens stay isolated in Jentic's vault, and the agent never holds a service-account key.

Example prompt: Search Jentic for 'deploy container to cloud run', load the create-service schema, execute against projects/my-prod/locations/us-central1, then call wait until done.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /v2/{+name} | Get a Cloud Run service, job, or revision |
| PATCH | /v2/{+name} | Patch a service or job |
| DELETE | /v2/{+name} | Delete a service, job, or revision |
| POST | /v2/{+name}:run | Run a Cloud Run job |
| POST | /v2/{+name}:wait | Wait on a long-running operation |
| POST | /v2/{+name}:cancel | Cancel a long-running operation |
| POST | /v2/{+name}:exportImage | Export an image associated with a service |
| GET | /v2/{+name}:exportImageMetadata | Export metadata for an image |

## Key resources

- **Services** — Create, get, patch, delete, and list Cloud Run services that autoscale on incoming requests.
- **Jobs** — Create, run, get, and delete Cloud Run jobs for batch and one-off container workloads.
- **Revisions** — List and inspect immutable revisions produced by service updates.
- **Operations** — Track, cancel, and wait on long-running operations for deploys and updates.

## Why Jentic

- **Setup:** Wiring the Cloud Run Admin API by hand means setting up Google OAuth 2.0, minting scoped access tokens, and threading service, job, and revision resource names through the v2 admin endpoints on run.googleapis.com. Through Jentic you install once, import the Cloud Run Admin API from the API Directory, store the OAuth credential once, and your agent calls it.
- **Permission scoping:** This API puts the service, job, and revision in the URL path (/v2/{+name}), so a rule can pin your agent to one service or job: it can read and run that resource and nothing else. You choose the operations it may call, so state-changing ones like deleting a service or cancelling an execution are not included unless you add them.
- **Credential handling:** Your Google OAuth credential is stored once, encrypted, by your own Jentic One instance and a scoped access token is injected at execution time. The credential never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'deploy a container to Cloud Run' or 'run a Cloud Run job', and Jentic returns the matching v2 admin operation with its input schema so the agent calls the right endpoint without reading the discovery document.

## Related APIs

- **Cloud Functions API** — Function-as-a-service alternative to Cloud Run for event-driven code without containers.
- **App Engine Admin API** — Older PaaS option that competes with Cloud Run for managed app hosting.
- **Kubernetes Engine API** — Self-managed Kubernetes when Cloud Run's managed model is too constrained.
- **Artifact Registry API** — Stores the container images Cloud Run deploys.

## FAQ

### What authentication does the Cloud Run Admin API use?

It uses Google OAuth 2.0 with the cloud-platform scope, declared as Oauth2 and Oauth2c. Service-account credentials and refresh tokens are typically used; through Jentic these stay encrypted in the vault, with the agent receiving a short-lived access token at execution time.

### Can I run Cloud Run jobs with overrides through the Admin API?

Yes. POST /v2/{+name}:run executes a Cloud Run job and accepts overrides for environment variables, args, and timeouts on a per-execution basis. The endpoint returns a long-running operation that the agent can poll with /v2/{+name}:wait or cancel with /v2/{+name}:cancel.

### What are the rate limits for the Cloud Run Admin API?

Google Cloud applies per-project quotas to Cloud Run admin calls; the default is 600 mutate requests per minute per project for service and job updates. Long-running operations also count against the maximum concurrent operations quota, which can be raised through the Cloud Console.

### How do I deploy a container to Cloud Run through Jentic?

Search Jentic for 'deploy container to cloud run', load the schema for the service create endpoint, and execute with parent set to projects/PROJECT/locations/LOCATION and the desired image and resource limits. Jentic returns the operation handle so the agent can wait on completion before sending traffic.

### Is the Cloud Run Admin API free?

The API itself is free to call within Google Cloud quotas; you pay only for the Cloud Run service or job execution time, billed per CPU-second and memory-GB-second with a generous free tier. Idle services with minScale=0 incur no charge between requests.

### How do I roll back to a previous Cloud Run revision?

List revisions for the service with GET /v2/{+name}/revisions, then PATCH the service to set its traffic split to 100% on the previous revision name. The service immediately stops sending traffic to the broken revision without redeploying or rebuilding the image.

### Can I limit what my agent is allowed to do with the Cloud Run Admin API?

Yes. Because you run Jentic One yourself, your own rules decide which Cloud Run operations and credentials the agent may use. This API puts the service, job, and revision in the URL path (/v2/{+name}), so you can pin the agent to a single service or job and let it read or run only that resource. You also choose the exact operations it can call, so state-changing ones like deleting a service or cancelling an execution stay off unless you add them.