Buy infrastructure without a human.

Public read endpoints return JSON without authentication. The check below is safe to call from any agent context with no setup — it lists 12 popular TLDs with availability and our prices for whatever name you pass.

curl -s 'https://nokycvps.com/domain-check-api.php?q=mybrand' \
  -H 'Accept: application/json' | jq .

From there: authenticate, fund a balance, then deploy a server or register a domain — all from your agent.

The canonical price/spec matrix lives in /includes/catalogue.php and /includes/domains_data.php on the server. For machine access, use the endpoint reference in §6.

Current implementation: session-cookie + CSRF. Identical to the web flow. An agent persists the PHPSESSID cookie and a _token CSRF value across the lifetime of its session.

Roadmap: a Bearer-token endpoint (POST /api/v1/account) returning { account_token: "AAAA-BBBB-CCCC-DDDD" } is planned. The current session-based API works today without it. When Bearer lands, all session endpoints will also accept Authorization: Bearer <token> as an alternative auth.

JAR=/tmp/nkv.jar
# 1. get a session + CSRF
CSRF=$(curl -sc $JAR https://nokycvps.com/csrf.php | jq -r .csrf)

# 2. create the account (no email verification)
curl -sb $JAR -c $JAR https://nokycvps.com/auth-api.php \
  -d "action=signup" \
  -d "email=a$(date +%s)@nokycvps.com" \
  -d "password=Sup3rH4rdP4ssword!" \
  -d "password_confirm=Sup3rH4rdP4ssword!" \
  -d "_token=$CSRF" | jq .

# 3. confirm we're logged in
curl -sb $JAR https://nokycvps.com/me.php | jq .

1. Top up balance. POST /topup-api.php with action=create&amount=100&coin=XMR&_token=<csrf> → returns order_ref.
2. Open the invoice. GET /pay/<order_ref> returns HTML with the deposit address, exact amount, optional memo. For programmatic flow, the same data is on GET /topup-status.php?ref=<order_ref>.
3. Send crypto. Exactly the deposit_amount to deposit_address on the matching network. Bonus from $100 (+30%) up to $1000 (+70%). The bonus is auto-credited on confirmation.
4. Wait for confirmation. Poll GET /topup-status.php?ref=<order_ref> until status=confirmed. The simsms hub pushes the webhook to /network-api/payment_status.php — usually 1–3 confirmations on the source chain.
5. Deploy a server. POST /deploy-api.php with product=vps|dedi&plan=s1|s2|s3|r1|r2|r3&region=par|rek|zrh|otp&os=debian-12&billing=1&root_password=<12+chars>&_token=<csrf>. Balance is debited atomically. Response includes server_id and the new balance.

curl -sb $JAR -c $JAR https://nokycvps.com/deploy-api.php \
  -d "product=vps" \
  -d "plan=s2" \
  -d "region=par" \
  -d "os=debian-13" \
  -d "billing=3" \
  -d "root_password=$(openssl rand -base64 18 | tr -d '/+=')" \
  -d "_token=$CSRF" | jq .

# Insufficient balance? Response includes the deficit:
# { ok:false, error:"insufficient_balance", have:X, need:Y, deficit:Y-X, topup:"/topup" }

1. Check availability. GET /domain-check-api.php?q=<sld>. Public, no auth. Returns { results: [{ tld, available, premium, price_usd, market_usd, discount_pct, badge, featured }] }. Pass q=name.fr to surface .fr first.
2. Authenticate (see §3) and ensure balance ≥ price.
3. Create the order. POST /domain-order?domain=<sld>.<tld> with years=1&privacy=1&_token=<csrf>&_submitted=1. Returns 302 redirect to /domain-pay?id=<order_id>.
4. Pay from balance. POST /domain-pay-api.php with action=pay_balance&order_id=<n>&_token=<csrf>. Balance debits atomically. Order moves to paid.
5. Registration finalization. Currently human-finalized within 24h (DOMAIN_AUTO_REGISTER=false). Order transitions paid → active when registry confirms.

# 1. probe availability
curl -s 'https://nokycvps.com/domain-check-api.php?q=mybrand' | jq '.results[]
  | select(.available==true)
  | {domain, price_usd, discount_pct}'

# 2. create the order (returns 302 → /domain-pay?id=N)
curl -sb $JAR -c $JAR -i -X POST \
  'https://nokycvps.com/domain-order?domain=mybrand.com' \
  -d "years=1&privacy=1&_submitted=1&_token=$CSRF" | grep -i location

# 3. pay it
curl -sb $JAR -c $JAR https://nokycvps.com/domain-pay-api.php \
  -d "action=pay_balance&order_id=42&_token=$CSRF" -i

All authenticated endpoints accept the same CSRF mechanism: include _token as POST body, or X-CSRF-Token as header. The token is fetched once via /csrf.php and persists for the session lifetime.

If a human is briefly in the loop (approval, confirmation), surface these URLs — they pre-fill the web flow with the agent's prior decision. No re-entry needed.

• CSRF on every POST. Fetch /csrf.php once per session; include the value as _token in body or X-CSRF-Token header.
• Session cookies must persist. Use a cookie jar (curl -b/-c, Python requests.Session(), etc.). Without persistence, every call is a fresh anonymous session.
• Idempotency. Balance credits are idempotent via credit_applied=1. Re-deploying with the same parameters creates a new server — there is no de-dup on deploy keys yet. Use your own client-side dedup if needed.
• Webhook timing. Topup confirmation is push-based from the simsms hub. Median ~3 min for BTC (1 conf), ~30 s for XMR. Poll /topup-status.php with a 5–10s interval.
• Top-up bounds (server-enforced): minimum $30, maximum $10,000 per invoice. Values outside this range return ok:false with error:'amount_too_low' or 'amount_too_high' — do NOT rely on client-side validation. Bonus tier starts at $100 (+30%) and caps at +70% beyond $1000.
• Server root passwords must be 12–64 chars. Stored AES-256-CBC encrypted at rest, decryptable only by the provisioner.
• DOMAIN_AUTO_REGISTER is currently off. Paid domain orders move to paid; operator finalizes registration within 24h.
• i18n prefix. URLs accept an optional language prefix (/fr/account, /de/domains). For agents, the bare path is canonical.

An agent driving this API binds the same user to the same operating rules a human would. Read these once and encode the constraints in your agent's reasoning:

• /terms-of-service — what we will and won't act on (judicial orders only, with notice).
• /acceptable-use — what you can run (the policy is "if it's legal somewhere"). One hard line: no CSAM.
• /privacy-notice — what we collect (an email, a password hash, your balance, your server config), what we don't (names, addresses, fingerprints, analytics).
• /abuse-policy — network-level abuse only (spam, scanning, amplification). Not content-based suspension.

Agents are welcome. We don't differentiate between an account opened by a human and one opened by an autonomous client. The rules of the road are the same.

MCP server: planned. The current REST surface above covers the same actions. Once the MCP endpoint ships, it will be advertised at /.well-known/agent.json#mcp and via the x-mcp-server extension in openapi.json.