# 661m Agent API Base URL: https://661m.com/api OpenAPI: https://661m.com/openapi.json Documentation: https://661m.com/docs ## Authorization The owner signs into the console, purchases a name with PayPal and creates a domain-scoped token. Payments remain a user action; an agent key cannot purchase or renew names. Send Authorization: Bearer on API requests. Store the token in a secret manager, not in public prompts, logs or repositories. The token is shown once. Read-only keys cannot preview or apply changes. ## Workflow 1. GET /domains to discover the domain ID accessible to this key. 2. GET /domains/{id} to read current services, configuration version and jobs. 3. POST /domains/{id}/plans with a service operation (examples below). 4. Inspect the returned changes. For permitted routine changes, POST /domains/{id}/apply with {"plan_id":"..."} and Idempotency-Key: . Preserve this key on retries. 5. GET /domains/{id} until applied equals version and status is active. Pending/retrying does not mean failed payment. 6. GET /domains/{id}/check to inspect recursive DNS. This does not validate hosting configuration or HTTPS. ## Website {"action":"connect_website","service_id":"website","name":"@","mode":"auto","target":"your-project.provider.example"} Root uses ALIAS and can coexist with MX and TXT. Child names use literal CNAME. Add the custom hostname to the hosting provider account separately, with the user's authorization. A provider requiring a literal root CNAME cannot be satisfied by ALIAS: use a supported TXT verification, provider address mode or www. Never promise provider compatibility without verifying it. Do not delete verification or email records to make a website work. Address mode: {"action":"connect_website","service_id":"website","name":"@","mode":"address","addresses":["YOUR_PUBLIC_IP"]} ## Verification / mail / other records {"action":"add_verification","service_id":"google-verification","records":[{"name":"@","type":"TXT","content":"google-site-verification=YOUR_VALUE"}]} Use connect_email or set_records with the same records structure. Types A, AAAA, TXT, MX, CNAME, CAA and SRV are accepted. For MX, content is "10 mx.provider.example.". Non-TXT structured content uses DNS presentation format. TTL defaults to 300 (60–86400 allowed). CNAME verification records remain literal. Never fabricate provider verification values. Do not add two SPF policies; merge only when the provider requirements are known. Each service_id owns its own records. Reusing it replaces only that service. Different services sharing TXT are merged; removing one service preserves shared values required by another. NS, SOA, DNSSEC and root delegation are platform-managed. ## Undo and conflicts GET /domains/{id}/history POST /domains/{id}/plans {"action":"rollback","restore_version":N} Review and apply the resulting plan normally. DNS caches still obey TTL. Remove one integration: {"action":"remove_service","service_id":"google-verification"} 409 means stale/used plan or idempotency conflict: read current state and preview again. 422 configuration_conflict preserves the existing records; follow the explanatory detail. 401 means token expired/revoked; ask the owner to create a new key. 403 means wrong scope or expired allocation. 429 means back off. Do not continuously retry a permanent error. ## Service scope An annual subdomain allocation is not an independent domain registration. Current infrastructure is one server; no redundant-DNS uptime SLA. Hosting, mailboxes, HTTP redirects and certificate issuance are not included. No automatic resale of expired names. Do not place critical workloads here without considering this early-access limitation.