canonical: https://jentic.com/apis/confluent.io/confluent

# Confluent Cloud API

Jentic publishes the only available OpenAPI specification for Confluent Cloud API, keeping it validated and agent-ready. The Confluent Cloud REST API lets developers and AI agents provision and manage Apache Kafka clusters, topics, service accounts, API keys, role bindings, connectors, and organization settings on Confluent's managed Kafka platform. It exposes 68 endpoints across IAM, Kafka, Connect, Cluster Management, and Organization resource groups. Authentication is HTTP Basic with a Cloud API key/secret pair, or OAuth 2.0 Bearer tokens for federated access.

## For AI agents

Provision and manage Confluent Cloud Kafka clusters, topics, service accounts, role bindings, and connectors. Useful for agents that automate streaming infrastructure provisioning and access control.

## Scope

Does not handle Kafka topic publish/consume traffic, schema registry data plane reads, or ksqlDB query execution - use for Confluent Cloud control-plane management only.

## Capabilities

- Provision a Cloud API key for a service account so a workload can publish to Kafka
- Invite a new user into a Confluent Cloud organization with a scoped role
- Create a service account and bind it to an environment-scoped role
- List role bindings to audit who has admin or writer access on a cluster
- Manage Connect cluster resources for source and sink connectors
- Read cluster management resources to confirm a cluster is in the running state
- Rotate or revoke an existing Cloud API key after an offboarding event

## Use cases

### Provision Streaming Workload Credentials

When a new microservice needs to publish to Kafka, an agent calls POST /iam/v2/service_accounts to create a service account and POST /iam/v2/api_keys to mint a Cloud API key bound to that account. The key is then handed to the workload's secret manager. This replaces a multi-hour manual provisioning ticket with a self-service flow that finishes in under a minute.

Example prompt: Call POST /iam/v2/service_accounts with display_name ingest-pipeline, then POST /iam/v2/api_keys with that service account ID and store the returned key/secret in the deployment secret store.

### Access Audit and Right-Sizing

Pull every role binding in an organization to answer who has access to which environment or cluster. The agent calls GET /iam/v2/role_bindings, joins the result against GET /iam/v2/users and GET /iam/v2/service_accounts, and produces a CSV of principal, role, and resource. This is the same evidence package most SOC 2 auditors ask for, generated on demand instead of through manual screenshots.

Example prompt: Page through GET /iam/v2/role_bindings and join with GET /iam/v2/users to produce a confluent-rbac-2026-q2.csv with columns principal_email, role, crn_pattern.

### Onboarding and Offboarding Automation

Tie Confluent Cloud user lifecycle to your IdP. On hire, an agent calls POST /iam/v2/invitations with the new user's email and the appropriate role. On termination, the agent looks up the user via GET /iam/v2/users and DELETEs them along with any API keys that have them as the owner. This keeps Kafka access in line with the rest of the identity perimeter without an admin clicking through the cloud console.

Example prompt: On termination of user 12345, call GET /iam/v2/api_keys?spec.owner=u-12345, DELETE each returned key, then DELETE /iam/v2/users/12345.

### AI Agent Cluster Operations via Jentic

Let an SRE assistant answer Confluent Cloud questions and take simple actions in chat. The agent searches Jentic for create confluent cloud API key, loads the operation schema, and executes it with the Cloud API key/secret kept in your Jentic One instance. The same wrapper covers IAM, role bindings, and cluster reads, so the assistant becomes a thin layer over the Confluent Cloud control plane.

Example prompt: Through Jentic, search create confluent cloud API key, load the POST /iam/v2/api_keys schema, and execute it for service account sa-ingest in the production environment.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /iam/v2/api_keys | Create a Cloud API key |
| GET | /iam/v2/api_keys | List Cloud API keys |
| POST | /iam/v2/service_accounts | Create a service account |
| POST | /iam/v2/invitations | Invite a user to the organization |
| GET | /iam/v2/role_bindings | List role bindings for audit |
| POST | /iam/v2/role_bindings | Grant a role binding |
| DELETE | /iam/v2/api_keys/{api_key_id} | Revoke a Cloud API key |

## Key resources

- **ApiKeys** — Mint, rotate, and revoke Cloud API keys bound to users or service accounts
- **ServiceAccounts** — Manage non-human identities used by workloads connecting to Kafka
- **Users** — Read and update human user records inside the organization
- **Invitations** — Invite new users into the Confluent Cloud organization
- **RoleBindings** — Grant and audit role assignments on environments, clusters, and resources
- **Cluster Management** — Read cluster state and configuration
- **Connect** — Manage connector and Connect cluster resources
- **Organization** — Read organization-level metadata

## Why Jentic

- **Setup:** Wiring the Confluent Cloud API by hand means learning its basic and bearer auth, mapping its IAM control-plane resources, and handling API key, service account, and role binding calls yourself. Through Jentic you install once, import the Confluent Cloud API from the API Directory, store the credentials once, and your agent calls it.
- **Permission scoping:** Confluent Cloud puts the API key id in the URL path (/iam/v2/api_keys/{api_key_id}), so a rule can pin your agent to acting on a specific API key. You choose the operations it may call, so you can allow reading API keys and role bindings while leaving API key deletion out unless you add it.
- **Credential handling:** Your Confluent Cloud credentials are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a Confluent Cloud API key' or 'list role bindings', and Jentic returns the matching Confluent operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Aiven API** — Aiven offers managed Kafka alongside Postgres, OpenSearch, and other open-source data services
- **Upstash API** — Upstash provides serverless Kafka and Redis with per-request pricing
- **AWS EventBridge** — AWS EventBridge is the AWS event bus often used alongside Confluent in hybrid architectures

## FAQ

### Why is there no official OpenAPI spec for Confluent Cloud API?

Confluent does not publish a single OpenAPI specification covering the cloud control plane. Jentic generates and maintains this spec so that AI agents and developers can call Confluent Cloud API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Confluent Cloud API use?

Two schemes are supported: HTTP Basic with a Cloud API key as the username and the secret as the password, or OAuth 2.0 Bearer tokens for federated access. Through Jentic the credential is held in the vault and never enters the agent's prompt.

### Can I create and rotate Cloud API keys via the API?

Yes. POST /iam/v2/api_keys mints a new key bound to a user or service account, GET /iam/v2/api_keys lists existing keys, and DELETE /iam/v2/api_keys/{api_key_id} revokes one. This is the supported path for automated rotation.

### Can I invite users to my Confluent Cloud organization through the API?

Yes. POST /iam/v2/invitations creates an invitation for an email address and assigns an organization-level role. The invitee then accepts via the standard Confluent Cloud sign-up flow.

### How do I audit role bindings across my organization?

Page through GET /iam/v2/role_bindings, which returns role bindings as principal, role_name, crn_pattern triples. Join with GET /iam/v2/users and GET /iam/v2/service_accounts to resolve principal emails or display names for the report.

### How do I provision Confluent Cloud resources through Jentic?

Run pip install jentic, then await client.search('create confluent cloud API key'), load the matching operation schema, and execute it. The underlying call is POST /iam/v2/api_keys with the service account ID you target at runtime.

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

Yes. Because you run Jentic One yourself, your own rules decide which Confluent Cloud operations and credentials the agent may use, so you can let it call read operations like GET /iam/v2/role_bindings and GET /iam/v2/api_keys while leaving DELETE /iam/v2/api_keys/{api_key_id} out unless you explicitly add it. Since the API key id sits in the URL path, a rule can also pin the agent to acting on a single API key rather than every key in the organization. The stored credentials are injected only at execution time and never enter the agent's prompt.