Answer
Domain registration API for AI agents, with no browser
Slipdock is a domain and infrastructure API where the whole flow is headless. One unauthenticated POST /v1/workspaces returns a scoped API token — no signup form, no email confirmation loop, no CAPTCHA, no browser. Domain search, authoritative DNS, a private git repository and a small deployed app are all free and need no human. Registration is the one step that costs money, and money is where a human is required: we email the workspace owner a payment link and hand your agent an order to poll.
$ curl -sX POST https://api.slipdock.ai/v1/workspaces \ -H 'content-type: application/json' \ -d '{"owner_email":"you@example.com"}' {"workspace_id":"ws_7f3a","token":"sk_live_...","plan":"free"} $ export AUTH="authorization: Bearer sk_live_..." $ curl -s "https://api.slipdock.ai/v1/domains/search?q=example&tlds=com,dev,io" {"results":[{"domain":"example.dev","available":true,"price":"$14.50"}]} $ curl -s https://api.slipdock.ai/v1/domains/register -H "$AUTH" \ -H 'idempotency-key: reg-example-dev' \ -d '{"domain":"example.dev","years":1}' 402 payment_required · pay-link emailed to y***@example.com next_action: await_payment · poll /v1/orders/o_1f2e
Why the browser normally appears, and why it does not here
Every mainstream registrar assumes a person: an account signup with a password, an email confirmation, a card form, sometimes a CAPTCHA, and a dashboard where the real state lives. Their APIs are usually good — the browser step is not in the API, it is before the API, in the account and billing setup that must already exist before a token works.
That is the wall an agent hits. It is not that the registrar lacks an endpoint; it is that the endpoint presumes a human already did something in a browser. Slipdock removes the presumption by moving the human to the end, and narrowing what they have to do to a single approval.
What your agent can do with no human at all
| Capability | Call | Human needed? |
|---|---|---|
| Domain availability and firm price | GET /v1/domains/search | no |
| Private git repository | POST /v1/repos | no |
| Build and deploy from a push | git push | no |
| Authoritative DNS records | POST /v1/dns/{zone}/records | no |
| Register a domain | POST /v1/domains/register | once, by email |
| Second and later purchases inside the cap | same call | no — already authorised |
Handling the payment step correctly
Treat 402 payment_required as a normal step, not an error.
Read next_action, tell your user you have emailed them a link for
a specific amount, and poll the order every 2–5 seconds until it reads
complete. Do not go looking for a card field, and do not ask your
user to paste card details into the conversation.
If the owner funds a wallet and sets a per-purchase cap at that first approval, subsequent purchases underneath the cap complete immediately with no email — because a human already authorised that ceiling.
When another provider is the better answer
If your user already has a Cloudflare account with a payment method on it, the Cloudflare Registrar API costs the same as us and is likely already in your toolchain. The trade you are making is that a human already opened a browser, and that nothing in their API caps what an agent can spend. The full comparison is here.
Related questions
Does the agent need an API key to search domains?
It needs a token, but getting one is a single unauthenticated POST and takes no human. Search itself is free and unlimited.
Can the agent complete a registration end to end alone?
No, and that is deliberate. The purchase requires a human authorisation artifact — either an approved pay-link or a wallet mandate with headroom, both of which a person created. Everything before and after the payment is fully automated.
Is there an MCP server?
Yes, exposing the same nouns as tools: search_domains, register_domain, check_order, create_repo, wallet_status and others.