Cloudflare API for Safer DNS Automation

By Greg Nowak. Last updated 2026-07-09.

Cloudflare's dashboard is fine for an occasional DNS edit. The API becomes useful when DNS is part of a launch checklist, migration plan, client onboarding process, or agency handover. In those cases, the goal is not clever automation. The goal is a repeatable workflow that can be reviewed before traffic moves and understood by someone else later.

As of July 9, 2026, Cloudflare's current API documentation still supports a simple curl-and-bash approach for DNS automation. The important baseline is permissions: use scoped API tokens rather than building scripts around a broad Global API key.

Use the API when DNS needs a paper trail

Automation is worth the setup when the risk of manual clicking is higher than the cost of writing a small script. That usually means launches, repeatable environment setup, bulk client work, or a migration where the same decision may need to be checked by a developer, project manager, and site owner.

Situation	Best approach	Why it helps
One small record change	Dashboard	Fastest path when there is no repeatable process.
Launch or migration	Scripted read, review, then write	Reduces wrong-zone and wrong-record mistakes.
Agency handover	Versioned bash script with comments	Makes ownership and intent visible after the project.
Bulk zone move	Export, clean, import	Creates a rollback reference and catches old DNS debt.
CI preflight check	Read-only token	Verifies required records without granting write access.

A practical decision matrix for choosing dashboard work, API scripts, or import/export workflows.

Start with the smallest useful token

Create a token for the job, not for the person who happens to be doing the job today. For inventory and preflight checks, DNS Read is normally enough. For changes and imports, use DNS Write and restrict the token to the relevant zone wherever possible. Cloudflare also supports Account API tokens for compatible endpoints, which can be cleaner for service automation that should not be tied to one employee login.

One practical detail catches teams out: looking up a zone through GET /zones requires Zone Zone Read. If the working script only needs DNS permissions, fetch the zone ID once from the dashboard or a separate admin step, then store it in your secret manager or CI variables.

export CLOUDFLARE_API_TOKEN='...'
export ZONE_ID='...'
CF_API='https://api.cloudflare.com/client/v4'

curl --fail --silent --show-error "$CF_API/user/tokens/verify" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

A bash workflow another person can run

A dependable DNS script should do four things in order: verify the token, read the current state, make the narrowest possible change, and leave context behind. Do not start with a write call. List the relevant records first, preferably with exact filters instead of broad search behavior.

curl --fail --silent --show-error "$CF_API/zones/$ZONE_ID/dns_records?type=A&name=app.example.com" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

curl --fail --silent --show-error "$CF_API/zones/$ZONE_ID/dns_records" \
  --request POST \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{"type":"A","name":"app.example.com","content":"198.51.100.4","ttl":3600,"proxied":true,"comment":"App origin - OPS-142"}'

Comments are useful because they carry business context inside Cloudflare without changing DNS responses. A ticket number, migration note, client owner, or expiry reminder is often enough. Tags can help larger teams group records, but comments are the low-friction habit to establish first.

Keep Cloudflare's record rules close to the script. A and AAAA records cannot share a name with a CNAME. NS records cannot share a name with any other record type. For TTL, 1 means automatic; otherwise the normal range is 60 to 86400 seconds, with 30 seconds available on Enterprise zones.

Treat imports like migrations, not uploads

For a real DNS migration, import and export endpoints are often more valuable than individual record calls. Export first, keep the file with the change request, clean the source zone file, and import only after someone has reviewed the records that will become active.

curl --fail --silent --show-error "$CF_API/zones/$ZONE_ID/dns_records/export" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --output zone-export.txt

curl --fail --silent --show-error "$CF_API/zones/$ZONE_ID/dns_records/import" \
  --request POST \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --form "file=@your_formatted_file.txt"

Cloudflare's current limits matter in production planning: zone files are capped at 256 KiB, and the import/export API limit is three requests per minute per user. If an import fails, read the parsing error instead of retrying blindly.

Zone-file formatting deserves a quiet review. Targets for records such as CNAME, MX, NS, PTR, and SRV should be fully qualified names with a trailing period. Cloudflare supports $ORIGIN, $TTL, and $GENERATE, but not $INCLUDE. If proxy state matters, use Cloudflare's reserved cf-proxied:true or cf-proxied:false tags in the zone file so the import does not guess.

What maintainable DNS automation looks like

For a single site, a few well-named curl commands may be enough. For a business or agency handling multiple zones, make the workflow boring on purpose: obvious inputs, scoped tokens, readable output, and no secrets in the script body.

Keep token and zone IDs in a proper secret store.
Use read-only tokens for checks and write tokens only for approved changes.
Version the script and sample input files.
Put ticket or owner context in record comments.
Export before imports so rollback has a known starting point.

If DNS changes keep showing up during launches, migrations, or client handovers, a small Cloudflare API workflow can remove a lot of avoidable risk. For help turning that into a clean operating process, talk with Greg about a safer DNS automation setup.

Related on GrN.dk

Need help with this kind of work?

Talk with Greg about DNS automation Get in touch with Greg.

Sources

Last modified

2026-07-09