The connect domain widget: drop-in domain onboarding for your product

Your customers want your product on their own domain. What most products give them is a settings page with a table of DNS records, a link to a registrar they have not logged into since 2019, and a verify button that fails for reasons neither side can see. The connect domain widget replaces that page. It is an embeddable component that takes a customer from typing a domain to serving live, TLS secured traffic in about 30 seconds, without your team building DNS tooling and without your customer learning what a CNAME is.

The widget is the front door to the same platform that powers custom domains for SaaS: a control plane that manages records, verification, and certificates, and a reverse proxy edge that terminates TLS for every connected domain. You embed the flow. The platform does the rest.

What the connect domain widget is

It is a prebuilt domain connection flow that drops into your dashboard, onboarding wizard, or settings page. A customer types a domain. The widget detects which provider hosts its DNS, requests authorization, writes the records, verifies ownership, and reports certificate status back to your application. You receive a callback in the page and a webhook on your server. Your customer receives a working domain. If you are weighing the broader build, our guide to adding custom domains to your SaaS covers the whole picture.

Coverage is broad by design. The platform supports 63 DNS and registrar providers through three paths: one-click provider authorization, where the customer approves the change inside their provider's own interface; an API token flow for providers that issue credentials; and a guided manual flow that shows the exact records and verifies them automatically the moment they resolve. The widget picks the right path for each customer, so you never have to maintain provider documentation again.

How embedding works

There are two ways in: a script tag or the SDK.

The script tag is the fastest. Add it to your page, give the widget a container element, and pass a short lived session token that your backend requests from the API. The token scopes the widget to a single customer, so a tenant can only ever see and connect their own domains.

The SDK wraps the same flow in typed configuration and events, and it is React friendly: render the component, pass the token and target, and subscribe to connection events the way you would with any controlled component. It behaves well in Next.js and other server rendered apps because the widget only initializes in the browser. The snippet above is illustrative; current options, event names, and framework notes live in the docs.

What the widget handles

Provider detection

As the customer types, the widget fingerprints where the domain's DNS is hosted and selects the best connection path for that provider. No dropdown of 63 logos, no "select your registrar" quiz. The customer just sees the next step.

Authorization

For supported providers, the customer approves the change through one-click provider authorization or a scoped API token. Consent happens in the provider's own interface, so your product never asks anyone to paste registrar passwords into a form.

Record writing

Once authorized, the platform writes the required records itself: the right types, the right values, at the right host. On the guided manual path it shows exactly what to add and nothing more.

Verification

Ownership is verified before any traffic is served. The widget polls as records propagate and flips state on its own, so customers are not stuck refreshing a page or filing a ticket to ask if it worked.

TLS status

Certificates are requested as soon as verification passes and renew automatically from then on. The widget surfaces issuance progress in plain language, and your server gets webhooks for connected, broken, and restored states.

A DNS configuration widget, not a DNS tutorial

Most domain settings pages quietly become DNS lessons: what a CNAME is, why the apex is different, which TTL to pick. A good DNS configuration widget absorbs all of that. Ours handles subdomains with CNAME records and apex domains with whatever each provider actually supports, and it applies the correct approach without asking the customer to choose. If you want the background, see apex domain vs CNAME in the glossary. After connection, monitoring keeps re-checking records so drift at the provider becomes a webhook to you, not a mystery outage report from your customer.

Styling and white label

The widget renders inside your page, not a popup or a redirect, and it is meant to disappear into your product. You control colors, typography, spacing, and the copy at each step, so "Connect your domain" can read the way your product speaks. It can run fully white label, with no Custom Domain branding visible to your customers. That matters most when the domain flow is itself part of what you sell: agencies and white label platforms put their own name on the entire experience, down to the confirmation screen.

The domain onboarding widget, placed where it counts

Where you put the widget shapes activation. A domain onboarding widget works hardest inside the first run experience: the moment a customer publishes their first site, store, or page is the moment they most want it on their own name. Site builders put it at publish time, ecommerce platforms at store launch, and creator tools at the upgrade step, where a custom domain is often the reason to pay. Because customers bring their own domain in about 30 seconds, the step is short enough to sit inside onboarding instead of being deferred to a settings page nobody revisits.

Embeddable domain connection for SaaS: what sits underneath

An embeddable domain connection is only as good as the infrastructure behind it. Every domain connected through the widget is served by the reverse proxy edge, which terminates TLS with strict multi-tenant isolation, so one customer's certificate and traffic never touch another's. Certificates are issued automatically and renewed without anyone re-touching DNS; the mechanics are covered in automating TLS for customer domains and the on-demand TLS glossary entry. The whole stack is fully managed. You embed a component; you do not inherit a certificate fleet.

When to use the API instead

The widget is the fastest path, but it is not the only one. The same platform is exposed as a full REST API, and some situations call for it:

• A fully custom UI. If your design system demands a bespoke flow, drive connections, records, verification, and TLS state directly from the API.
• Backoffice and bulk work. Migrating hundreds of existing customer domains is a script against the API, not a widget session.
• Agent driven flows. An MCP server lets AI agents connect domains with the same verification gates. See Custom Domain for AI agents and the guide to connecting domains with AI agents.
• Registrar search and purchase. If customers should buy a domain inside your product rather than connect one they own, that lives in the API.

Widget and API are not either or. Many platforms embed the widget for self serve customers and use the API for migrations and support tooling. Both write to the same control plane, described in how it works.

Try it on your own page

The free tier includes the widget, so you can embed it and connect a real domain before you talk to anyone. Create an account, follow the docs, and compare plans on the pricing page. If you would rather see it running against your product first, book a demo and we will connect a domain live on the call.