Where to go from here

Two things are now in place: a host-scoped Liveboard and a conversational Spotter panel underneath it, both themed to match the SpotStay portal and locked down so hosts cannot download or share things that should not leave the tool. The pattern underneath does not change for whatever you build next — a Liveboard for a different team, a Spotter embed inside a mobile app, or a custom action that writes back to a different internal system. The full working version of this build is in the SpotStay example repo on GitHub if you want to see it end to end.

Every build follows the same loop:

Grab the exact ID (Liveboard, model, or visualization) from the Developer Playground. Don’t hand-type it.
Wire it into your existing app shell with the SDK.
Style it with CSS variables first. Use rules_UNSTABLE only when you have to.
Lock down actions before it reaches real users, not after.

Next steps🔗

Appendix A: Development environment🔗

Use the latest Chrome build and keep DevTools open while developing: most embed issues show up as console errors first.
Disable the browser cache while iterating (DevTools > Network > Disable cache), or you’ll keep debugging a stale build of app.js.
Blank embed → check the console, then confirm thoughtSpotHost is correct and reachable.

Appendix B: Security settings🔗

Configure all three settings under Develop > Customizations > Security Settings before anything renders on your domain:

CSP visual embed hosts: The domain(s) allowed to embed ThoughtSpot. For example, http://localhost:8000. Use * only for local testing, never in production.
CSP connect-src domains: Required for custom actions. The full URL (protocol and port) that a custom action or callback needs to reach.
CORS allowlisted domains: Required with a token-based AuthType. The full URL of your embedding app.

Note	In production, your app’s domain typically needs to be in all three lists.

← Previous Done