Why manage Cloudflare through the API and Terraform

With a single site on the account, it's fine to change Cloudflare settings by hand in the Dashboard. Once there are ten or more domains, and cache and firewall rules need to be repeated on each of them, manual clicking becomes a source of drift between zones.

The API and Terraform solve this with code: the same DNS record or rule is described once and applied to the needed zones with a command instead of a series of tab clicks. Changes show up in the git history, not just in Cloudflare's audit log.

When the plain API is enough, and when Terraform is needed

The choice depends on whether it's a one-off task or a repeatable configuration that must be kept up to date.

Task	REST API	Terraform
One-off record change	A single curl request, simplest option	Overkill for one edit
Same setup across 20 zones	Needs a custom script with a loop	One module for all zones
Tracking changes	Only through the Dashboard Audit Log	A git diff before every apply

First API request: token and verification

Create a token in the Dashboard under My Profile → API Tokens with Zone:Edit permission for one specific zone, not a global Account API Key. Check the token with a single request:

curl -X GET "https://api.cloudflare.com/client/v4/user/tokens/verify" \
  -H "Authorization: Bearer $CF_API_TOKEN"

A response with status active confirms the token works, and you can move on to changing DNS records or cache rules, covered in the article on DNS records and Proxy mode.

The Terraform provider for Cloudflare: basic setup

The official provider is connected with three lines in the configuration, after which Terraform can create and update Cloudflare resources the same way it handles cloud provider resources.

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 4.0"
    }
  }
}

provider "cloudflare" {
  api_token = var.cf_api_token
}

Example: a DNS record and a cache rule as code

The cloudflare_record resource describes a DNS record, and cloudflare_ruleset describes a cache or firewall rule using the same syntax as the rest of the infrastructure:

resource "cloudflare_record" "app" {
  zone_id = var.zone_id
  name    = "app"
  type    = "A"
  content = "203.0.113.10"
  proxied = true
}

After editing the file, run terraform plan to see which records will change, then terraform apply to push them to all listed zones at once.

The state file and common mistakes

The main source of trouble isn't the provider itself, but how the state file and token permissions are handled:

the state file stores resource values in plain text — never commit it to a public repository
for a team, keep the state in a remote backend rather than on one laptop
a token with Zone:Edit rights over every zone on the account is riskier than a single-zone token
a manual edit in the Dashboard after apply creates drift — Terraform will revert it on the next apply

Summary: where to start automating

The API fits one-off scripts and integrations, while Terraform fits configuration that needs to be repeated across many zones and kept under version control.

create an API token scoped only to the zones you need, not an Account API Key
connect the cloudflare/cloudflare provider at the needed version
move into code the DNS records and rules from Cache Rules and WAF Custom Rules
set up a remote backend for the state file
check plan before every apply, never apply changes blindly

Managing Cloudflare through the API and Terraform, no clicks