How Domain0 works
The connection lifecycle, trust boundaries, and fallback behavior.
The two-client model
| Client | Runs in | Authentication | Purpose |
|---|---|---|---|
createDomain0PlatformClient | Your server | Long-lived d0_… API key | Create/read connections and issue browser access |
createDomain0Client | Browser or trusted server | Short-lived bearer token | Advance one connection through the setup flow |
The platform client derives the application and tenant from its API key. Your code cannot submit ownership identifiers through this public boundary.
Connection lifecycle
requested → detecting provider → provider selected
→ authorization → plan review → apply → propagation → active
↘ guided manual setup ────────────────────────────────↗The exact path depends on current provider capability and the selected setup
policy. Provider authorization alone is never treated as success. A connection
becomes active only after the requested records are observed at every
authoritative nameserver required by the verification policy.
Automatic and manual setup
Domain0 uses an automatic path only when the current deployment has reviewed support for it. Unavailable, unsupported, or unverified providers stay usable through the same guided manual record flow.
Idempotency and retries
Connection mutations use typed command identifiers inside the orchestration API. The embedded UI creates fresh commands at the appropriate state boundary. A retry resumes from the recorded pre-failure checkpoint; it does not blindly repeat an unknown provider mutation.