Reference · built on requestConnectorStreams, queues & webhooks

Confluent Cloud

Records, topics, consumer lag, clusters, and managed connectors from Confluent Cloud through its Kafka REST and management APIs.

Request accessPricing ↗

About

Confluent Cloud is Confluent's hosted Apache Kafka service. An organization holds environments, and each environment holds Kafka clusters of type Basic, Standard, Enterprise, Dedicated, or Freight, plus Schema Registry, ksqlDB, and Flink resources. Management goes through api.confluent.cloud: Org API v2, Cluster Mgmt for Kafka v2, Identity Access Management v2, and Connect API v1. Each Kafka cluster also has its own REST endpoint for Kafka REST API v3, and Metrics APIs sit at api.telemetry.confluent.cloud.

Through Fibric, an operator reads records and consumer lag from a cluster and the state of its managed connectors. It proposes a produce, a topic change, or a connector change. You approve. The connector makes one call and leaves a receipt.

This is a reference listing. It documents what Fibric would read from Confluent Cloud and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Records from topics, consumed through Kafka REST API v3 or with a Kafka client connected to the cluster
  • Topics, cluster and topic configuration, and ACLs listed through Kafka REST API v3
  • Consumer groups, consumers, and consumer lag through Kafka REST API v3, which the docs note for Dedicated clusters
  • Environments, Kafka clusters, service accounts, and API keys through Org API v2, Cluster Mgmt for Kafka v2, and Identity Access Management v2
  • Fully managed connector status through Connect API v1
  • Schema subjects and versions through Schema Registry API v1

Proposed actions

  • Target capability: propose producing a record through Kafka REST Produce v3 on the cluster's REST endpoint
  • Target capability: propose creating or deleting a topic, or changing a topic configuration, through Kafka REST API v3
  • Target capability: propose creating or reconfiguring a fully managed connector through Connect API v1
  • Target capability: propose adding an ACL for a service account through Kafka REST API v3

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Know when a managed connector stops

    The operator polls Connect API v1 for connector state. When a sink to your warehouse fails or pauses, it reports the connector and the topic it was draining, and proposes the next step for your approval.

    With Integration Health

  • Watch consumer lag before reports go stale

    Lag on a consumer group grows past what you set. The operator names the group, the cluster, and the topics behind it before a dashboard reads old data.

    With Data Freshness

  • Flag cluster growth against your plan

    The operator reads cluster type and configuration from Cluster Mgmt for Kafka v2 and reports when a Basic or Standard cluster approaches the capacity its type allows.

    With Quota Headroom, Cost Anomaly

Requirements

  • A Confluent Cloud organization with an environment and at least one Kafka cluster
  • A service account holding a Cloud resource management API key for the management APIs
  • A Kafka cluster API key scoped to the environment and cluster, for Kafka REST API v3 and client access
  • The cluster's REST endpoint, in the form https://pkc-xxxxx.region.provider.confluent.cloud:443
  • For schema reads, a Schema Registry API key scoped to the environment's Schema Registry cluster
Authentication
HTTP Basic Auth with a Cloud API key (key ID as username, secret as password) for management APIs and a resource-specific Kafka cluster or Schema Registry API key for data APIs, or OAuth/OIDC tokens for Kafka REST and Schema Registry.

Limits

  • A breached rate limit returns HTTP 429 with X-RateLimit-Limit, X-RateLimit-Reset, and Retry-After headers
  • Compressed records cannot be sent to the Kafka REST Produce API
  • Basic clusters do not support RBAC roles for resources inside the cluster and run one task per connector. Freight clusters do not support transactions
  • Each user or service account may hold only two global API keys, and the count of API keys is bounded by service quotas

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Confluent Cloud ↗

Questions and answers

Which API key does the connector use for which call?
A Cloud API key, bound to a user or service account, authenticates the management APIs at api.confluent.cloud. A Kafka cluster API key authenticates Kafka REST API v3 on that cluster's REST endpoint. A Schema Registry API key authenticates Schema Registry API v1. Each is sent as HTTP Basic Auth.
Can records be read and written over HTTP?
Yes. Kafka REST API v3 produces records and consumes from topics on the cluster's REST endpoint, in addition to listing topics, configuration, ACLs, and consumer group lag. Compressed records cannot be sent to the Produce endpoint.
How does Confluent Cloud signal a rate limit?
With an HTTP 429 Too Many Requests response carrying X-RateLimit-Limit, X-RateLimit-Reset, and Retry-After headers. The connector waits for the reset before retrying. Limits differ by cluster type.
Ask about Confluent Cloud

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Confluent Cloud through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy