One domain.
One scoped key.
Create an account, purchase a name, then create a domain key in the console. Store it in your agent’s secret manager. Use the API from any agent that can make HTTPS requests.
Full machine-readable instructions ↗
1. Discover your domain
GET /api/domains Authorization: Bearer YOUR_DOMAIN_KEY
2. Preview a website connection
POST /api/domains/DOMAIN_ID/plans
Authorization: Bearer YOUR_DOMAIN_KEY
Content-Type: application/json
{
"action": "connect_website",
"service_id": "website",
"name": "@",
"mode": "auto",
"target": "your-project.provider.example"
}The returned plan describes exact record changes. A root website target uses ALIAS; your email and verification records remain separate. You must also register the custom hostname with your hosting provider.
3. Apply the reviewed plan
POST /api/domains/DOMAIN_ID/apply
Authorization: Bearer YOUR_DOMAIN_KEY
Idempotency-Key: YOUR_STABLE_REQUEST_ID
Content-Type: application/json
{"plan_id":"PLAN_ID"}Reuse the same idempotency key if the request times out. A stale plan returns 409; fetch current state and preview again.
4. Verify and recover
GET /api/domains/DOMAIN_ID GET /api/domains/DOMAIN_ID/check GET /api/domains/DOMAIN_ID/history
Wait until the applied version matches the desired version. Public DNS checks are separate from hosting-provider validation and HTTPS. Restore a previous configuration by previewing an action of rollback with restore_version, then apply it normally.
Service operations
| Action | Purpose |
|---|---|
| connect_website | Follow a hostname or set public IP addresses |
| connect_email | Manage a provider’s MX, TXT and DKIM records |
| add_verification | Add TXT or literal CNAME verification |
| set_records | Manage A, AAAA, CNAME, TXT, MX, CAA or SRV |
| remove_service | Remove only one integration |
| rollback | Restore a previous service configuration |
Different integrations should have different stable service IDs. Do not reuse “website” for email. Preview checks name boundaries, incompatible records, duplicate SPF policies and local CNAME loops.
Operational boundaries
Domain keys cannot purchase names, change billing or create other keys. Literal CNAME verification is never silently flattened. The domain root cannot host a literal CNAME; use ALIAS, provider A/AAAA or a child name. Provider acceptance and certificate issuance are not guaranteed by DNS configuration alone.