Google Cloud Composer API

Name: Cloud Composer API
Brand: Cloud Composer API
Availability: InStock

✓ Official Vendor SpecDeveloper ToolsCi Cdoauth221 EndpointsREST

Install Jentic One Beta

Connect the Cloud Composer API to your agent

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

Create, update, and delete managed Apache Airflow environments

Execute Airflow CLI commands inside an environment and poll their output

Save and load environment snapshots for backup, upgrade, and migration

GET STARTED

Start building with Cloud Composer API

Explore with Jentic

View OpenAPI Document

For Agents

Provision Cloud Composer environments, execute Airflow CLI commands remotely, take snapshots, and manage user workloads. Lets agents drive managed Apache Airflow without operating the underlying cluster.

Use for: I need to create a new Cloud Composer environment, Run an Airflow CLI command in my Composer environment, Trigger a database failover for a Composer environment, Take a snapshot of a Composer environment for backup

Not supported: Does not author DAG code, run jobs outside Airflow, or replace data processing engines like Dataflow - use for managing Cloud Composer environments and remotely executing Airflow commands only.

Use Cases

Patterns agents use Cloud Composer API for, with concrete tasks.

★ Managed Airflow For ETL Pipelines

Provision a Composer environment to run Apache Airflow DAGs that orchestrate data extraction, transformation, and loading across BigQuery, Cloud Storage, and external systems. The environments.create endpoint stands up the Airflow web server, scheduler, and workers behind the scenes so platform teams skip the operational overhead of self-hosted Airflow.

Create a Composer environment named acme-prod-etl in us-central1 with node count=3 and machine type=n1-standard-2

Remote Airflow CLI Execution

Trigger DAG runs, pause DAGs, list connections, and manage variables by executing the Airflow CLI remotely against a Composer environment. The executeAirflowCommand endpoint accepts the command and arguments, returns an execution ID, and the pollAirflowCommand endpoint streams output, so CI/CD systems can manage Airflow state without SSHing into a worker.

Call executeAirflowCommand with command=dags trigger, args=[my-etl-dag], poll until exit_code is set, and return the captured stdout

Disaster Recovery Snapshots

Take a Composer environment snapshot before a major upgrade and restore from it if the upgrade fails. The saveSnapshot and loadSnapshot endpoints capture DAGs, plugins, and Airflow metadata into Cloud Storage and replay them into the same or a different environment, giving teams a clean rollback path that does not depend on hand-restoring DAG files.

Call saveSnapshot on projects/acme/locations/us-central1/environments/prod, then call loadSnapshot on a freshly-created environment with the returned snapshot URL

Database Failover For HA Composer

Trigger a manual database failover when an outage in the primary zone affects the Composer metadata database. The databaseFailover endpoint switches the active database to the standby in the secondary zone with no DAG redeploys required, which keeps long-running pipelines available during regional impairments.

Call databaseFailover on projects/acme/locations/us-central1/environments/prod and poll the operation until the failover completes

Agent-Orchestrated Pipeline Runs

An AI agent can trigger DAG runs and inspect their state through Composer's API by going through Jentic. The agent searches for 'trigger airflow dag', loads the executeAirflowCommand schema, and invokes the right CLI without learning Airflow's full command surface.

Use Jentic to call executeAirflowCommand on the prod environment with command=dags trigger and args=[customer-segmentation-dag]

Key Endpoints

21 endpoints — cloud composer is google cloud's managed apache airflow service.

METHOD

PATH

DESCRIPTION

POST

/v1/{+environment}:executeAirflowCommand

Execute an Airflow CLI command in the environment

POST

/v1/{+environment}:pollAirflowCommand

Poll the status and output of a running Airflow command

POST

/v1/{+environment}:saveSnapshot

Snapshot a Composer environment to Cloud Storage

POST

/v1/{+environment}:loadSnapshot

Restore a Composer environment from a snapshot

POST

/v1/{+environment}:databaseFailover

Trigger a manual database failover

POST

/v1/{+environment}:checkUpgrade

Check upgrade compatibility for an environment

POST

/v1/{+environment}:executeAirflowCommand

Execute an Airflow CLI command in the environment

POST

/v1/{+environment}:pollAirflowCommand

Poll the status and output of a running Airflow command

POST

/v1/{+environment}:saveSnapshot

Snapshot a Composer environment to Cloud Storage

POST

/v1/{+environment}:loadSnapshot

Restore a Composer environment from a snapshot

POST

/v1/{+environment}:databaseFailover

Trigger a manual database failover

Why Jentic?

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

Credential isolation

Your Cloud Composer 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.

Intent-based discovery

Agents search Jentic by intent such as 'run an Airflow command' or 'create a Composer environment', and Jentic returns the matching Cloud Composer operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

Time to first call

FAQs

Specific to using Cloud Composer API through Jentic.

What authentication does the Cloud Composer API use?

It uses Google OAuth 2.0 with the https://www.googleapis.com/auth/cloud-platform scope. Through Jentic the OAuth credentials are stored encrypted in your Jentic One instance and the agent only ever sees a short-lived access token at execution time.

Can I trigger an Airflow DAG run with the Composer API?

Yes. Call executeAirflowCommand with command=dags trigger and the DAG ID as the argument, then poll pollAirflowCommand for the result. This is the supported way to drive DAG runs without SSHing into a worker pod.

What are the rate limits for the Cloud Composer API?

Environment-level operations like create, update, and delete are heavily rate-limited per project because each one provisions infrastructure under the hood. Airflow command execution and polling allow much higher rates and are usually limited only by Airflow's scheduler throughput.

How do I run an Airflow command through Jentic?

Search Jentic for 'run airflow command', load the executeAirflowCommand schema, and execute the call against /v1/{environment}:executeAirflowCommand with the command and args fields. Jentic returns the schema so the agent does not need to read the Composer discovery doc.

Is the Cloud Composer API free?

Composer is billed by environment-hour and underlying resource consumption (GKE nodes, Cloud SQL, Cloud Storage). The API itself has no per-call charge but every running environment incurs cost, so dev and prod environments should be sized intentionally.

Can I snapshot and migrate a Composer environment?

Yes. Call saveSnapshot to capture DAGs, plugins, and Airflow metadata into Cloud Storage, then call loadSnapshot on the destination environment to restore. This is the canonical pattern for upgrades and cross-region migrations.

Can I limit what my agent is allowed to do with the Cloud Composer API?

Yes. Because you run Jentic One yourself, your own rules decide which Cloud Composer operations and which OAuth credential the agent may use. Since the environment resource name sits in the URL path, such as /v1/{environment}:executeAirflowCommand and /v1/{environment}:saveSnapshot, you can pin the agent to a single environment and let it run Airflow commands and save snapshots there and nothing else. You choose the exact operations it may call, so sensitive actions like loadSnapshot or databaseFailover stay off unless you explicitly allow them.

Google Cloud Composer API

Connect the Cloud Composer API to your agent

Capabilities

Start building with Cloud Composer API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs