Every API here is available over the APIs.io API and to AI agents over MCP.
openapi: 3.2.0
info:
title: Confluent Cloud Clusters (srcm/v3) API
version: ''
x-api-id: 46234552-5833-42eb-ba0f-883ad3f70d2b
x-audience: external-public
x-logo:
url: https://assets.confluent.io/m/1661ef5e4ff82d3d/
description: "# Introduction\n\n<div class=\"status-info\">\n<p class=\"status-info-title\">Note</p>\nThis documents the collection of Confluent Cloud APIs. Each API documents its\n<a href=\"#api-lifecycle-policy\">lifecycle phase</a>. APIs\nmarked as Early Access or Preview are not ready for production usage. We're currently\nworking with a select group of customers to get feedback and iterate on these APIs.\n</div>\n\nConfluent Cloud APIs are a core building block of Confluent Cloud. You can use the APIs to\nmanage your own account or to integrate Confluent into your product.\n\nMost of the APIs are organized around\n<a href=\"http://en.wikipedia.org/wiki/Representational_State_Transfer\" target=\"_blank\">REST</a>\nand the resources which make up Confluent Cloud. The APIs have predictable\nresource-oriented URLs, transport data using JSON, and use standard HTTP verbs,\nresponse codes, authentication, and design principles.\n\n## Object Model\n\n<div class=\"status-info\">\n<p class=\"status-info-title\">Note</p>\nThis section describes the object model for many Confluent Cloud APIs, but not all.\nThe Connect v1 API group has a different object model. You can review the example\nrequest and response bodies in <a href=\"../ccloud/connectors-connect-v-1/\">Connect v1 API</a>\nto see its object model.\n</div>\n\nConfluent Cloud APIs are primarily designed to be declarative and intent-oriented. In other words,\ntell the API what you want (for example, throughput or SLOs) and it will figure out how to make it happen\n(for example, cluster sizing). A Confluent object acts as a \"record of intent\" — after you create the\nobject, Confluent Cloud will work tirelessly in the background to ensure that the object exists\nas specified.\n\nConfluent APIs represent objects in JSON with media-type `application/json`.\n\nMany objects follow a model consisting of `spec` and `status`. An object's `spec` tells\nConfluent the _desired state_ (specification) of the resource. The object may not be\nimmediately available or changes may not be immediately applied. For this reason,\nmany objects also have a `status` property that provides info about the\n_current state_ of the resource. Confluent Cloud is continuously and actively managing\neach resource's current state to match it's desired state.\n\nAll Confluent objects share a set of common properties:\n\n- **api_version** – API objects have an `api_version` field indicating their API version.\n- **kind** – API objects have a `kind` field indicating the kind of object it is.\n- **id** – Each object in the API will have an identifier, indicated via its `id` field,\n and should be treated as an opaque string unless otherwise specified.\n\nThere are a number of other [standard properties](#standard-properties) and that you'll encounter\nused by many API objects. And of course, objects have plenty of non-standard fields that are\nspecific to each object _kind_... this is what makes them interesting!\n\n# Authentication\n\nConfluent uses API keys and JSON Web Tokens (JWTs) to integrate your applications\nand workflows to your Confluent Cloud resources using the Confluent Cloud REST APIs.\nYour applications and workflows must be authenticated and authorized in order to\naccess and manage Confluent Cloud resources.\n\n## API keys\n\nYou can create and manage your API keys using the Confluent Cloud Console or\nConfluent CLI. For more information, see [Use API Keys to Control Access in Confluent Cloud](https://docs.confluent.io/cloud/current/access-management/authenticate/api-keys/api-keys.html).\n\nConfluent Cloud uses the following two categories of API keys:\n\n- A **Cloud API key** grants access to the Confluent Cloud Management APIs,\n such as for Provisioning and Metrics integrations.\n- A **resource-specific API key** grants access to a Confluent Kafka cluster\n (Kafka API key), a Confluent Cloud Schema Registry (Schema Registry API key),\n Flink (Flink API key scoped to an Environment + Region pair), or a ksqlDB application.\n\nEach Confluent Cloud API key is associated with a principal (specific user or\nservice account) and inherits the permissions granted to the owner.\n\n- For example, if service account `Armageddon` is granted ACLs on Kafka cluster\n `neptune`, then a Kafka API Key for `neptune` owned by `Armageddon` will have\n these ACLs enforced.\n- **Note:** API keys are automatically deleted when the associated user or service\n account is deleted (for example, when an employee leaves the company or moves to\n a new department and an SSO integration removes the Confluent Cloud user as they\n no longer require access).\n- Confluent **strongly recommends** that you use service accounts for all\n production-critical access.\n\nConfluent Cloud API keys grant access to Confluent Cloud resources, so **keep them secure**!\nDo not share your API keys and secrets in publicly-accessible locations, such as\nGitHub or client-side code.\n\nAll API requests must be made over HTTPS. Calls made over plain HTTP will fail.\nAPI requests without authentication will also fail.\n\nTo use an API key, you must send it in an `Authorization: Basic {credentials}` header.\nRemember that HTTP Basic authentication requires you to provide your credentials as\nthe API key ID and associated API secret separated by a colon and encoded using Base64\nformat. For example, if your API key ID is `ABCDEFGH123456789` and the API key Secret\nis `XNCIW93I2L1SQPJSJ823K1LS902KLDFMCZPWEO`, then the authorization header is:\n\n```text\nAuthorization: Basic QUJDREVGR0gxMjM0NTY3ODk6WE5DSVc5M0kyTDFTUVBKU0o4MjNLMUxTOTAyS0xERk1DWlBXRU8=\n```\n\nYou can generate this header example from the API key:\n\nmacOS:\n\n```shell\n$ echo -n \"ABCDEFGH123456789:XNCIW93I2L1SQPJSJ823K1LS902KLDFMCZPWEO\" | base64\n\n```\n\nLinux:\n\n```shell\n$ echo -n \"ABCDEFGH123456789:XNCIW93I2L1SQPJSJ823K1LS902KLDFMCZPWEO\" | base64 -w 0\n```\n\nWindows (PowerShell only):\n\nThis command is only supported for PowerShell and will not work in the Command shell. \n\n```shell\n$ [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes(\"ABCDEFGH123456789:XNCIW93I2L1SQPJSJ823K1LS902KLDFMCZPWEO\"))\n```\n\nTo find out if an API operation supports Cloud API Keys, look in the **AUTHORIZATIONS**\nlisting for `cloud-api-key`.\n\nTo find out if an API operation supports resource-specific API Keys, look in the **AUTHORIZATIONS**\nlisting for `resource-api-key`.\n\n## External OAuth\n\nYou can use [OAuth/OIDC support for Confluent Cloud](https://docs.confluent.io/cloud/current/access-management/authenticate/oauth/overview.html)\nto authenticate and authorize access to applications and workloads for the\nfollowing Confluent Cloud REST APIs:\n\n- **Kafka REST API**: [Kafka REST API for Clusters(V3)](../ccloud/cluster-v-3/).\n For an API overview and examples, see [Cluster Management with Kafka REST API](https://docs.confluent.io/cloud/current/kafka-rest/kafka-rest-cc.html).\n- **Schema Registry REST API**: [Schema Registry REST API for Schemas(V1)](../ccloud/schemas-v-1/)\n and [Subjects](../ccloud/subjects-v-1/).\n For an API overview and examples, see [Schema Registry REST API for Confluent Cloud](https://docs.confluent.io/cloud/current/sr/sr-rest-apis.html).\n\nAlternatively, to find out if an API operation supports external tokens, look in the **AUTHORIZATIONS**\nlisting for `external-access-token`.\n\n## Confluent STS tokens\n\nConfluent Security Token Service (STS) issues access tokens (`confluent-sts-access-token`)\nby exchanging an external token (`external-access-token`) for a `confluent-sts-access-token`. You can use\nConfluent STS tokens to authenticate to Confluent Cloud APIs that support the\n`confluent-sts-access-token` notation.\n\nTo find out if an API operation supports Confluent STS tokens, look in the **AUTHORIZATIONS**\nlisting for `confluent-sts-access-token`.\n\n## Partner OAuth\n\nApproved partners can fetch Partner tokens (`confluent-partner-access-token`) that validate their identity\nand grant access to the Partner API (`partner/v2`), which lets them sign up\nan organization on behalf of a customer, manage entitlements (create, read, and list),\nand read or list organizations they have signed up.\n\nTo find out an API operation supports Partner tokens, look in the **AUTHORIZATIONS**\nlisting for `confluent-partner-access-token`.\n\n<!-- TODO: port this back to the Confluent API Design Guide -->\n\n<SecurityDefinitions />\n\n# Errors\n\nConfluent API error messages are a critical part of the developer experience. For Confluent Cloud, they must be\nclear, consistent, actionable, and designed for both developers and automated systems. Strong error\nhandling supports fast troubleshooting, reliable integration, and efficient support–the foundation of\na positive developer experience.\n\nOur APIs are built on RESTful principles. They use resource-oriented URLs, standard HTTP verbs, and JSON\nfor requests and responses. This section defines clear standards for structuring, formatting, and documenting\nerror messages for all Confluent REST APIs.\n\n<div class=\"status-info\">\n<p class=\"status-info-title\">Note</p>\nThis error format applies to most Confluent Cloud APIs. However, the Connect v1 API group uses a different structure. For Connect v1-specific error behavior and examples, refer to the Connect v1 API documentation <a href=\"../ccloud/connectors-connect-v-1/\">below</a> to see its error behavior.\n</div>\n\n## Key principles\n\nUse the following best practices when designing and documenting API error messages:\n\n- **Ensure clarity and consistency**: Messages must be easy to understand–use active voice and plain language–and consistently formatted across endpoints.\n\n- **Write actionable messages**: Always include a resolution or next step, enabling users to correct the problem.\n\n- **Avoid exposing sensitive data**: Never expose internal system details, stack traces, logs, or user-specific content.\n\n- **Follow industry best practices**: Don't use a period at the end of the message field, even if it is a full sentence. This follows industry standards. Use periods in the details and suggestion fields if the content is a complete sentence. View the [API best practices blog](#status-codes) by Postman, a trusted API leader.\n\n## HTTP status codes\n\nConfluent Cloud APIs return standard [HTTP status codes](#status-codes) to\nindicate the outcome of API request. Each error response includes a `status` field that reflects the appropriate HTTP code as a string (for example, `\"403\"` or `\"404\"`).\nFor a list of supported codes and their meaning, see the [HTTP status codes](#status-codes) section.\n\n## Error response structure\n\nEach API error response **should** include the following fields:\n\n**Top-level fields**\n\n| Field | Type | Required | Description |\n| ------------ | ------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| status | String | Yes | HTTP status code (for example, 400, 404, 500). |\n| error | Object | Yes | Main object containing error details. |\n| requestId | String | Optional | Unique identifier for the API request. Use for tracing, debugging, and support inquiries. |\n| doc_url | String | Optional | Link to relevant documentation or troubleshooting steps. |\n\n**Fields inside `error` object**\n\n| Field | Type | Required | Description |\n| ------------| ------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| code | String | Yes | Unique, application-specific error code. Write error codes in uppercase letters, using underscores to separate words (for example, RESOURCE_NOT_FOUND). |\n| message | String | Yes | Clear, actionable, user-friendly description of what went wrong using active voice. |\n| details | String | Optional | Additional explanation or context about the error using active voice. |\n| timestamp | String | Yes | ISO 8601 UTC timestamp indicating the date and time when the error occurred. |\n| path | String | Yes | The exact API endpoint or resource path related to the error. |\n| suggestion | String | Optional | Recommend actions the user can take to fix or avoid the error using active voice. |\n\nEach Confluent API error includes a status and a structured error object with a code, message, and optional context to help you understand and resolve the issue. The following example\nshows a standard Confluent API error response in JSON format:\n\n {\n \"status\": 400,\n \"error\": {\n \"code\": \"INVALID_SCHEMA_FIELD\",\n \"message\": \"The 'name' field in the schema is required and cannot be empty.\",\n \"details\": \"Schemas must include a top-level 'name' field with a non-empty string value.\",\n \"timestamp\": \"2025-08-01T20:36:45Z\",\n \"path\": \"/api/v1/schemas\",\n \"suggestion\": \"Ensure the 'name' field is included in the payload and is not an empty string.\"\n },\n \"requestId\": \"a1b2c3d4-e5f6-7890-g1h2-i3j4k516m7n8\",\n \"doc_url\": \"https://docs.confluent.io/cloud/current/api/errors/INVALID_SCHEMA_FIELD.html\"\n }\n\nNote that if a request fails validation, it will return an HTTP `422 Unprocessable Entity`\nwith a list of fields that failed validation.\n\n## Pagination\n\n<div class=\"status-info\">\n<p class=\"status-info-title\">Note</p>\nThis section describes the pagination behavior of “list” operations for many Confluent Cloud APIs, but not all.\nThe Connect V1 and Kafka V3 API list operations do not support pagination.\n</div>\n\nAll API resources have support for bulk reads via \"list\" API operations. For example,\nyou can \"list Kafka clusters\", \"list api keys\", and \"list environments\". These \"list\"\noperations require pagination; by requesting smaller subsets of data, API clients\nreceive a response much faster than requesting the entire, potentially large, data set.\n\nAll \"list\" operations follow the same pattern with the following parameters:\n\n- `page_size` – client-provided max number of items per page, only valid on the first request.\n- `page_token` – server-generated token used for traversing through the result set.\n\nA paginated response may include any of the following pagination links. API clients may\nfollow the respective link to page forward or backward through the result set as desired.\n\n| [Link Relation](https://www.iana.org/assignments/link-relations/link-relations.xml) | Description |\n| ----------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `next` | A link to the next page of results. A response that does not contain a next link does not have further data to fetch. |\n| `prev` | A link to the previous page of results. A response that does not contain a prev link has no previous data. This link is **optional** for collections that cannot be traversed backward. |\n| `first` | A link to the first page of results. This link is **optional** for collections that cannot be indexed directly to a given page. |\n| `last` | A link to the last page of results. This link is **optional** for collections that cannot be indexed directly to a given page. |\n\nAPI clients must treat pagination links and the `page_token` parameter in particular as an opaque string.\n\nAn example paginated list response may look like\n\n```\n{\n \"api_version\": \"v2\",\n \"kind\": \"KafkaClusterList\",\n \"metadata\": {\n \"next\": \"https://api.confluent.cloud/kafka-clusters?page_token=ABCDEFGHIJKLMNOP1234567890\"\n }\n \"data\": [\n {\n \"metadata\": {\n \"id\": \"lkc-abc123\",\n \"self\": \"https://api.confluent.cloud/kafka-clusters/lkc-abc123\",\n \"resource_name\": \"crn://confluent.cloud/kafka=lkc-abc123\",\n }\n \"spec\": {\n \"display_name\": \"My Kafka Cluster\",\n <snip>\n },\n \"status\": {\n \"phase\": \"RUNNING\",\n <snip>\n }\n },\n <snip>\n ]\n}\n```\n\n# Rate Limiting\n\nTo protect the stability of the API and keep it available to all users, Confluent employs\nmultiple safeguards. If you send too many requests in quick succession or perform too many\nconcurrent operations, you may be throttled or have your request rejected with an error.\n\nWhen a rate limit is breached, an HTTP `429 Too Many Requests` error is\nreturned. The following headers are sent back to provide assistance in dealing\nwith rate limits. Note that headers are not returned for a `429` error response with\n[Kafka REST API (v3)](../ccloud/cluster-v-3/).\n\n| Header | Description |\n| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `X-RateLimit-Limit` | The maximum number of requests you're permitted to make per time period. |\n| `X-RateLimit-Reset` | The relative time in seconds until the current rate limit window resets. |\n| `Retry-After` | The number of seconds to wait until the rate limit window resets. Only sent when the rate limit is reached. |\n| `X-RateLimit-Remaining` | The number of requests remaining in the current rate-limit window. **Important:** This differs from Github and Twitter\\'s same-named header which uses UTC epoch seconds. We use relative time to avoid client/server time synchronization issues. |\n\nConfluent enforces multiple kinds of limits, including request-rate and concurrency limits, both per user and organization-wide. Unauthenticated requests are associated with the originating IP address, not the user making requests.\n\nIntegrations should gracefully handle these limits by watching for `429` error responses and\nbuilding in a retry mechanism. This mechanism should follow a capped exponential backoff policy to\nprevent [retry amplification](https://landing.google.com/sre/sre-book/chapters/addressing-cascading-failures/)\n(\"retry storms\") and also introduce some randomness (\"jitter\") to avoid the\n[thundering herd effect](https://en.wikipedia.org/wiki/Thundering_herd_problem).\n\nRate limits are generally fixed and cannot be increased. If you require higher\nthroughput, you can use a Dedicated cluster, where certain limits scale\nautomatically with the number of CKUs. For example, each additional CKU\nincreases the Kafka REST Produce v3 connection limit by 300 requests per\nsecond. For reference, see the\n[eCKU/CKU comparison table](https://docs.confluent.io/cloud/current/clusters/cluster-types.html#ecku-cku-comparison).\n\nIf you’re running into this error and think you need a higher rate limit, contact Confluent at\n[support@confluent.io](mailto:support@confluent.io).\n\n# Identifiers and URLs\n\nMost resources have multiple identifiers:\n\n- `id` is the \"natural identifier\" for an object. It is only unique within its parent resource.\n The `id` is unique across time: the ID will not be reclaimed and reused after an object is deleted.\n- `resource_name` is a Uniform Resource Identifier (URI) that is globally unique across all resources.\n This encompasses all parent resource `kind`s and `id`s necessary to uniquely identify a particular\n instance of this object `kind`. Because it uses object `id`s, the CRN will not be reclaimed and\n reused after an object is deleted. It is represented as a Confluent Resource Name (see below).\n- `self` is a Uniform Resource Locator (URL) at which an object can be addressed.\n This URL encodes the service location, API version, and other particulars necessary to\n locate the resource at a point in time.\n\nTo see how these relate to each other, consider `KafkaBroker` with `broker.id=2` in a `KafkaCluster`\nin Confluent Cloud identified as `lkc-xsi8201`. In such an example, the `KafkaBroker` has `id=2`,\nthe `resource_name` is `crn://confluent.cloud/kafka=lkc-xsi8201/broker=2` and the `self` URL may be\nsomething like `https://pkc-8wlk2n.us-west-2.aws.confluent.cloud`. Note that different identifiers\ncarry different information for different purposes, but the `resource_name` is the most complete\nand canonical identifier.\n\n## Confluent Resource Names (CRNs)\n\n_Confluent Resource Names_ (CRNs) are used to uniquely identify all Confluent resources.\n\nA CRN is a valid URI having an \"authority\" of `confluent.cloud` or a self-managed\n<a href=\"https://docs.confluent.io/current/security/rbac/configure-mds/index.html\" target=\"_blank\">\nmetadata service URL</a>, followed by the minimal hierarchical set of key-value\npairs necessary to uniquely identify a resource.\n\nHere are some examples for basic resources in Confluent Cloud:\n\n| Resource | Example CRN |\n| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| Organization | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a |\n| Environment | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/environment=env-456xy |\n| User | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/user=u-rst9876 |\n| API Key | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/user=u-zyx98/api-key=ABCDEFG9876543210 |\n| Service Account | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/service-account=sa-abc1234 |\n| Kafka Cluster | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/environment=env-456xy/cloud-cluster=lkc-123abc/kafka=lkc-123abc |\n| Kafka Topic | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/environment=env-456xy/cloud-cluster=lkc-123abc/kafka=lkc-123abc/topic=my_kafka_topic |\n| Consumer Group | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/environment=env-456xy/cloud-cluster=lkc-123abc/kafka=lkc-123abc/group=confluent_cli_consumer_123 |\n| Network | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/environment=env-456xy/network=n-123abc |\n| Peering | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/environment=env-456xy/network=n-123abc/peering=p-123abc |\n| Private Link Access | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/environment=env-456xy/network=n-123abc/private-link-access=pla-123abc |\n| Transit Gateway Attachment | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/environment=env-456xy/network=n-123abc/transit-gateway-attachment=tgwa-123abc |\n| Schema Registry Cluster | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/environment=env-456xy/schema-registry=lsrc-789qw |\n| Schema Subject | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/environment=env-456xy/schema-registry=lsrc-789qw/subject=test |\n| KEK | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/environment=env-456xy/schema-registry=lsrc-789qw//kek=test_kek |\n| Connector | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/environment=env-456xy/cloud-cluster=lkc-123abc/connector=my_datagen_connector |\n| Provider Integration | crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/environment=env-456xy/provider-integration=cspi-123j1 |\n\n# Data Types\n\n## Primitive Types\n\n| Data Type | Representation |\n| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Integers | Each API may specify the type as `int32` or `int64`. Note that many languages, including JavaScript, are limited to a max size of approx `2**53` and don't correctly handle large `int64` values with their default JSON parser. |\n| Dates | <a href=\"https://www.ietf.org/rfc/rfc3339.txt\" target=\"_blank\">RFC 3339</a> formatted string. UTC timezones are assumed, unless otherwise given. |\n| Times | <a href=\"https://www.ietf.org/rfc/rfc3339.txt\" target=\"_blank\">RFC 3339</a> formatted string. UTC timezones are assumed, unless otherwise given. |\n| Durations | <a href=\"https://www.ietf.org/rfc/rfc3339.txt\" target=\"_blank\">RFC 3339</a> formatted string. |\n| Periods | <a href=\"https://www.ietf.org/rfc/rfc3339.txt\" target=\"_blank\">RFC 3339</a> formatted string. UTC timezones are assumed, unless otherwise given. |\n| Ranges | All ranges are represented using half-open intervals with naming conventions like `[start_XXX, end_XXX)` such as `[start_time, end_time)`. |\n| Enums | Most APIs use <a href=\"https://opensource.zalando.com/restful-api-guidelines/#112\" target=\"_blank\">`x-extensible-enum`</a> as an open-ended list of values. This improves compatibility compared with a standard `enum` which by definition represents a closed set. All enums have a `0`-valued entry which either serves as the default for common cases, or represents `UNSPECIFIED` when no default exists and results in an error. |\n\n<!-- TODO\n### Standard Objects\n\n| Money Object | https://schema.org/MonetaryAmount or https://opensource.zalando.com/restful-api-guidelines/#173\n| Price Specification | https://schema.org/PriceSpecification -> https://schema.org/UnitPriceSpecification and https://schema.org/PaymentChargeSpecification\n-->\n\n### Standard Properties\n\nConfluent uses this set of standard properties to ensure common concepts use\nthe same name and semantics across different APIs.\n\n| Name | Description |\n| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------
# --- truncated at 32 KB (83 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/confluent/refs/heads/main/openapi/confluent-clusters-srcm-v3-api-openapi.yml