Confluent Cloud APIs are a core building block of Confluent Cloud. You can use the APIs to manage your own account or to integrate Confluent into your product.

Most of the APIs are organized around REST and the resources which make up Confluent Cloud. The APIs have predictable resource-oriented URLs, transport data using JSON, and use standard HTTP verbs, response codes, authentication, and design principles.

Confluent Cloud APIs are primarily designed to be declarative and intent-oriented. In other words, tell the API what you want (e.g., throughput or SLOs) and it will figure out how to make it happen (e.g., cluster sizing). A Confluent object acts as a "record of intent" — after you create the object, Confluent Cloud will work tirelessly in the background to ensure that the object exists as specified.

Confluent APIs represent objects in JSON with media-type application/json.

Many objects follow a model consisting of spec and status. An object's spec tells Confluent the desired state (specification) of the resource. The object may not be immediately available or changes may not be immediately applied. For this reason, many objects also have a status property that provides info about the current state of the resource. Confluent Cloud is continuously and actively managing each resource's current state to match it's desired state.

All Confluent objects share a set of common properties:

• api_version – API objects have an api_version field indicating their API version.
• kind – API objects have a kind field indicating the kind of object it is.
• id – Each object in the API will have an identifier, indicated via its id field, and should be treated as an opaque string unless otherwise specified.

There are a number of other standard properties and that you'll encounter used by many API objects. And of course, objects have plenty of non-standard fields that are specific to each object kind... this is what makes them interesting!

Confluent uses API keys for integrating with Confluent Cloud. Integrations must be authorized and authenticated before they can access or manage resources in Confluent Cloud. You can manage your API keys in the Confluent Cloud Dashboard or Confluent Cloud CLI. See the docs for details on creating and managing API keys.

Today, you can divide API keys into two classes:

• Cloud API Keys – These grant access to the Confluent Cloud Control Plane APIs, such as for Provisioning and Metrics integrations.
• Cluster API Keys – These grant access to a single Confluent cluster, such as a specific Kafka or Schema Registry cluster.

An API key is owned by a User or Service Account and inherits the permissions granted to the owner.

• For example, if service account Armageddon is granted ACLs on Kafka Cluster neptune, then a Cluster API Key for neptune owned by Armageddon will have these ACLs.
• Note 1: ACLs aren't currently enforced for users, only service accounts.
• Note 2: API Keys are automatically deleted when the owning user or service account is deleted (e.g., an employee leaves the company, or moves to a new department and an SSO integration removes their user in Confluent Cloud as they no longer require access)
• Confluent strongly recommend that you use service accounts for all production-critical access.

Your API keys carry many privileges, so be sure to keep them secure! Do not share your API keys in publicly accessible areas such as GitHub, client-side code, and so forth.

All API requests must be made over HTTPS. Calls made over plain HTTP will fail. API requests without authentication will also fail.

To use your API key, send it as an Authorization: Basic {key} header. Remember that HTTP Basic authorization requires you to colon-separate and base64 encode your key. For example, if your API Key ID is ABCDEFGH123456789 and the corresponding API Key Secret is XNCIW93I2L1SQPJSJ823K1LS902KLDFMCZPWEO, then the authorization header will be

Authorization: Basic QUJDREVGR0gxMjM0NTY3ODk6WE5DSVc5M0kyTDFTUVBKU0o4MjNLMUxTOTAyS0xERk1DWlBXRU8=

This example header can be generated from the API key (on Mac OS X) with

$ echo -n "ABCDEFGH123456789:XNCIW93I2L1SQPJSJ823K1LS902KLDFMCZPWEO" | base64

Confluent uses conventional HTTP status codes to indicate the success or failure of an API request.

Failures follow a standard model to tell you about what went wrong. They may include one or more error objects with the following fields:

* indicates a required field

All errors include an id and some detail message. The id is a unique identifier — use it when you're working with Confluent support to debug a problem with a specific API call. The detail describes what went wrong.

Some errors that could be handled programmatically (e.g., a Kafka cluster config is invalid) may include an error code that briefly explains the error reported.

Validation issues and similar errors include a source which tells you exactly what in the request was responsible for the error.

For example, a failure may look like

{
  "errors": [{
    "status": "422",
    "code": "invalid_configuration",
    "id": "30ce6058-87da-11e4-b116-123b93f75cba",
    "title": "The Kafka cluster configuration is invalid",
    "detail": "The property '/cluster/storage_size' of type string did not match the following type: integer",
    "source": {
      "pointer": "/cluster/storage_size"
    }
  }]
}

If a request fails validation, it will return an HTTP 422 Unprocessable Entity with a list of fields that failed validation.

All API resources have support for bulk reads via "list" API operations. For example, you can "list Kafka clusters", "list api keys", and "list environments". These "list" operations require pagination; by requesting smaller subsets of data, API clients receive a response much faster than requesting the entire, potentially large, data set.

All "list" operations follow the same pattern with the following parameters:

• page_size – client-provided max number of items per page, only valid on the first request.
• page_token – server-generated token used for traversing through the result set.

A paginated response may include any of the following pagination links. API clients may follow the respective link to page forward or backward through the result set as desired.

API clients must treat pagination links and the page_token parameter in particular as an opaque string.

An example paginated list response may look like

{
    "api_version": "v2",
    "kind": "KafkaClusterList",
    "metadata": {
        "next": "https://api.confluent.cloud/kafka-clusters?page_token=ABCDEFGHIJKLMNOP1234567890"
    }
    "data": [
        {
            "metadata": {
                "id": "lkc-abc123",
                "self": "https://api.confluent.cloud/kafka-clusters/lkc-abc123",
                "resource_name": "crn://confluent.cloud/kafka=lkc-abc123",
            }
            "spec": {
                "display_name": "My Kafka Cluster",
                <snip>
            },
            "status": {
                "phase": "RUNNING",
                <snip>
            }
        },
        <snip>
    ]
}

To protect the stability of the API and keep it available to all users, Confluent employs multiple safeguards. If you send too many requests in quick succession or perform too many concurrent operations, you may be throttled or have your request rejected with an error.

When a rate limit is breached, an HTTP 429 Too Many Requests error is returned.

Integrations should gracefully handle these limits by watching for 429 error responses and building in a retry mechanism. This mechanism should follow a capped exponential backoff policy to prevent retry amplification ("retry storms") and also introduce some randomness ("jitter") to avoid the thundering herd effect.

If you’re running into this error and think you need a higher rate limit, contact Confluent at support@confluent.io.

Most resources have multiple identifiers:

• id is the "natural identifier" for an object. It is only unique within its parent resource. The id is unique across time: the ID will not be reclaimed and reused after an object is deleted.
• resource_name is a Uniform Resource Identifier (URI) that is globally unique across all resources. This encompasses all parent resource kinds and ids necessary to uniquely identify a particular instance of this object kind. Because it uses object ids, the CRN will not be reclaimed and reused after an object is deleted. It is represented as a Confluent Resource Name (see below).
• self is a Uniform Resource Locator (URL) at which an object can be addressed. This URL encodes the service location, API version, and other particulars necessary to locate the resource at a point in time.

To see how these relate to each other, consider KafkaBroker with broker.id=2 in a KafkaCluster in Confluent Cloud identified as lkc-xsi8201. In such an example, the KafkaBroker has id=2, the resource_name is crn://confluent.cloud/kafka=lkc-xsi8201/broker=2 and the self URL may be something like https://pkc-8wlk2n.us-west-2.aws.confluent.cloud. Note that different identifiers carry different information for different purposes, but the resource_name is the most complete and canonical identifier.

Confluent Resource Names (CRNs) are used to uniquely identify all Confluent resources.

A CRN is a valid URI having an "authority" of confluent.cloud or a self-managed metadata service URL, followed by the minimal hierarchical set of key-value pairs necessary to uniquely identify a resource.

Here are some examples for basic resources in Confluent Cloud:

Primitive Types

Standard Properties

Confluent uses this set of standard properties to ensure common concepts use the same name and semantics across different APIs.

Confluent APIs ensure stability for your integrations by avoiding the introduction of breaking changes to customers unexpectedly. Confluent will make non-breaking API changes without advance notice. Thus, API clients must follow the Compatibility Policy below to ensure your ingtegration remains stable. All APIs follow the API Lifecycle Policy described below, which describes the guarantees API clients can rely on.

Breaking changes will be widely communicated in advance in accordance with the Confluent Deprecation Policy. Confluent will provide timelines and a migration path for all API changes, where available. Be sure to subscribe to one or more communication channels so you don't miss any updates!

One exception to these guidelines is for critical security issues. Confluent will take any necessary actions to mitigate any critical security issue as soon as possible, which may include disabling the vulnerable functionality until a proper solution is available.

Do not consume any Confluent API unless it is documented in the API Reference. All undocumented endpoints should be considered private, subject to change without notice, and not covered by any agreements.

Note: The version in the URL (e.g. "v1" or "v2") is not a "major version" in the Semantic Versioning sense. It is a "generational version" or "meta version", as seen in APIs like Github API or the Stripe API.

During the Early Access and Preview periods, we have a few known issues.

The following status labels are applicable to APIs, features, and SDK versions, based on the current support status of each:

• Early Access – May change at any time. Not recommended for production usage. Not officially supported by Confluent. Intended for user feedback only. Users must be granted explicit access to the API by Confluent.
• Preview – Unlikely to change between Preview and General Availability. Not recommended for production usage. Officially supported by Confluent for non-production usage. For Closed Previews, users must be granted explicit access to the API by Confluent.
• Generally Available (GA) – Will not change at short notice. Recommended for production usage. Officially supported by Confluent for non-production and production usage.
• Deprecated – No longer supported. Will be removed in the future at the announced date. Use is discouraged and migration following the upgrade guide is recommended.
• Sunset – Removed, and no longer supported or available.

Resources, operations, and individual fields in the OpenAPI spec will be annotated with x-lifecycle-stage, x-deprecated-at, and x-sunset-at. These annotations will appear in the corresponding API Reference Documentation. An API is "Generally Available" unless explicitly marked otherwise.

Confluent Cloud APIs are governed by Confluent Cloud Upgrade Policy, which means that backward incompatible changes and deprecations will be made approximately once per year, and 180 days notice will be provided via email to all registered Confluent Cloud users.

Backward Compatibility

An API version is backward compatible if a program written against the previous version of the API will continue to work the same way, without modification, against this version of the API.

Confluent considers the following changes to be backward compatible:

• Adding new API resources.
• Adding new optional parameters to existing API requests (e.g., query string).
• Adding new properties to existing API resources (e.g., request body).
• Changing the order of properties in existing API responses.
• Changing the length or format of object IDs or other opaque strings.
  • Unless otherwise documented, you can safely assume object IDs generated by Confluent will never exceed 255 characters, but you should be able to handle IDs of up to that length. If you're using MySQL, for example, you should store IDs in a VARCHAR(255) COLLATE utf8_bin column.
  • This includes adding or removing fixed prefixes (such as lkc- on Kafka cluster IDs).
  • This includes API keys, API tokens, and similar authentication mechanisms.
  • This includes all strings described as "opaque" in the docs, such as pagination cursors.
• Adding new API event types.
• Adding new properties to existing API event types.
• Omitting properties with null values from existing API responses.

Forward Compatibility

An API version is forward compatible if a program written against the next version of the API will continue to work the same way, without modification, against this version of the API.

In other words, a forward compatible API will accept input intended for a later version of itself.

Confluent does not guarantee the forward compatibility of the APIs, but Confluent does generally follow the guidelines given by the Robustness principle. This means that the API determines what to do with a request based only on the parts that it recognizes.

This is often referred to as the MUST IGNORE rule.

• Request parameters that are not recognized will be ignored (e.g., query string).
• Request properties that are not recognized will be ignored (e.g., request body).
• Request metadata that are not recognized will be ignored (e.g., request headers).

API clients must also follow the MUST IGNORE rule.

• Response properties that are not recognized must be ignored (e.g., response body).
• Response metadata that are not recognized must be ignored (e.g., response headers).

Additionally, there is a more subtle related rule called the MUST FORWARD rule. Any parts of a request that an API doesn't recognize must be forwarded unchanged.

• Response properties that are not recognized must be included in any input subsequent updates (e.g., request body)
  • This includes future PUT requests in a read/modify/write operation. (This isn't required for PATCH partial updates, which is why Confluent APIs use PATCH.)
• Event processors must not strip unknown properties before forwarding messages.

Client Responsibilities

• Resource and rate limits, and the default and maximum sizes of paginated data are not considered part of the API contract and may change (possibly dynamically). It is the client's responsibility to read the road signs and obey the speed limit.
• If a property has a primitive type and the API documentation does not explicitly limit its possible values, clients must not assume the values are constrained to a particular set of possible responses.
• If a property of an object is not explicitly declared as mandatory in the API, clients must not assume it will be present.
• A resource may be modified to return a "redirection" response (e.g. 301, 307) instead of directly returning the resource. Clients must handle HTTP-level redirects, and respect HTTP headers (e.g. Location).

Confluent will announce deprecations at least 180 days in advance of a breaking change and will continue to maintain the deprecated APIs in their original form during this time.

Exceptions to this policy apply in case of critical security vulnerabilities or functional defects.

Communication

When a deprecation is announced, the details and any relevant migration information will be available on one or more of the following channels:

• Lifecycle, deprecation and "since" annotations in the OpenAPI spec
• Announcements on the Developer Blog, Community Slack (join!), Google Group, the @ConfluentInc twitter account, and similar channels
• Enterprise customers may receive information by email to their specified Confluent contact, if applicable.

Confluent respects the meanings and behavior of HTTP status codes as defined in RFC2616 and elsewhere.

• Codes in the 2xx range indicate success
• Codes in the 3xx range indicate redirection
• Codes in the 4xx range indicate an error caused by the client request (e.g., a required parameter was omitted, an invalid cluster configuration was provided, etc.)
• Codes in the 5xx range indicate an error with Confluent's servers (these are rare)

The various HTTP status codes that might be returned are listed below.

This list is not exhaustive; other standard HTTP error codes may be used, including 304, 307, 308, 405, 406, 408, 410, and 415.

For more details, see https://httpstatuses.com.

Environment objects represent an isolated namespace for your Confluent resources for organizational purposes.

The API allows you to create, delete, and update your environments. You can retrieve individual environments as well as a list of all your environments.

Related guide: Environments in Confluent Cloud.

This resource is subject to the following quotas:

User objects represent individuals who may access your Confluent resources.

The API allows you to retrieve, update, and delete individual users, as well as list of all your users. This API cannot be used to create new user accounts.

Related guide: Users in Confluent Cloud.

This resource is subject to the following quotas:

ServiceAccount objects are typically used to represent applications and other non-human principals that may access your Confluent resources.

The API allows you to create, retrieve, update, and delete individual service accounts, as well as list all your service accounts.

Related guide: Service Accounts in Confluent Cloud.

This resource is subject to the following quotas:

Clusters objects represent Apache Kafka Clusters on Confluent Cloud.

The API allows you to list, create, read, update, and delete your Kafka clusters.

Related guide: Confluent Cloud Cluster Management for Apache Kafka APIs.

This resource is subject to the following quotas:

API for managing connectors.

The API allows you to list, create, get, update and delete your connectors.

Connect metrics are available through Metrics v2 API.

Related guide: Connectors in Confluent Cloud.

API for managing lifecycle of connectors. Operations currently supported are Pause and Resume.