SDK Origins

SDK Origins is the allowlist for browser apps that call Thalovant from a customer-owned site.

Use it only when a browser runtime must make cross-origin SDK or API requests. For services, agents, CLIs, and jobs, keep using a backend or protected runtime with a secret store.

Free workspaces do not need SDK Origins for the starter voice path. Use Public hubs and Connections first; SDK Origins appears when a workspace plan supports browser-origin review.

Start Here If

a web app runs on your own domain and needs to call https://api.thalovant.com;
browser requests fail before they reach the API because the origin is not approved;
a teammate asked for review of a pending SDK Origin;
you need to disable an origin that should no longer send browser requests.
the code runs in a browser, not just on your laptop, server, CI job, or room device.

How It Works

Open SDK Origins in the dashboard.
Choose the workspace that owns the browser app.
Request one exact origin such as https://app.example.com.
Wait for review. A workspace reviewer receives a notification and email.
Use the approved origin. Browser requests from that origin can use non-credentialed CORS.

An origin must include https://, host, and optional port only. Do not include paths, queries, fragments, wildcards, http://, or null.

What Approval Allows

Allows	Does not allow
Cross-origin API calls from the exact approved origin.	Dashboard cookies or refresh-session flows from customer sites.
`Authorization` and `Idempotency-Key` request headers.	CSRF or dashboard-only refresh headers.
Browser SDK requests from a known production domain.	Wildcard domains, local files, or origins with paths and query strings.

Safe Browser Pattern

Use a backend when the browser needs secrets.

Good fit

A web app calls a small approved API surface with short-lived user auth and no long-lived hub identity in the bundle.

Use a backend

Identity creation, identity storage, setup material, broker passwords, refresh sessions, and payment flows stay server-side.

Review every domain

Request production, staging, and preview domains separately. Disable origins that no longer serve the app.

Local SDKs and Servers

SDK Origins are not the security boundary for code that runs from a laptop, backend service, CI job, room device, or private server.

Runtime	Use SDK Origins?	Safer pattern
Laptop script or CLI	No	Store the identity file outside the repo and restrict it to the current user.
Backend service or job	No	Keep tokens, setup material, and hub identity in a server-side secret store.
Thalovant Voice device	No	Use the private setup link or generated install command from Connections.
Customer browser app	Yes	Request the exact production, staging, and preview origins separately.

If a browser app needs a secret operation, put that operation behind your backend and call the backend from the browser.

Notifications

When an origin is requested, the requester and reviewer see a security notification. Email is also sent so the reviewer can open the dashboard and decide.

When the review is complete, the requester receives a status notification and email. Approved origins start working after the CORS cache refreshes.

Troubleshooting

Symptom	Check
Browser preflight returns `400`	Confirm the exact origin is approved and uses `https://`.
Works in staging but not production	Request the production origin separately.
Credentialed requests fail	Use the dashboard only for cookie-based flows; customer origins are non-credentialed.
`X-CSRF-Token` is rejected	Remove dashboard-only headers from SDK origin requests.
The app was moved to a new domain	Request the new origin, wait for review, then disable the old one.

Ready When

The SDK Origin setup is ready when:

the origin is exact and approved;
the browser sends only supported headers;
long-lived secrets stay out of the browser bundle;
staging and production origins are tracked separately;
old or unused origins are disabled.