Setup types & the ask gate

Setup types

POST /v1/domains:check classifies a domain into a setup_type that steers the widget to the smoothest available rail:

• automatic — the provider can be configured without the customer copying records: an OAuth-into-provider authorization or a Domain Connect apply. domains:check reports oauth_available and domain_connect so the widget knows which is on offer.
• manual — no automatic path; the customer copies the exact records into their DNS provider and the poller watches for them.
• async — a Domain Connect flow that completes out-of-band (the provider applies the template after a redirect).
• mcp — reserved for agent-driven setup.

The engine also returns capability flags (ns_support, wildcard_support, cname_flattening, spf_override_support, caa_support) and any record_conflicts it observes in public DNS, so you can pre-warn the customer.

Control is proven by the rail

There is no separate ownership-TXT challenge. Each rail is itself proof that the customer controls the zone:

• an OAuth authorization grants a one-time token to that customer's DNS account;
• a Domain Connect apply happens inside the customer's provider session;
• an API token is a scoped credential only the zone owner can mint;
• the manual flow requires the records to actually appear in the domain's authoritative DNS, value-checked.

The ask gate

Before the edge serves TLS for a hostname, it calls POST /internal/ask. The control-plane approves the host iff a connection for it is live or propagating — a status-based gate, answered from a single indexed lookup so the TLS handshake never blocks on business logic. A domain the platform has never connected is refused, so the edge will never obtain a certificate for an unauthorized host.