What registrars require before they issue a domain registration API key

Every registrar with an API publishes an endpoint reference. Almost none publishes, in the same place, what your account has to look like before those endpoints will answer you. The endpoint list is almost never the blocker. The domain registration API requirements sitting in front of it are, and they are usually documented somewhere other than the reference you are reading.

This is written for a SaaS platform that wants its own users to buy a domain inside its signup flow. Most registrar API documentation assumes a different reader, a hosting company or reseller automating its own book of business, and the two read the same endpoints with different problems. A reseller already has thousands of domains under management and a funded account, so it clears Namecheap's threshold without ever reading it. A SaaS platform wiring this up for the first time has neither, and the threshold is the whole integration.

One disclosure before anything else: we build CustomDomain, and this article lives on our blog. Every statement below about another company comes from that company's own public documentation, read in August 2026, and every vendor is linked so you can check it yourself. The last section says where we sit, including the parts we have not built.

Registering a domain and connecting one are different jobs

The word provisioning gets used for both, and they share almost no machinery.

Registering means your user does not own a domain yet. You search availability, quote a price, take payment, submit registrant contact data to a registry, and become responsible for a renewal eighteen months later. There is a legal registrant, an ICANN contact record, and money moving.

Connecting means your user already owns a domain and wants it pointed at your platform with a certificate on it. You detect where their DNS lives, write or hand over the right records, verify propagation, and issue TLS. No money moves and no registry is involved. That is what our one-click DNS setup and connect a custom domain pages describe, and what protocols like Domain Connect exist to standardize. Everything below is about the first job only.

Very little spans both. Among the products we looked at in August 2026, Entri sells through partner registrars with the purchase presented inside your product rather than as a redirect, Domainee resells at wholesale plus a flat fee, Vercel has a complete registrar API, Cloudflare has both halves as separate products with the registrar half in beta, and we cross it ourselves with a caveat of our own that the last section spells out.

Domain registration API requirements, registrar by registrar

All of this was read from each vendor's public documentation in August 2026; where we could not verify something first-hand, the section below says so. Access policies change quietly, so confirm against current docs before scoping work around this table.

Namecheap: the threshold most first integrations hit

Namecheap states the requirement plainly. From their API FAQ, read in August 2026:

have at least 20 domains under your account; have at least $50 on your account balance; have at least $50 spent within the last 2 years.

Any one of the three qualifies you, there is no additional fee for resellers using the API, and drop catching through it is not allowed. Separately, "you should whitelist at least one IP before your API access begin to work," and "only IPv4 addresses can be used."

The allowlist is the part that reaches your architecture: your egress addresses have to be stable, which rules out serverless deployments and anything behind a rotating NAT pool. That is an infrastructure decision made for you by a registrar's access policy, discovered at integration time rather than design time.

One mitigation from the same article: the sandbox is open to accounts that do not meet the production criteria, so you can build and test before you qualify. What you cannot do is go live.

GoDaddy: the credential is the trap

GoDaddy has rebuilt its developer platform, and the most expensive thing you can do is follow an old tutorial. The classic sso-key developer key is marked deprecated, supported through 2026, and their documentation states it "doesn't work for v3 endpoints." If you inherit an integration that authenticates that way, that is a rewrite rather than a config change.

The v3 API at api.godaddy.com uses bearer personal access tokens with eleven granular scopes spanning domain reads and writes, DNS, nameservers, hosts, forwarding, contacts, and transfer execution and updates. Scopes are additive, so one token can carry several.

Two account conditions sit behind the scopes. Domain management operations, meaning listing, DNS, contacts, renewals, lock and privacy, require that the account "holds at least one domain, OR is on a plan that grants management access." Anything that costs money in production requires "a valid billing method on file or a funded Good as Gold balance." A valid credential on an ineligible account is refused with a 403 and an error code that distinguishes the reason from a missing scope, which at least makes the failure diagnosable.

Rate limiting is per credential and windowed rather than per minute: as documented in August 2026, 600 requests per roughly 23-minute window, with RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset headers on every response. GoDaddy notes the specific values can change without notice.

There is no test environment. Their own words: "GoDaddy provides a single production environment for API development," and "Actions taken in production are real, billable, and often irreversible." Plan your integration tests accordingly, because your first successful registration call is a real domain and a real charge.

Porkbun: built to run unattended

Porkbun's v3.15 API is the one in this table that reads as though someone expected a machine to be driving it without supervision. Writes accept an Idempotency-Key, and retries within 24 hours replay the original response rather than charging twice. Billable or destructive writes accept dryRun: true, which rehearses price, funds and eligibility without performing the operation. Errors carry a stable code plus a next_action object, so a client can recover programmatically instead of parsing prose.

Access controls are unusually fine-grained, and it is worth separating two mechanisms that get conflated. Spend controls are per account: monthly limits, low-balance alerts, and auto top-up on API spend. Scoping is per key: a key can be restricted to specific source IPs by CIDR and to specific domains, which is how you hand an agent a least-privilege credential.

The testing story is the best here. A sandbox runs the full lifecycle against isolated fake credit, and a mock server at /mock/<path> returns schema-accurate examples with no credentials and nothing to install. GET /domain/getRegistrationRequirements/{tld} returns the create payload as JSON Schema, so per-TLD contact requirements are discoverable rather than something you learn from a rejection. They also ship a first-party MCP server via npx -y @porkbunllc/mcp-server. Porkbun is the only one here you can drive end to end without a person in the loop.

The one gap worth knowing: they publish X-RateLimit-* headers without committing to numeric limits, so you can react to throttling but cannot capacity-plan against a published figure.

Name.com and Dynadot: the least ceremony

Name.com asks for the least: an account and a token, an OpenAPI 3.1 description you can generate a client from, and a sandbox at api.dev.name.com with preloaded testing credit. The one snag is a 2FA interaction their docs call out directly, which is that an account with two-factor authentication enabled has to toggle API access on in Account Settings under Security before tokens work.

Dynadot requires enabling API access on the account. There is no eligibility threshold documented for obtaining a key; the balance requirement they state, which is to make sure you have enough account balance for your order, applies to the registration transactions themselves rather than to API access. Published guidance is that rate limits depend on your pricing level, with no numbers attached. We could not get a machine-readable spec out of Dynadot's documentation, so we are not quoting command names or action counts here. Check their page before you scope against any specific one.

Cloudflare Registrar: the longest precondition list, the narrowest surface

Cloudflare Registrar has the longest precondition list in the table and the narrowest surface behind it. What those preconditions buy you is search, availability and registration for a subset of extensions; unsupported ones return extension_not_supported_via_api from the check endpoint.

Their own documentation is direct about the state of it: "This is the first beta release of the Registrar API," and then "Renewals are not yet available through the API," "Transfers are not yet available through the API," and "Contact updates are not yet available through the API." For a platform selling domains to its users, that is the whole post-purchase lifecycle. You can register a domain programmatically and then have to renew it by hand.

We are deliberately not dating the beta. Cloudflare's own changelog entry for it carries a URL slug with one year and a published date with another, and we would rather omit the date than pick one.

Vercel: the most complete registrar API in the table

Vercel's registrar API covers more of the lifecycle than anything else here: supported TLDs, TLD price data, per-domain pricing, single and bulk availability, buy, bulk buy, order status, auth code retrieval, transfer-in, transfer status, renew, auto-renew toggling, nameserver updates, and a per-TLD contact information schema. There is an official @vercel/sdk client with a domainsRegistrar namespace. The documented prerequisite is a Vercel access token.

The caveat is commercial rather than technical: domains bought this way are registered and managed inside a Vercel account, so you are taking on a Vercel relationship whether or not you deploy there. The legacy purchase, pricing and availability endpoints have been sunset in favor of the registrar endpoints, and Vercel asks CLI users specifically to move to version 48.2.8 or later.

What the gate actually costs you

Check two things before you write code. The first is whether a sandbox exists that does not require a funded account, because that decides whether your engineers wait on procurement. Namecheap, Porkbun and Name.com all have one; the rest either document that they do not or say nothing.

The second is what the API refuses to do after registration. An API that registers a domain but cannot renew it hands you a problem eighteen months out, when a renewal your product implicitly promised has to go through a human in a console. Cloudflare's beta is the clearest current example, and it is stated on their own page rather than discovered later.

Otherwise the gate mostly costs you calendar time, and in Namecheap's case a fixed egress address as well. Buying twenty domains or funding an account is not hard, but it is a purchase order, an approval, and a wait. No reference doc mentions that wait, so put it in the estimate.

Where we sit, and what we have not built

CustomDomain does both halves in one API, and the registration half is the smaller and less finished of the two. Five registrar adapters exist in our codebase: Squarespace, IONOS, Porkbun, Name.com and Dynadot. GoDaddy is deliberately not among them, because for us GoDaddy is a DNS provider on the connection side and never a registrar. Exactly one of those five is wired into the running server, and it is Name.com. The other four are written and unit-tested and are not instantiated by the binary today.

Purchase sits behind its own kill switch, SELL_PURCHASE_ENABLED, which our shipped production compose file defaults to off. Search, suggestion and quoting work without it. Commission is a flat $5.00 on every settled registration, and it sits on top of a retail markup that defaults to 1.5 times the wholesale registrar price. The multiplier is configurable and clamped so retail is never below cost, but 1.5 is what you get if you change nothing.

The widget initiates a real purchase and creates a durable order, but the host application has to mount Stripe Embedded Checkout and call fulfill itself, because a payment UI cannot live inside a self-contained widget bundle. Buyer contact handling is minimal: name, email and country, with full ICANN and WHOIS contact handling out of scope for this cut. We also do not do registrar transfers, and four domain.transfer.* webhook events were deleted from our codebase for describing a product that does not exist in it.

The connection half is further along, and it has its own unfinished edges. We cover 63 DNS providers, of which 25 are automated (17 through provider APIs, 6 through provider OAuth, 2 through the Domain Connect protocol) and 38 are guided manual flows with automatic public-DNS verification. Apex domains resolve natively on 12 of those providers and depend on configured A records everywhere else, and where those are not configured we refuse rather than write a record the provider would reject. OAuth connections are use-once: for Cloudflare, DigitalOcean, DNSimple, Netlify, Vercel and WordPress.com a re-apply returns 409, and when records drift we send a webhook for a human to act on rather than healing it ourselves.

The same operations are in our API, which is what our custom domain API page covers: 67 paths across 79 operations, with an OpenAPI 3.1 spec served without authentication at api.customdomain.ai/v1/openapi.json, so you can generate a client before you have an account. The endpoints behind it need a key. The product is Apache-2.0 licensed and self-hostable if you would rather not have an access policy of ours to read at all.

Pricing as of August 2026 starts at $0 for 10 connections a year, then $149 and $649 per month. Since we are asking what other vendors withhold, here is ours: the $0 and $149 tiers are the DNS connection engine, the widget and SDK, the REST API, webhooks and drift detection. Automatic TLS and our reverse-proxy edge start on the $649 tier. The $0 tier is also the only one that refuses at quota.

The bottom line

If you are attaching domains your customers already own, none of this applies and the connection side is a different evaluation entirely. If you are selling domains inside your product, work the eligibility column first and the endpoint reference second, because that is the order in which they will stop you.

Two shortlists fall out of the table. If you want to build and test before anyone funds an account, Porkbun and Name.com both hand you a working sandbox on signup. If you want an integration that can run unattended, Porkbun is the only one with idempotency keys, a dry-run mode and machine-readable error recovery.

Any vendor promising both registration and connection deserves a specific question about which half is finished, us included. You can see where ours stands on the pricing page, start on the free tier at app.customdomain.ai/signup, or book a call and we will walk your registrar shortlist against it.