Domain API

A domain API is the interface a registrar exposes for registering, renewing, transferring and managing domain names in code instead of through a control panel. It is what you integrate when your product needs to hand a customer a real domain as part of a signup flow.

It is a different layer from a DNS API. A DNS API edits records inside a zone you already own. A domain API deals with the registration itself: who holds the name, until when, and at which registrar.

Every domain API is a wrapper over EPP

This is the single most useful thing to know before you integrate one, and almost no registrar documentation says it out loud.

Registrars do not talk to registries over REST. They talk over EPP, the Extensible Provisioning Protocol, specified in RFC 5730 with the domain, host and contact object mappings in RFCs 5731 to 5733. Every "domain API" you will ever call is a JSON or XML skin over EPP commands: check, create, info, renew, transfer, update, delete.

That inheritance explains nearly every surprise in registrar APIs:

• The verbs are fixed and identical everywhere. Once you have integrated one registrar, the second takes days rather than weeks, because the object model underneath is the same.
• Operations are asynchronous and stateful. EPP has pending states. A transfer is not a request that succeeds or fails; it is an object that sits in pendingTransfer for days.
• There is no partial update. EPP update uses add/remove/change semantics on nameservers, contacts and statuses. Registrar APIs that look like a REST PATCH are translating, and the translation leaks.
• Statuses are a vocabulary, not a boolean. clientTransferProhibited, serverHold, pendingDelete, redemptionPeriod. Model them as a set of EPP status codes on your side, because that is what you will actually receive.

Availability checks are advisory, and registration is a race

The trap that catches every first integration: check does not reserve anything.

An availability check tells you a name was unregistered at the registry a moment ago. Between that answer and your create, anyone in the world can take it, and at the registry the create is strictly first-come-first-served. On a short, desirable name the gap is measured in the time your own backend takes to collect a payment.

So treat registration as a payment-style operation, not a lookup:

• Never show an availability result as a promise. Show it as a quote with a timestamp.
• Expect create to fail with "not available" even after a clean check, and handle it as a normal path rather than an exception.
• Charge the customer after the registry confirms, or refund automatically when it does not.
• Never cache availability results across sessions. A cached "available" is a customer-facing lie with a bill attached.

The same applies to price. Many TLDs have premium tiers where an individual name costs many multiples of the standard rate, and the price comes back on the check response. Read it; do not assume the TLD's list price.

The clocks you have to model

Domain lifecycle is mostly waiting, and the waits are policy, not implementation. Build these into your data model from day one:

Period	Length	What it means
Add Grace Period	5 days	A newly created domain can be deleted for a refund. Registrars ration this; ICANN's AGP Limits Policy caps how many free deletes a registrar gets per month.
Transfer pending	5 days	An inbound transfer sits pending while the losing registrar can approve or reject. No response means it completes.
Auto-renew grace	~30-45 days	After expiry the name usually still resolves and can be renewed at the normal price. Length is per registry.
Redemption Grace Period	30 days	The name is deleted but restorable, at a restore fee typically $70-$100 on top of renewal.
Pending delete	5 days	Nothing can save it. It drops to the pool at the end.
Transfer lock after registration or transfer	60 days	The name cannot be transferred away. See the note below.

The restore fee in that table is the one worth designing around. A domain your customer let lapse is not gone at expiry and is not cheap after redemption starts. If your product renews domains on customers' behalf, an alert at expiry minus 30 days costs nothing and saves a $90 conversation.

About the 60-day lock: it is what every registrar enforces today and what every guide quotes, but it is being replaced. At ICANN82 in March 2025 the GNSO Council approved all 47 recommendations of the Transfer Policy Review, including cutting the post-registration and change-of-registrant locks to 720 hours and standardising the Transfer Authorization Code. Implementation is rolling out across registrars rather than flipping on one date. The practical advice for an integrator: do not hardcode 60, read the lock status off the domain's EPP statuses.

Also worth knowing, since it governs what you may store and show: ICANN's Registration Data Policy came into force on 21 August 2025, replacing the Temporary Specification that had governed registration data since GDPR. It is the document that decides what your WHOIS and RDAP responses contain.

What the API surface looks like

Every registrar API covers roughly the same ground:

• Availability and pricing. Check one or many names; get premium pricing back. Our domain availability checker and free availability API do the read-only half of this without an account.
• Suggestions. Given a keyword, propose available alternatives.
• Register, renew, transfer in, transfer out. The four money operations. Transfer out means generating an EPP auth code.
• Nameservers. Point the domain at a DNS host, which is where a DNS API takes over.
• Contacts. Registrant, admin, tech, billing. Changing the registrant is the one that historically triggers a lock.
• Locks and privacy. Toggle registrar lock and WHOIS privacy. What privacy actually hides now depends on the policy below; the WHOIS lookup shows what a given domain publishes today.
• List and inventory. Everything in the account, with expiry dates.

Where they differ is operational rather than functional: whether there is a real sandbox, whether production access requires a reseller agreement and a deposit, whether auth is a key or an IP allowlist, whether pricing is per-call or wholesale, and how many TLDs are covered including whether local-presence services exist for ccTLDs like .fr, .de and .cn. Those four questions decide the integration more than the API design does.

Choosing one

Three trade-offs, in the order they usually matter:

1. TLD coverage and local presence. TLDs, gTLDs and ccTLDs are not interchangeable here. If you must offer ccTLDs with residency requirements, most small registrars are out immediately, regardless of how nice their API is.
2. Reseller onboarding. Wholesale channels give the best rates and the worst time-to-first-call: contracts, deposits, compliance review. Retail-with-an-API gets you live this week at a worse margin.
3. Sandbox fidelity. A sandbox that cannot simulate a pending transfer or a failed create will not catch the bugs that matter, because as established above those are the normal paths, not the edge cases.

Buying domains inside your own product

If the goal is to sell domains to your users rather than to run a registrar, the whole stack above is undifferentiated work: registrar contracts, EPP status modelling, grace-period clocks, renewal billing, ICANN compliance. It is several months of engineering that no customer will ever thank you for.

Domainee is a custom domains API for SaaS with a native MCP server — 50 domains and 100 GB free. It covers search, purchase, renewal and DNS provisioning behind one API, and the buy-a-domain API page has the endpoint list, so a user can buy a domain inside your product and have it connected without leaving it. For the comparison of doing that yourself against the alternatives, see the best domain APIs for buying domains and selling domains in your app. If what you actually need is to connect domains customers already own, that is a custom domain API or custom domains as a service instead, and pricing covers both.

FAQ

What is a domain API? A registrar's programmatic interface for registering, renewing, transferring and managing domain names. It is how a product offers "buy your domain here" without a human touching a registrar control panel. Underneath, it is a wrapper over EPP, the protocol registrars use to talk to registries.

What is the difference between a domain API and a DNS API? A domain API manages the registration: who owns the name, when it expires, which registrar holds it, which nameservers it delegates to. A DNS API manages records inside a zone: A, CNAME, TXT, MX. You usually need both, and they are frequently different vendors.

Can I check availability and then guarantee the domain? No. An availability check is a point-in-time answer with no reservation attached, and registration at the registry is first-come-first-served. Design for the create to fail after a successful check, and take payment in a way you can reverse.

Do I need a reseller agreement to use a registrar API? For wholesale channels like OpenSRS, Enom and Tucows, yes, along with onboarding and usually a deposit. Several retail registrars expose an API on an ordinary account with a sandbox and no contract, which is the faster path if margin is not the priority.

Why do domain transfers take five days? Because EPP models a transfer as a pending state, and the losing registrar is given a window to approve or reject it. If it does nothing, the transfer completes automatically at the end of that window. It is a policy clock, not a slow system.

How long can I recover an expired domain? Typically an auto-renew grace period of about 30 to 45 days at the normal renewal price, then a 30-day Redemption Grace Period (grace periods explained) where restoring costs a fee usually in the $70 to $100 range, then five days of pending delete where nothing can be done. Warn customers before redemption starts, not after.