Chat widgets use client tokens for authentication and support domain restrictions to prevent unauthorized use.
When you embed a chat widget, it uses a client token to authenticate with Runtype. Client tokens are:
You never manually handle client tokens—the widget script includes them automatically.
Configure which domains can use your chat widget:
example.com www.example.com app.example.com
This allows app.example.com, staging.example.com, and any other subdomain.
Using * alone allows any domain. Only use this for testing—never in production.
Add local development URLs for testing:
This lets you test the widget locally before deploying.
Development and production surfaces have separate domain lists:
This prevents accidentally using production widgets on development sites.
Domain restrictions don’t consider protocol or port:
example.com matches both http://example.com and https://example.comlocalhost:3000 requires the specific portWidget shows but doesn’t respond:
www vs non-www mismatchesCORS errors:
If you see CORS-related errors, the domain isn’t approved. Add it to the allowed domains list.
If a client token is compromised:
Old tokens stop working immediately after rotation.
Client tokens are different from API keys. API keys are secret and used server-side. Client tokens are public and used client-side with domain restrictions for security.