26. Custom Domains & Domain Verification

Klariton uses domains for three related purposes: widget origin checks, customer-facing worker domains, and AI-crawler delivery. Correct domain setup is required before production embeds can run reliably.

Production Domain

The production domain is configured under Settings -> Organization. It is the primary website or shop domain where Klariton widgets are expected to run.

Use a bare host or HTTPS URL consistently, for example:

example.com
https://www.example.com

Changing the production domain can affect widget delivery and should be followed by an embed test.

Staging URLs

Staging URLs allow the widget to run outside the production domain for tests, previews, or development stores.

Add each staging origin explicitly, including scheme and port where relevant:

https://staging.example.com
https://preview.example.com
http://localhost:3000

Use staging URLs for testing. Do not loosen production-domain controls just to make a preview work.

Public Domains API

The Worker can read allowed domains through Klariton’s public domains API. It returns the production domain and active staging URLs for the organization and can be cached because domain settings change rarely.

If a widget returns an origin-related error, check:

production domain,
active staging URLs,
exact scheme and host,
trailing slash or path accidentally included,
whether the page uses HTTPS,
whether the embed uses the correct organization slug.

Customer Worker Subdomain

The embed settings can use a customer worker subdomain through data-worker-url. This enables a more first-party setup for the widget.

When a customer worker subdomain is configured, copy a fresh embed snippet from the Studio. Do not manually edit old snippets unless you understand the deployment state.

Custom Domain Provisioning

Custom domain provisioning can use Cloudflare SSL for SaaS behind the scenes. Provisioning states include:

State	Meaning
pending	Domain setup or verification is still in progress.
active	Domain is ready.
error	Provisioning failed and needs review.

The Worker can write back Cloudflare custom-hostname status to Klariton using a server-to-server worker secret. That secret is not a customer API key and must never appear in browser code.

Best Practices

Configure production domain before embedding.
Add staging URLs before testing previews.
Use generated snippets after domain or worker URL changes.
Keep worker secrets server-side only.
Test the widget on every live domain after domain changes.
For AI crawler setup, also review GEO / Agentic Reach.