If you only touch DNS a few times a year, Cloudflare's dashboard is enough. The API starts paying for itself when DNS is part of launches, migrations, CI, client handovers, or repeatable agency work. In those cases, the real value is not just speed. It is control: fewer manual clicks, clearer approvals, and a workflow another person can take over without guesswork.
The original idea behind this page still holds up: bash can be perfectly adequate for managing Cloudflare DNS, including BIND zone imports. What has changed is the baseline for doing it safely. As of April 24, 2026, Cloudflare's current docs steer teams toward scoped API tokens rather than broad legacy API keys, and that is the right place to start.
When the Cloudflare API is worth using
- Bulk DNS changes during a migration, replatform, or launch.
- Repeatable client work across several domains or environments.
- Ops handovers where you need a readable change trail instead of dashboard clicks.
- Simple CI or deployment checks for records that must exist before traffic moves.
If that sounds familiar, a small API workflow is usually enough. You do not need to overengineer it. You need something safe, predictable, and easy for the next person to understand.
Start with the smallest safe access
Use zone-scoped API tokens where possible. For read-only inventory or preflight checks, DNS Read is enough. For record changes or imports, use DNS Write. If automation is shared across a team or CI system, Cloudflare now also supports Account API tokens for compatible endpoints, which is useful when you do not want a production workflow tied to one person's login.
One practical detail many teams miss: if you want to discover a zone ID through the zones API, that endpoint requires Zone Zone Read. For locked-down automation, I usually fetch the zone ID once from the dashboard, store it securely, and keep the working token limited to DNS permissions for that specific zone.
export CLOUDFLARE_API_TOKEN="..."
export ZONE_ID="..."
curl "https://api.cloudflare.com/client/v4/user/tokens/verify" \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"If you do need to look up the zone through the API, this is the simplest pattern:
curl "https://api.cloudflare.com/client/v4/zones?name=example.com" \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"Useful bash calls that still make sense
Before changing anything, list the current records. That confirms you are in the right zone and gives you a quick snapshot for review. Cloudflare's DNS records endpoint is also a good fit for pre-change checks in CI because it can run with read-only permissions.
curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"For a straightforward record add, the API is often easier to review than a series of dashboard clicks. Cloudflare's current API still supports record comments, and I would use them every time. A ticket reference, environment label, or migration note makes later audits much easier.
curl "https://api.cloudflare.com/client/v4/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"}'A few record-model rules are worth remembering because they are a common cause of failed imports and confusing errors. A or AAAA records cannot share the same hostname with a CNAME, and NS records cannot exist on the same name as any other record type. Cloudflare also treats ttl: 1 as automatic; otherwise explicit TTL values are generally 60 to 86400 seconds, with lower minimums only on Enterprise plans.
Importing a BIND zone file into Cloudflare
If your real goal is moving an existing zone, Cloudflare still supports BIND-style imports through the API. That keeps the older bash-based approach relevant. What I would change is the process around it: export first, review the source zone file, then import with a token that only has access to the target zone.
curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/export" \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
--output zone-export.txt
curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/import" \
--request POST \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
--form "file=@your_formatted_file.txt"Cloudflare's current DNS docs list a 256 KiB zone-file limit and an API limit of three import or export requests per minute per user. That matters if you are batching migrations or testing several import attempts in quick succession. A failed upload should usually trigger review, not brute-force retries.
The zone file itself is where many migration mistakes happen. For CNAME, DNAME, MX, NS, PTR, and SRV records, Cloudflare expects the target value to be a fully qualified domain name with a trailing period, such as example.com.. It supports $ORIGIN, $TTL, and $GENERATE, but not $INCLUDE. If your existing DNS setup relies on included files, flatten them before import.
If proxy behavior matters per record, do not rely on defaults blindly. Cloudflare's docs note that cf-proxied:true or cf-proxied:false tags inside the zone file take precedence during import. That is useful when only some records should sit behind Cloudflare and others should remain DNS-only.
What a maintainable setup looks like
For a single site, a few curl commands may be enough. For a company with multiple environments, or an agency managing several client zones, I would standardize a small wrapper around the API and keep it boring. The winning pattern is usually simple:
- Verify the token and target zone.
- Read the current state before changing it.
- Apply one narrow change or one reviewed import.
- Use record comments so another person knows why the change exists.
- Keep the commands or script in version control, even if it is only a short bash file.
That gives you a workflow an operations lead can approve, a developer can automate, and an agency can hand over cleanly. It also avoids the usual failure mode of DNS automation: a clever script that saves five minutes once and costs hours later because nobody trusts it.
If you only change one or two records a year, the dashboard may still be the cheaper tool. The API earns its keep when repeatability, auditability, and handover matter more than raw speed. If you want that workflow set up properly without turning DNS management into a bigger project than it needs to be, Greg can help.
Talk with Greg about a safer Cloudflare DNS workflow if you need help with launches, migrations, or client handovers.
Need help with this kind of work?
Need a safer Cloudflare DNS workflow for launches, migrations, or client handovers? Talk with Greg. Get in touch with Greg.