Zones through the API

Four endpoints, under /api/v1/dns. All of them need a key with the right scope; see API keys.

The endpoints

{zone} is the zone name, not a numeric id — example.com, not 41. Names are stable and ids are not meaningful outside the platform.

Every response has the same shape

{ "ok": true, "data": { ... } }

and on failure:

{ "ok": false, "error": { ... } }

Check ok rather than the status code alone. The code tells you the class of problem; the error object tells you which one. See API errors and limits.

Listing

GET /api/v1/dns/zones

Returns your zones with their type, status, record count and sync state — the same fields the portal's zone list shows.

Creating

POST /api/v1/dns/zones
{ "name": "example.com" }

Creating a zone through the API is an ordinary zone creation: it counts against your plan's zone limit, it is delegated to the platform nameservers at birth, and it appears in the portal immediately. The API is not a way around a plan limit — a request over your cap is refused exactly as the form would be.

Fetching one

GET /api/v1/dns/zones/example.com

Useful before a change, to confirm a zone exists and is in the state you expect rather than assuming.

Deleting

DELETE /api/v1/dns/zones/example.com

⚠️ Deleting a zone stops it resolving immediately. On a plan with a recycle bin the zone is recoverable for the retention window; on the free plan it is not.

A script that deletes zones is the one worth writing carefully. Fetch first, check the name matches what you meant, and prefer an allow-list of zones your automation is permitted to touch over trusting whatever a variable held.

Related

• Records through the API
• API errors, limits and retries
• The recycle bin

Last reviewed 2026-09-16.