Domain registration and DNS: the agent answers

I’d use **OpenSRS** if the domains are being registered for customers and are intended to belong to them.

It is built as a wholesale/reseller platform, with APIs covering the full domain lifecycle—availability, registration, renewal, contacts, transfers, DNS, and expiration handling—and supports 700+ TLDs. That matters more here than finding the absolute cheapest `.com`. [OpenSRS API overview](https://opensrs.com/integrations/api/) and [pricing/TLD coverage](https://opensrs.com/domains/pricing/).

My architecture would be:

- OpenSRS for registration and lifecycle management.
- Cloudflare DNS for authoritative DNS, using one isolated zone per customer and narrowly scoped API tokens.
- Your own database and job state machine as the source of truth; registrar operations are asynchronous and must be reconciled.
- ACME DNS-01 or your edge provider’s managed-certificate system for TLS.
- Customer self-service for renewal, transfer-out, ownership/contact changes, and domain removal.

The most important product decision is who legally owns the domain:

- If the customer owns it, register using their accurate registrant data and use a reseller-oriented provider such as OpenSRS. Build email-verification and TLD-specific requirements into onboarding.
- If your company owns it and merely licenses its use, say that very clearly. Customers otherwise reasonably assume “their domain” is portable. This model also leaves you responsible for renewals, disputes, abuse reports, and offboarding.

What else I considered:

- **AWS Route 53 Domains:** My runner-up, and potentially the simplest choice if you already live in AWS and the domains remain company assets. Its mature API can register a domain, create the hosted zone, assign nameservers, enable auto-renew, and apply privacy protection automatically. It supports lifecycle operations through normal AWS IAM and SDKs. Downsides are retail rather than reseller positioning, hosted-zone/query charges, no premium-name registration, and customer ownership/transfer workflows that you must build yourself. [RegisterDomain API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_domains_RegisterDomain.html) and [operational limitations](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-register.html).

- **Cloudflare Registrar:** Extremely attractive economically—registration and renewal are sold at registry/ICANN cost—and Cloudflare DNS is excellent. But its programmatic registration API is currently beta, supports only a subset of extensions, and does not yet expose API renewals, transfers, or contact updates. Premium registrations are also unsupported. Furthermore, Cloudflare-registered domains must use Cloudflare nameservers. I would test it, but not make it the only production registrar until those lifecycle gaps close. [Registrar API and beta limitations](https://developers.cloudflare.com/registrar/registrar-api/), [at-cost pricing](https://developers.cloudflare.com/registrar/), and [nameserver restriction](https://developers.cloudflare.com/registrar/get-started/register-domain/).

- **Gandi:** A credible alternative with domain, contact, billing, and LiveDNS APIs. I would evaluate it if European contracting/data handling or specific ccTLD coverage dominates. It is less explicitly shaped around an embedded reseller product than OpenSRS. [Gandi domain API](https://api.gandi.net/docs/domains/).

- **Namecheap:** It exposes registration and DNS APIs, but the API design is older, including IP allowlisting and record-set-style DNS operations. It would not be my first choice for a high-volume backend integration. [Namecheap registration API](https://www.namecheap.com/support/api/methods/domains/create/).

One more distinction: customers who already own a custom domain should normally keep it at their registrar. Ask them to delegate a subdomain or create a verification record and CNAME/ALIAS toward your service. Only use the registrar purchasing workflow when you are genuinely procuring a new domain for them.

Before committing, I’d run a short proof of concept covering registration, duplicate retries, delayed registry completion, contact verification, renewal failure, redemption, transfer-out, DNSSEC, abuse suspension, and at least every ccTLD you intend to sell. The happy-path `registerDomain()` call is the easy part; lifecycle and ownership are what determine whether the integration survives production.

I’d use **Openprovider as the registrar**, with **Cloudflare as the authoritative DNS provider**.

Openprovider is designed for reseller/platform use: its API covers availability, pricing, registration, renewals, transfers, contacts, DNSSEC, nameservers, and lifecycle management. That is a better fit than automating a retail registrar account. Its API also exposes the actual price before committing to a billable registration. [Openprovider API documentation](https://docs.openprovider.com/doc/all)

Cloudflare would handle the DNS zones and records because its DNS API, propagation, security controls, and scoped API tokens are strong. Keeping registrar and DNS separate also limits the blast radius of either account being compromised.

### What I considered

| Option | Verdict | Why |
|---|---|---|
| **Openprovider** | Best production fit | Reseller-oriented, broad lifecycle API, wholesale pricing options, DNSSEC and contact management. |
| **AWS Route 53 Domains** | Best simple alternative | Mature registration API, more than 350 TLDs, automatic hosted-zone creation, renewals, privacy, and operation tracking. Particularly attractive if everything already runs in AWS. [Registration API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_domains_RegisterDomain.html) |
| **Cloudflare Registrar** | Not yet for this use case | Its new API is convenient and domains are sold at cost, but it is still beta: only some TLDs work through the API, renewals/transfers/contact changes are not yet exposed, accounts are currently limited to 100 registered domains, and domains must use Cloudflare nameservers. [API limitations](https://developers.cloudflare.com/registrar/registrar-api/) |
| **Gandi** | Viable, less compelling | Capable domain and LiveDNS APIs, but generally not my first choice on cost or reseller economics. [Domain API](https://api.gandi.net/docs/domains/) |
| **Namecheap/Porkbun-style retail APIs** | Fine for small internal portfolios | Often inexpensive, but access restrictions, prefunding, limits, and weaker reseller/lifecycle workflows make them less attractive for a customer-facing product. |

If this is an AWS-native product with perhaps tens—not thousands—of domains, I might choose **Route 53 Domains alone** to minimize moving parts. Its `RegisterDomain` operation creates a hosted zone and assigns its nameservers automatically. DNS hosting is billed separately, though, so per-zone charges become material at scale. [Route 53 Domains](https://aws.amazon.com/route53/domains/)

### The important product distinction

A “custom domain” normally means the customer already owns `customer.com`. You should not register anything in that flow. Give them:

1. A TXT record for ownership verification.
2. A CNAME, ALIAS, or A/AAAA record pointing at your service.
3. Automated TLS certificate issuance and renewal.
4. Continuous verification so an abandoned domain cannot remain attached to another tenant.

Treat “buy a domain through us” as a separate feature. That makes you a registrar reseller and introduces registrant agreements, ownership, renewal, transfer, expiry, abuse, privacy, and tax/support obligations. ICANN requires registered-name holders to enter into a registration agreement, and reseller arrangements inherit specific contractual requirements. [ICANN registrar and reseller policies](https://www.icann.org/en/contracted-parties/accredited-registrars/resources/agreements-and-policies)

Also, “nobody at the keyboard” cannot be guaranteed for every TLD. Registrant-email verification, registry-specific eligibility checks, premium-domain approval, and occasional manual review can still occur. AWS explicitly warns that unverified registrant email can result in suspension; the same underlying ICANN requirement affects other registrars. [AWS verification guidance](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-register.html)

My production design would therefore be:

- Openprovider for registration and lifecycle.
- Cloudflare DNS zones created through the API.
- Customer recorded as the legal registrant unless your product explicitly leases domains.
- Your company as technical contact where permitted.
- Auto-renew on, with a funded balance and expiry monitoring independent of the registrar.
- A registration state machine rather than a synchronous request: `quoted → authorized → registering → verification-required → active/failed`.
- Price caps and explicit handling for premium domains.
- Webhook polling reconciliation, idempotency keys, audit logs, scoped credentials, and alerts at 60/30/14/7 days before expiry.
- At least two supported providers behind an internal registrar interface if domains are business-critical.

I’d use **Openprovider for registration**, with **Cloudflare as authoritative DNS**.

Openprovider is built for the actual business model here: a SaaS company embedding domain sales into its product. Its API supports registration, renewal, transfer, contacts, DNSSEC, and DNS across 2,000+ TLDs, with an isolated sandbox and reseller/white-label support. That matters more than saving a dollar on individual registrations. [Openprovider’s API overview](https://developers.openprovider.com/)

For DNS, I’d create a Cloudflare zone, obtain its assigned nameservers, register the domain through Openprovider with those nameservers, and manage records through Cloudflare’s API.

A key distinction:

- If customers already own the custom domain, don’t register anything. Give them a CNAME/TXT verification flow and automate certificate issuance.
- Use the registrar integration only when your product is actually selling or provisioning a new domain for them.

What else I considered:

- **Cloudflare Registrar:** The most attractive simple option. Its API now supports availability, real-time pricing, and unattended registration, while domains are sold at registry cost. But the registration API is still documented as beta; programmatic TLD coverage is narrower, premium registrations and IDNs aren’t supported, and domains are permanently tied to Cloudflare nameservers while registered there. I’d use it if you support a small, controlled TLD list and are comfortable being Cloudflare-only. [Registrar API](https://developers.cloudflare.com/registrar/registrar-api/), [restrictions](https://developers.cloudflare.com/registrar/get-started/register-domain/)

- **Amazon Route 53 Domains:** Operationally dependable and particularly convenient if everything already lives in AWS. Registration automatically creates a hosted zone, and the SDK/API lifecycle is solid. Downsides are higher ongoing DNS cost, limited premium-domain support, and a product model aimed more at infrastructure owners than embedded domain resale. [RegisterDomain API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_domains_RegisterDomain.html)

- **Porkbun:** Its current API is pleasantly modern and supports programmatic registration, DNS, per-TLD registration schemas, and an OpenAPI specification. It would be my lightweight alternative, but I’d want written confirmation about reseller terms, production limits, abuse handling, and support expectations before building a customer-facing domain business on it. [Porkbun API](https://porkbun.com/api/json/v3/documentation)

- **OpenSRS/Tucows:** Mature and explicitly designed for resellers, with broad registry experience. Still worth an enterprise evaluation, especially at significant volume, but its integration surface is more legacy-heavy than Openprovider’s REST/OpenAPI approach. [OpenSRS domains API](https://www.opensrs.com/wp-content/uploads/api_domains.pdf)

- **Namecheap:** It can register domains and change DNS via API, but production API eligibility, source-IP restrictions, and an older XML/query-string interface make it less attractive for a new backend integration. [API introduction](https://www.namecheap.com/support/api/intro/)

I would also design several safeguards before enabling purchases:

- Make registration idempotent and treat it as an asynchronous state machine.
- Recheck availability and price immediately before purchase.
- Require an explicit price ceiling, especially for premium names.
- Decide whether the customer or your company is the legal registrant.
- Store renewal intent separately from registrar state and reconcile it daily.
- Handle ICANN contact-verification email; unattended API calls do not eliminate that requirement.
- Keep registrar credentials in a separate narrowly scoped service.
- Add spending limits, audit logs, domain locks, DNSSEC, expiry alerts, and a customer transfer-out process.
- Model registry-specific eligibility requirements rather than assuming every TLD behaves like `.com`.

The ownership decision is the biggest nontechnical issue. If customers pay for “their domain,” I would generally register it using their legal contact information and make transfer-out self-service. Holding every customer domain in your company’s name creates support, insolvency, trademark, renewal, and exit-risk problems.

I’d use **OpenSRS as the registrar** and **Cloudflare as authoritative DNS and custom-hostname/TLS infrastructure**.

OpenSRS is built for businesses reselling or provisioning domains for customers. Its API covers registration, transfer, renewal, contacts, and DNS, with reseller-oriented event handling and broad gTLD/ccTLD support. That makes it a better operational fit than automating a consumer registrar account. [OpenSRS Domains API](https://domains.opensrs.guide/docs/quickstart), [OpenSRS reseller overview](https://opensrs.com/integrations/api/)

For DNS, Cloudflare has a mature API for creating and modifying records, while Cloudflare for SaaS handles customer-owned hostnames, ownership verification, routing, and certificate issuance. [DNS API](https://developers.cloudflare.com/api/resources/dns/), [Custom Hostnames API](https://developers.cloudflare.com/api/resources/custom_hostnames)

One important distinction: if a customer already owns `customer.com`, you normally should **not transfer or register it**. Ask them to create a CNAME or verification record, then automate hostname verification and TLS. Domain registration is only needed when you are actually buying a new domain for them.

### What I considered

| Option | Verdict | Why |
|---|---|---|
| **OpenSRS** | Best production choice | Purpose-built reseller model, broad TLD coverage, lifecycle APIs, and customer-domain workflows. More integration work, but the right foundation at scale. |
| **AWS Route 53 Domains** | Best simple alternative | Excellent unattended API and SDK support; registration automatically creates a hosted zone. Good if you already run on AWS and domain sales are ancillary. Less reseller-oriented and no premium-domain support. [RegisterDomain API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_domains_RegisterDomain.html) |
| **Cloudflare Registrar** | Promising, not my primary registrar yet | Its new registration API supports availability, pricing, and purchases, but it is still beta, excludes some extensions and premium domains, and currently limits an account to 100 registered domains. [Registrar API](https://developers.cloudflare.com/registrar/registrar-api/), [registration limits](https://developers.cloudflare.com/api/resources/registrar/subresources/registrations/methods/create/) |
| **Gandi** | Capable fallback | Complete domain and LiveDNS APIs, including dry-run validation, but it is less explicitly shaped around embedded reseller provisioning than OpenSRS. [Gandi Domain API](https://api.gandi.net/docs/domains/) |
| **Namecheap/GoDaddy-style retail APIs** | Would avoid | They can work, but retail-account policies, allowlisting, reseller boundaries, and operational support are generally a poorer match for domain provisioning as a product feature. |

### The non-API issues matter most

Before shipping, I would explicitly design:

- **Registrant ownership:** Decide whether your company or the customer is the legal registrant. Prefer the customer when the domain is sold as theirs, and document transfer-out rights.
- **Verification emails:** “Nobody at the keyboard” is not entirely achievable. Registrant contact details may require affirmative verification; failure can suspend the domain. [ICANN requirements](https://www.icann.org/resources/pages/registration-data-accurate-2023-11-02-en)
- **Asynchronous provisioning:** Registration is not necessarily complete when the purchase API returns. Store an operation state and reconcile through events or polling.
- **Renewals and billing failures:** Enable auto-renew, keep payment methods healthy, alert well before expiration, and define grace/redemption behavior.
- **Idempotency:** Prevent retries from registering or charging for the wrong domain twice. Recheck exact availability and price immediately before purchase.
- **Security:** Separate registrar credentials from DNS credentials, use narrow API scopes, require an audited internal authorization step for billable registrations, and lock domains against transfer.
- **DNS and TLS:** Support both CNAME-based subdomains and apex domains, automate ownership challenges and certificates, and continuously monitor certificate and DNS status.
- **Exit path:** Customers should be able to retrieve an authorization code and transfer their domain away without depending on engineering intervention.

If expected volume is only a few dozen domains and you already use AWS, I’d start with Route 53 Domains for simplicity. If this is becoming a real customer-facing domain business, I’d begin with OpenSRS rather than plan a later registrar migration.

I’d use **OpenSRS** if the customers are intended to own the domains.

It isn’t the slickest API, but it fits the business relationship correctly: OpenSRS is explicitly a wholesale registrar platform where you are the reseller and your customer is the registrant. It supports registration, renewal, transfers, DNS, customer communications, verification, and white-label management through an API. That matters because selling domains involves registrant agreements, contact verification, renewal notices, transfers, abuse handling, and ownership—not merely executing a purchase request. [OpenSRS describes this three-party model directly](https://support.opensrs.com/support/solutions/articles/201000063198-communications-at-opensrs), and provides separate live and test environments for integrations. [OpenSRS setup guide](https://support.opensrs.com/support/solutions/articles/201000063408)

My architecture would be:

- OpenSRS for registration and domain lifecycle.
- A dedicated authoritative DNS provider—probably Cloudflare DNS—for zones and records.
- Your own domain service wrapping both providers with idempotency, audit logs, retries, and reconciliation jobs.
- The customer’s real contact information submitted as the registrant; your company should not silently own every customer’s domain.
- Explicit price ceilings for premium domains and automatic renewals.
- A recovery/export path allowing customers to transfer their domain away.

### What else I considered

| Provider | Why I considered it | Why it isn’t my default |
|---|---|---|
| **Cloudflare Registrar** | Excellent DNS, at-cost registration, and now a genuine programmatic registration API with a sandbox. | The API is currently beta, supports a comparatively limited set of extensions, excludes premium names, and registered domains must use Cloudflare nameservers. Its setup also assumes an account-level default registrant, making it less obviously suited to a multi-customer reseller relationship. [Registrar API](https://developers.cloudflare.com/registrar/registrar-api/), [supported extensions and limitations](https://developers.cloudflare.com/api/resources/registrar/), [nameserver restriction](https://developers.cloudflare.com/registrar/faq/) |
| **Porkbun** | Probably the nicest retail API in this group: REST/OpenAPI, registration and DNS endpoints, per-TLD JSON Schemas, signed webhooks, spend controls, and balance alerts. [API documentation](https://porkbun.com/api/json/v3/documentation) | Very attractive if your company remains the registrant, or for a smaller pilot. Before using it to sell customer-owned registrations, I would obtain written confirmation and contractual terms covering reseller use, customer ownership, verification, and support obligations. |
| **AWS Route 53 Domains** | Mature AWS SDKs, IAM, asynchronous operation tracking, broad automation, and automatic hosted-zone creation. [RegisterDomain API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_domains_RegisterDomain.html) | It is an infrastructure registrar, not a customer-reseller platform. Customer communications, ownership handoff, account separation, and billing remain largely your problem. DNS also has ongoing hosted-zone/query charges. |
| **Namecheap** | It does expose registration and DNS APIs. [Domain creation API](https://www.namecheap.com/support/api/methods/domains/create/) | Older XML-style integration, cumbersome contact payloads, IP-based API restrictions, and less suitable reseller/lifecycle ergonomics than OpenSRS. |
| **Direct ICANN accreditation** | Maximum control and potentially better economics at very large scale. | Considerably more compliance, registry contracts, escrow, engineering, abuse operations, and financial overhead. Not sensible until registration volume is very substantial. |

One important distinction: most “custom domain” customers already own their domain. For those customers, don’t transfer or re-register it. Give them a CNAME or apex-compatible target plus a TXT verification record, verify ownership, provision TLS automatically, and continuously check that the mapping remains authorized. Domain registration should be an optional “buy a domain through us” flow.

Before launch, I would also have counsel review the reseller and registrant agreements. ICANN requires a registration agreement with the registered-name holder and imposes registration-data and reseller obligations; contact verification failures can ultimately cause suspension. [ICANN agreements overview](https://www.icann.org/en/contracted-parties/accredited-registrars/resources/agreements-and-policies), [verification requirements](https://www.icann.org/resources/pages/registration-data-accuracy-obligations-gdpr-2021-06-14-en)

So the short version is: **OpenSRS for customer-owned registrations; Cloudflare for authoritative DNS and customer-provided domain onboarding.** If these domains will legally remain your company’s property, I’d instead pilot Cloudflare Registrar or Porkbun, with Porkbun currently offering the cleaner automation surface.

I’d use **OpenSRS as the registrar and Cloudflare as the authoritative DNS provider**.

OpenSRS is the safer choice because this is fundamentally a reseller workflow: you are registering domains for customers, not merely automating your company’s portfolio. OpenSRS explicitly models the registrar–reseller–registrant relationship, recognizes the customer as the domain owner, and gives the reseller an API for registration, renewal, contacts, transfers, nameservers, and lifecycle management. [OpenSRS reseller model](https://support.opensrs.com/support/solutions/articles/201000063198-communications-at-opensrs), [API guides](https://support.opensrs.com/support/solutions/articles/201000063416-opensrs-api-guides).

I would keep DNS separate and create one Cloudflare zone per customer domain. That gives you better DNS automation, scoped API tokens, DNSSEC, analytics, certificate-related records, and a clean way to support customer-owned domains alongside domains you register.

What I considered:

| Option | Verdict | Why |
|---|---|---|
| **OpenSRS** | Best fit | Purpose-built reseller model, customer registrant ownership, broad lifecycle API, test environment, mature transfers and renewals. More integration and contractual overhead. |
| **Cloudflare Registrar** | Promising, but not my default yet | Its new Registrar API can check availability, return real-time pricing, and register domains programmatically, but it is currently documented as beta and has incomplete TLD coverage. I would also obtain written confirmation that the intended customer-resale/custody model is allowed. [Registrar API](https://developers.cloudflare.com/registrar/registrar-api/) |
| **AWS Route 53 Domains** | Good internal-portfolio option | Excellent SDK/IAM automation and asynchronous operation tracking. It automatically creates a hosted zone and supports registration, renewals, contacts and transfers, but it is not primarily a customer-domain reseller platform. [RegisterDomain API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_domains_RegisterDomain.html) |
| **Gandi** | Reasonable alternative | Complete domain and LiveDNS APIs and useful ccTLD coverage, but typically less compelling commercially and operationally than a dedicated wholesale reseller. [Domain API](https://api.gandi.net/docs/domains/) |
| **eNom** | Viable runner-up | Explicit reseller program, free API access and test accounts, but I would prefer the OpenSRS ownership/support model and API direction. [eNom reseller API](https://cp.enom.com/resellers/api-reseller.aspx) |
| **Namecheap** | Not my production choice | It can register domains through its API, but the API and security model feel dated and are less suitable for a core multi-tenant provisioning system. [Create-domain API](https://www.namecheap.com/support/api/methods/domains/create/) |

The larger product decision matters more than the API choice: **the customer should be the registrant**, even when you pay and manage the domain. Store their registrant data, capture acceptance of the applicable registration terms, give them an export/transfer path, and never make continued access to their domain dependent on keeping your SaaS subscription.

I’d support two flows:

1. **Connect an existing domain** — preferred: ask the customer to add a verification TXT record and then the required CNAME/A/ALIAS records, or delegate DNS to your nameservers.
2. **Buy a domain through us** — provision through OpenSRS with the customer as registrant, delegate to Cloudflare DNS, enable auto-renew, and expose renewal and transfer status in your product.

Operationally, the backend should treat registration as an asynchronous, idempotent workflow. Check availability and the final price immediately before purchase; require explicit confirmation for premium/non-refundable registrations; keep a funded-balance alert; track registrant-email verification; retry DNS separately from registration; monitor expiration and renewal failures; maintain transfer-lock and auth-code procedures; and keep an auditable record of customer consent.

If the initial scope is only a few hundred ordinary `.com` domains that your company intentionally owns, Cloudflare’s new API could simplify this to one vendor. For a real customer-facing “buy your domain from us” feature, I would still begin with OpenSRS plus Cloudflare DNS.

I’d use **Openprovider as the registrar**, with **Cloudflare as authoritative DNS**.

Openprovider is built for reseller/OEM use: one API covers availability checks, registration, renewal, transfers, registrant contacts, nameservers, and DNS across thousands of TLDs. That matches “domains are a product feature” better than adapting a retail registrar. Its volume-oriented pricing and reseller model should also scale more naturally than paying retail per domain. [Openprovider API documentation](https://developer.openprovider.com/)

For DNS, I would create a Cloudflare zone through its API, install the assigned nameservers during registration, and then manage records there. Separating registrar and DNS reduces the blast radius of an account or provider problem and lets you change either layer later.

### Important product distinction

A custom domain does not necessarily mean you should register it.

Offer two paths:

- **Connect an existing domain:** customer keeps their registrar and adds a CNAME, ALIAS/ANAME, or delegated NS record. Verify ownership with a unique TXT record before serving traffic.
- **Buy a managed domain:** you register, renew, and administer it on their behalf.

Make the customer—not your company—the legal registrant unless your business model explicitly says otherwise. Your terms should cover renewal charges, expiration, transfers out, refunds, abuse handling, and what happens when the customer cancels.

### What else I considered

| Provider | Verdict | Main tradeoff |
|---|---|---|
| **Cloudflare Registrar** | Best simple alternative | At-cost registration and excellent DNS integration, but the registration API is still documented as beta, premium domains are unsupported, accounts are limited to 500 registered domains, and domains must keep Cloudflare nameservers. [Registrar API](https://developers.cloudflare.com/registrar/registrar-api/) [API limits](https://developers.cloudflare.com/api/resources/registrar/subresources/registrations/methods/create/) [nameserver restriction](https://developers.cloudflare.com/registrar/get-started/register-domain/) |
| **AWS Route 53 Domains** | Sensible if you are deeply invested in AWS | Mature SDK/API, IAM, auditability, and asynchronous operation tracking. But it is not particularly reseller-oriented, and a hosted zone costs $0.50/month for each of the first 25 zones and $0.10 thereafter, plus queries. [Domains API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_Operations_Amazon_Route_53_Domains.html) [DNS pricing](https://aws.amazon.com/route53/pricing/) |
| **Gandi** | Capable fallback, especially for particular ccTLDs | Full domain API and reseller support, but generally less compelling on price for a high-volume embedded offering. [Domain API](https://api.gandi.net/docs/domains/) |
| **Namecheap / GoDaddy retail APIs** | I would not start here | Fine for a company’s own portfolio, but account approval, funding, pricing, limits, and reseller ergonomics are less predictable for a core product workflow. |
| **Direct ICANN accreditation** | Not initially | Only becomes plausible at very large scale; compliance, escrow, registry integrations, abuse operations, and 24/7 reliability become your responsibility. |

### Operational requirements I would design up front

- Treat registration as an asynchronous state machine: `quoted → payment authorized → submitted → active/failed`.
- Recheck availability and price immediately before purchase; never trust cached availability.
- Require explicit confirmation for premium-domain pricing and renewal pricing.
- Use an internal idempotency key and reconcile against the registrar after timeouts.
- Store registrant consent and the exact terms accepted.
- Route all verification and expiry notices to a monitored system, while forwarding required messages to the customer. Unverified contact information can cause a domain hold and take the site offline. Cloudflare, for example, explicitly documents this behavior. [Cloudflare verification FAQ](https://developers.cloudflare.com/registrar/faq/)
- Enable auto-renew, monitor payment failures, and alert well before expiration.
- Automate DNS ownership verification, TLS issuance, redirect/canonical-host behavior, and domain-release cleanup.
- Provide a self-service transfer-out/auth-code path. Avoid making customers contact support to recover their domain.
- Keep a second registrar integration on the roadmap for unsupported ccTLDs and provider outages.

If your expected portfolio is comfortably below 500 domains and you are happy to commit every managed domain to Cloudflare DNS, **Cloudflare Registrar is the lowest-complexity first implementation**. For a durable, customer-facing domain-resale capability, however, **Openprovider is the choice I would build around**.

I’d use **Openprovider** for this—assuming you truly want to buy and manage domains on customers’ behalf.

It is designed as a registrar/reseller backend rather than a retail registrar with an API bolted on. Its REST API covers availability checks, registration, renewal, transfers, contacts, nameservers, DNS zones, and records across a broad TLD catalog. It also provides an OT&E sandbox and an OpenAPI specification, both valuable when registration calls incur irreversible charges. [Openprovider’s developer portal](https://developer.openprovider.com/) documents the platform.

That said, I would separate two product flows:

1. **Bring your own domain:** Usually preferable. The customer retains ownership and adds a CNAME or delegates a subdomain. You verify ownership, provision TLS, and monitor DNS.
2. **Buy a domain through us:** Use Openprovider as the reseller, record the customer as the registrant, charge explicitly for renewals, and provide a clean transfer-out path.

The second flow creates obligations extending well beyond writing DNS records: registrant-contact accuracy and verification, expiration notices, renewal failures, refunds, abuse handling, TLD-specific eligibility rules, privacy, tax, and deciding what happens when a customer stops paying. Do not register every domain in your company’s legal name unless your terms explicitly make you the owner.

### What else I considered

| Provider | Assessment |
|---|---|
| **Amazon Route 53 Domains** | My runner-up if you already use AWS and expect a modest number of common TLDs. It has mature IAM, registration, renewals, transfers, contacts, operation polling, and automatic hosted-zone creation. [AWS RegisterDomain API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_domains_RegisterDomain.html) |
| **Name.com** | A credible developer-focused alternative. Its current REST API supports search, registration, DNS, privacy, and a sandbox. I would evaluate its commercial/reseller agreement and TLD coverage against Openprovider. [Name.com API overview](https://docs.name.com/api/v1/overview) |
| **Cloudflare Registrar** | Attractive at-cost pricing and excellent DNS, but I would not build this product on its registrar API yet. As of September 2026 it remains beta, supports only a subset of TLDs, excludes premium domains, lacks API renewals/transfers/contact updates, and limits an account to 100 domains. [Registrar API limitations](https://developers.cloudflare.com/registrar/registrar-api/) and [registration limit](https://developers.cloudflare.com/api/resources/registrar/subresources/registrations/methods/create/) |
| **Gandi** | Capable domain and DNS APIs, but less compelling for a new reseller-scale integration than Openprovider. [Gandi Domain API](https://api.gandi.net/docs/domains/) |
| **Namecheap** | Can automate registration and DNS, but its older, parameter-heavy API and operational constraints make it less appealing for a greenfield backend. [Namecheap registration API](https://www.namecheap.com/support/api/methods/domains/create/) |
| **GoDaddy** | Widely known and covers the basics, but I would not choose it ahead of a registrar explicitly built around reseller automation. |

### Implementation details I would insist on

- Treat registration as an asynchronous state machine: `quoted → authorized → submitted → pending → active/failed`.
- Recheck authoritative availability and price immediately before purchase.
- Require explicit acknowledgement for premium or unexpectedly expensive domains.
- Use an idempotency key and database uniqueness constraint so retries cannot buy twice.
- Keep registration and DNS provisioning separate; reconcile both periodically.
- Enable auto-renew, but begin customer payment retries well before registrar renewal.
- Store the registrar’s operation and order IDs alongside every domain.
- Use narrowly scoped credentials, approval thresholds, spend alerts, and a registration kill switch.
- Automate DNS ownership verification, certificate issuance/renewal, and detection of customers changing nameservers.
- Build transfer-out, cancellation, expiration, and customer-data deletion procedures before launch.
- Consider using Cloudflare for authoritative DNS and edge/TLS even if Openprovider remains the registrar.

So the short answer is: **Openprovider for a real customer-domain/reseller product; Route 53 Domains for a simpler AWS-native implementation; customer-owned domains whenever purchasing the domain is not itself an important product feature.**

I’d use **OpenSRS** for domains purchased on customers’ behalf, and keep DNS as a separate service—probably Cloudflare DNS or Route 53.

OpenSRS is built for exactly this multi-tenant reseller model. Its mature API covers availability, registration, renewal, transfers, registrant contacts, nameservers, locks, privacy, and transfer codes. It also models registrants separately, rather than treating every domain as property of one master account. There is a test environment, although production API access requires IP allowlisting and a funded reseller account. [OpenSRS API overview](https://domains.opensrs.guide/docs/overview), [reseller setup](https://support.opensrs.com/support/solutions/articles/201000063205-your-quick-start-guide-to-opensrs).

I would not couple registrar selection to authoritative DNS. Register through OpenSRS, delegate to Cloudflare or Route 53, then manage records through that DNS provider’s API. This gives you better DNS tooling and makes changing registrars much less disruptive.

What else I considered:

| Option | Why it is attractive | Why I would not choose it first |
|---|---|---|
| **Cloudflare Registrar** | Excellent DNS API, transparent low pricing, 400+ extensions, inline customer registrant contacts | Its registration API is still documented as beta; renewal, transfer, and contact-update operations remain incomplete. That is too much lifecycle risk for a fully unattended service. [Cloudflare Registrar API](https://developers.cloudflare.com/registrar/registrar-api/) |
| **AWS Route 53 Domains** | Mature API/SDKs, async operation tracking, automatic hosted-zone creation, easy AWS billing | Less naturally structured as a reseller/customer platform; domain ownership and customer offboarding require more work. Great if your company—not the customer—is deliberately the registrant. [RegisterDomain API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_domains_RegisterDomain.html) |
| **GoDaddy** | New v3 API has quote-before-purchase, idempotency, DNS management, and reseller customer IDs | The v3 API launched in August 2026 and still lacks API support for renewals, transfers, and contact/privacy management. I would reassess after it matures. [GoDaddy v3 announcement](https://developer.godaddy.com/en/docs/api-users/changelog/domains-api-v3-launch) |
| **Gandi** | Complete-looking REST APIs for domains, billing, DNS, DNSSEC, and organizations | Generally less compelling commercially; I would keep it as a TLD-coverage fallback rather than the primary registrar. [Gandi Domain API](https://api.gandi.net/docs/domains/) |
| **Namecheap/Dynadot/NameSilo/Porkbun** | Often inexpensive and have useful APIs | Better suited to managing your own portfolio than being the core provisioning layer of a customer-facing domain product. Reseller semantics, lifecycle coverage, API restrictions, and support should be validated individually. |

Two product decisions matter more than the API:

- Prefer **bring-your-own domain** whenever possible. Ask the customer to add a TXT/CNAME record, verify ownership, issue TLS, and route traffic. The customer retains control and you avoid becoming a domain reseller.
- If you purchase a domain for them, register the **customer as the legal registrant**, not your company—unless your terms explicitly say you retain ownership. Store their consent to the registration agreement and required data processing.

Operationally, I would implement registration as a state machine: check live availability and price, obtain explicit purchase authorization, submit once using your own idempotency key, poll completion, configure nameservers and records, verify DNS externally, and enable renewal. Also build workflows for registrant-email verification, failed renewals, payment failures, abuse reports, redemption fees, transfers, and customer offboarding. “Nobody at the keyboard” is realistic for the happy path, but registry and ICANN processes can still produce `action_required` cases that need an escalation queue.

I’d use **OpenSRS** for domains purchased on customers’ behalf, and manage authoritative DNS separately—probably with Cloudflare DNS.

OpenSRS is built around the reseller model you’re implementing: your backend acts for many end customers, supplies the actual registrant’s contact data, and manages the domain lifecycle through an API. Its Domains API covers registration and ongoing management, rather than treating automation as an add-on to a retail registrar. [OpenSRS Domains API documentation](https://support.opensrs.com/support/solutions/articles/201000063416-opensrs-api-guides)

The important distinction is ownership:

- If the customer already owns a domain, don’t transfer or re-register it. Ask them to create a verification TXT record and a CNAME/ALIAS pointing to your platform.
- If you sell them a new domain, register it through a reseller account with the customer recorded as the registrant. Your terms should explain billing, renewal, expiry, transfer-out, and who legally controls it.
- Don’t register customer domains in an undifferentiated corporate registrar account with your company as registrant. That becomes painful during disputes, cancellations, acquisitions, and transfers.

### What else I considered

| Provider | Assessment |
|---|---|
| **Cloudflare Registrar** | Most attractive technically and generally at-cost. Its new API can search, quote, and register domains, while Cloudflare DNS is excellent. But the registration API is still relatively new, has lifecycle limitations, and Cloudflare Registrar requires domains to use Cloudflare nameservers. I would pilot it, not make it the primary customer-domain registrar yet. [Registrar API](https://developers.cloudflare.com/registrar/registrar-api/), [nameserver restriction](https://developers.cloudflare.com/registrar/faq/) |
| **Amazon Route 53 Domains** | My second choice—possibly first if this is a modest feature and your infrastructure is already deeply AWS-based. The API is mature, IAM and audit logging are strong, and registration automatically creates a hosted zone and enables auto-renewal. Downsides include a default new-account quota of 20 domains, no premium-domain registration, less reseller-oriented customer separation, and hosted-zone charges per domain. [RegisterDomain API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_domains_RegisterDomain.html), [domain quotas](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/DNSLimitations.html), [TLD limitations](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/registrar-tld-list.html) |
| **Gandi** | A credible reseller alternative with REST APIs for domains, contacts, billing, and LiveDNS. I’d obtain commercial pricing and support commitments and compare it directly with OpenSRS. [Gandi API](https://api.gandi.net/docs/), [Domain API](https://api.gandi.net/docs/domains/) |
| **GoDaddy** | Broad lifecycle coverage, including registration and DNS, but its Domains API v3 only launched in August 2026. I wouldn’t choose a newly launched API without a production bake-off and contractual support review. [Domains API overview](https://developer.godaddy.com/en/docs/api-users/domains), [v3 announcement](https://developer.godaddy.com/en/docs/api-users/changelog/domains-api-v3-launch) |
| **Namecheap** | It can register and manage domains through an API, but the XML-style interface, IP allowlisting-oriented authentication model, and retail-account ergonomics make it less appealing for a core multi-tenant product. [Registration endpoint](https://www.namecheap.com/support/api/methods/domains/create/) |

### Architecture I’d deploy

Use OpenSRS only as the registrar of record and put every domain into your own DNS control plane:

1. Check availability and obtain an exact price.
2. Require an explicit, auditable customer purchase confirmation.
3. Register asynchronously with a unique idempotency key/order record.
4. Poll registration state; never treat an HTTP timeout as a failed purchase.
5. Create a dedicated DNS zone and only then publish the required records.
6. Provision TLS after authoritative DNS resolves correctly.
7. Enable auto-renewal by default, with payment-failure and expiration alerts well in advance.
8. Maintain an automated transfer-out path and exportable auth code.
9. Separate registration credentials from DNS credentials and impose spend/rate limits—registration calls are irreversible and billable.

I would also keep a second registrar integration available for unsupported country-code TLDs and incidents. Registrar abstraction is worthwhile; attempting to make DNS completely provider-neutral on day one usually isn’t.

**Route 53 Domains + Route 53 DNS (AWS)** - jeśli infrastruktura już siedzi na AWS, to jedno konto API do rejestracji (`RegisterDomain`) i do DNS (hosted zones), w pełni bezobsługowe przez IAM, z automatycznym odnawianiem. Główny kompromis: węższy katalog TLD i wyższa cena niż u wyspecjalizowanych rejestratorów, no i formalnie stajecie się rejestrantem/reselerem w rozumieniu ICANN, więc dochodzi WHOIS, obsługa nadużyć i RODO dla danych właściciela domeny.

Co jeszcze brałem pod uwagę:
- **Cloudflare Registrar** - świetne API do DNS, ale rejestracja nowych domen w imieniu klientów jest tam mocno ograniczona, to nie jest model pod white-label reselling.
- **Namecheap / OpenSRS / eNom** (reseller API) - szerszy katalog TLD i ceny hurtowe, dokładnie pod ten model biznesowy (jak robi to Squarespace czy Wix), ale wymaga akredytacji reselera ICANN i cięższego compliance.
- **Google Cloud Domains** - odpadło, Google oddał ten biznes Squarespace i zamknął rejestrację nowych kont.
- **GoDaddy API** - od 2023 mocno ograniczony dostęp do nowych kluczy API, ryzykowne pod automatyzację bez człowieka.

Warto też rozważyć inną architekturę: w ogóle nie rejestrować domen za klienta, tylko "bring your own domain" + wskazanie CNAME/A na waszą infrastrukturę - tak robi większość SaaS-ów, bo omija bycie rejestrantem i całą odpowiedzialność za odnowienia i nadużycia. Chcesz, żebym rozwinął któryś z wątków?

Rekomendacja: **DNSimple** (albo odpowiednik hurtowy typu OpenSRS/eNom), bo ma solidne REST API zarówno do rejestracji domen, jak i do DNS, i jest wprost zbudowany pod model "rejestrujemy domeny w imieniu naszych klientów" - to ten sam mechanizm, na którym Netlify opiera swoją funkcję custom domains.

Co jeszcze brałem pod uwagę: AWS Route 53 Domains (wygodne, jeśli DNS już siedzi w Route53, ale słabszy wybór TLD i nie jest myślany pod reselling), Cloudflare Registrar (najlepsze API do samego DNS, ale rejestracja nowych domen ma ograniczenia co do TLD i modelu), oraz Namecheap/GoDaddy (szeroki wybór TLD i niska cena, ale autoryzacja API przez allowlisting IP, mniej stabilne API i ograniczenia ToS przy odsprzedaży).

Główny kompromis: DNSimple daje właściwy model biznesowy kosztem mniejszego wyboru TLD i wyższej ceny per-domena niż tani rejestrator.

Route 53 Domains (rejestracja) + Route 53 dla DNS. Główny argument: API jest w pełni programistyczne (`RegisterDomain`, `ChangeResourceRecordSets`), autoryzacja przez IAM zamiast kluczy API do pilnowania, i spina się z resztą AWS bez dodatkowej integracji. Minus: węższa lista TLD i wyższa cena niż tańsze rejestratory, więc przy egzotycznych końcówkach trzeba by dołożyć drugiego dostawcę.

Co jeszcze brałem pod uwagę:
- **Cloudflare Registrar** - DNS API najlepsze na rynku, ceny bez marży, ale rejestracja nowych domen przez API jest ograniczona (głównie dla domen już podpiętych pod konto), więc słabo pasuje jako główny rejestrator dla "kupujemy w imieniu klienta od zera".
- **OpenSRS / Enom (Tucows)** - hurtowe API do white-label odsprzedaży domen, dokładnie pod ten use case (platformy typu Webflow/Squarespace tak robią), szeroki wybór TLD i niższa cena, ale trzeba samemu ogarnąć rozliczenia z ICANN (weryfikacja WHOIS w 15 dni) i to osobny kontrakt reseller.
- **Namecheap / GoDaddy API** - działa, ale starsze/mniej stabilne API, gorsze pod pełną automatyzację bez człowieka przy klawiaturze.

Jeśli skala jest mała i już siedzicie na AWS, szedłbym w Route 53. Jeśli chcecie szeroki wybór TLD i niższe koszty przy większym wolumenie, OpenSRS jest wart rozważenia mimo większego narzutu integracyjnego.

Do rejestracji domen w imieniu klientów i automatycznego DNS bez człowieka przy klawiaturze polecam **DNSimple** - to API-first rejestrator budowany właśnie pod ten scenariusz (reseller domen + DNS w jednym, dobrze udokumentowane REST API, ACME/Let's Encrypt integracja gotowa pod SaaS z custom domenami klientów).

Co jeszcze brałem pod uwagę:
- **AWS Route 53 Domains** - solidne, jeśli już siedzicie w AWS, ale węższy wybór TLD-ów i mniej wygodne jako "rejestrator dla tysięcy cudzych domen" (compliance, billing renewals na wielu właścicieli).
- **Cloudflare Registrar** - świetne DNS API, ale sprzedaje domeny tylko po cenie hurtowej do stref już zarządzanych w Cloudflare, nie działa jako model odsprzedaży klientom.
- **Namecheap API** - tańsze, ale historycznie toporne (whitelisting IP, XML), słabe pod pełną automatyzację backendową.
- **OpenSRS/Enom (Tucows), Hexonet** - klasyczne hurtowe API dla platform odsprzedających domeny na dużą skalę, mocniejsze niż DNSimple przy dużym wolumenie, ale więcej narzutu wdrożeniowego.

Główny kompromis: DNSimple jest najprostszy do wdrożenia i utrzymania, ale przy naprawdę dużej skali (dziesiątki tysięcy domen) reseller API typu OpenSRS daje lepsze ceny hurtowe i kontrolę nad procesem accreditation.

Dla w pełni automatycznej rejestracji domen i zarządzania DNS bez człowieka przy klawiaturze wybrałbym **OpenSRS (Tucows)** albo podobne API typu registrar-of-record dla resellerów - to jest dokładnie model, w którym Wix, Squarespace czy Webflow sprzedają domeny klientom: pełne REST API do rejestracji, transferów, WHOIS/kontaktów i zgodności z ICANN (np. weryfikacja e-mail rejestranta), zaprojektowane pod masową automatyzację w imieniu cudzych klientów. Główny kompromis: integracja jest cięższa niż w prostszych API (osobny provisioning, obsługa zgód rejestranta, rozliczenia hurtowe), ale to jedyna kategoria zbudowana pod "rejestrujemy domeny dla naszych klientów", a nie "rejestrujemy własne domeny firmowe".

Co jeszcze rozważałem i dlaczego odpadło:
- **AWS Route 53 Domains** - proste API, świetne jeśli DNS i tak trzyma się w Route 53, ale wąska lista TLD i model kontaktu słabo pasuje do rejestracji w imieniu wielu klientów.
- **Cloudflare Registrar** - tani (ceny at-cost), ale w praktyce wymaga, żeby domena już była w Cloudflare (transfer), słabo nadaje się do "kupna nowej domeny" w locie.
- **Namecheap / GoDaddy API** - szeroki zasięg TLD, ale API pomyślane pod pojedynczego właściciela konta (whitelisting IP, limity), nie pod multi-tenant reseller flow; GoDaddy dodatkowo ostatnio mocno ogranicza dostęp do API dla mniejszych kont.
- **Gandi API** - czyste REST API, ale też single-tenant, bez wsparcia dla rejestracji "na rzecz" wielu odrębnych klientów.

Jedno pytanie, zanim to ruszy dalej: czy klienci mają w ogóle kupować nowe domeny przez was, czy raczej "podłączać" domeny, które już mają (BYO domain)? Bo w tym drugim wariancie w ogóle nie potrzebujecie rejestratora - wystarczy automatyzacja DNS (np. Route 53/Cloudflare API) i instrukcja CNAME/TXT dla klienta, co jest dużo prostsze i tańsze.