> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# ClickHouse Cloud API
> Learn about ClickHouse Cloud API
Overview
The ClickHouse Cloud API is a REST API designed for developers to easily manage
organizations and services on ClickHouse Cloud. Using our Cloud API, you can
create and manage services, provision API keys, and add or remove members in your
organization, and more.
[Learn how to create your first API key and start using the ClickHouse Cloud API.](/products/cloud/features/admin-features/api/openapi)
Swagger (OpenAPI) Endpoint and UI
The ClickHouse Cloud API is built on the open-source [OpenAPI specification](https://www.openapis.org/)
to allow for predictable client-side consumption. If you need to programmatically
consume the ClickHouse Cloud API docs, we offer a JSON-based Swagger endpoint
via [https://api.clickhouse.cloud/v1](https://api.clickhouse.cloud/v1). You can also find the API docs via
the [Swagger UI](/products/cloud/api-reference/organization/get-list-of-available-organizations).
If your organization has been migrated to one of the [new pricing plans](https://clickhouse.com/pricing?plan=scale\&provider=aws\®ion=us-east-1\&hours=8\&storageCompressed=false), and you use OpenAPI you will be required to remove the `tier` field in the service creation `POST` request.
The `tier` field has been removed from the service object as we no longer have service tiers.\
This will affect the objects returned by the `POST`, `GET`, and `PATCH` service requests. Therefore, any code that consumes these APIs may need to be adjusted to handle these changes.
Rate limits
Developers are limited to 100 API keys per organization. Each API key has a
limit of 10 requests over a 10-second window. If you'd like to increase the
number of API keys or requests per 10-second window for your organization,
please contact [support@clickhouse.com](mailto:support@clickhouse.com)
The official ClickHouse Terraform Provider lets you use [Infrastructure as Code](https://www.redhat.com/en/topics/automation/what-is-infrastructure-as-code-iac)
to create predictable, version-controlled configurations to make deployments much
less error-prone.
You can view the Terraform provider docs in the [Terraform registry](https://registry.terraform.io/providers/ClickHouse/clickhouse/latest/docs).
If you'd like to contribute to the ClickHouse Terraform Provider, you can view
the source [in the GitHub repo](https://github.com/ClickHouse/terraform-provider-clickhouse).
If your organization has been migrated to one of the [new pricing plans](https://clickhouse.com/pricing?plan=scale\&provider=aws\®ion=us-east-1\&hours=8\&storageCompressed=false), you will be required to use our [ClickHouse Terraform provider](https://registry.terraform.io/providers/ClickHouse/clickhouse/latest/docs) version 2.0.0 or above. This upgrade is required to handle changes in the `tier` attribute of the service since, after pricing migration, the `tier` field is no longer accepted and references to it should be removed.
You will now also be able to specify the `num_replicas` field as a property of the service resource.
ClickHouse maintains two official Terraform providers - the ClickHouse Cloud provider for cloud infrastructure and the DBops provider for database-level objects. Both follow the same release model.
GA versus Beta resources
Every release is a single build that contains all resources. Resources for features that have not yet reached general availability ship alongside GA ones, marked as **beta** — there is no separate build and nothing to pin to use them.
A beta resource announces itself in two places:
* **At plan and apply time**, as a `Beta Resource` warning. Terraform never fails on warnings, so the run proceeds normally.
* **In its documentation**, with a callout reading "This resource is in beta".
Beta means the schema and behavior may change in a future provider version. Anything without the marker is GA and covered by the usual compatibility guarantees.
Before v3.25.2, the provider marked these resources as *alpha* rather than *beta*, and the plan-time warning read `Alpha Resource`. Only the wording changed — no schema, behavior, or state migration is involved — but tooling that greps plan output for `Alpha Resource` will silently stop matching. Earlier releases also published a separate alpha build.
Versioning
Both providers use semantic versioning (MAJOR.MINOR.PATCH). The major version is incremented for breaking changes, the minor version for new features or resources, and the patch version for bug fixes. Releases are cut on demand rather than on a fixed schedule.
Versions with an `-alphaN` suffix (e.g., `3.15.0-alpha3`) predate the single-build model. They remain available but are no longer produced.
When a feature reaches general availability, its resource drops the beta marker in the next provider release: the plan-time warning stops appearing, and the docs callout is removed. Nothing else changes — no configuration edits, no state migration, and no switching between builds.
The number of replicas each service will be created with defaults to 3 for the Scale and Enterprise tiers, while it defaults to 1 for the Basic tier.
For the Scale and the Enterprise tiers it is possible to adjust it by passing a `numReplicas` field in the service creation request.
The value of the `numReplicas` field must be between 2 and 20 for the first service in a warehouse. Services that are created in an existing warehouse can have a number of replicas as low as 1.
Support
We recommend visiting [our Slack channel](https://clickhouse.com/slack) first to get quick support. If
you'd like additional help or more info about our API and its capabilities,
please contact ClickHouse Support at [https://console.clickhouse.cloud/support](https://console.clickhouse.cloud/support)