SDK Sites: a cleaner way to manage where your embeds live
We're rolling out SDK Sites, a lightweight registry for the domains where you embed our SDK. Here's why we built it and what it sets up for later.
If you've ever tried to debug an SDK embed on a staging domain at 11pm, you know the feeling: you're not sure if the right key is in play, you're not sure if the request is even being recognized, and the only thing the dashboard tells you is that something is happening, somewhere. We wanted to fix that, and SDK Sites is the first step.
Why a registry, and why now
Up to this point, the SDK was happy to run anywhere you dropped it. That's flexible, but flexibility without structure turns into mystery traffic — staging requests mixed with production, partner subdomains nobody remembered approving, and no good way to scope configuration per environment. The fix is unglamorous but useful: make customers explicitly tell us where their SDK is going to run.
An SDK Site is just a named pairing of a human-readable label and the domain where the SDK will be embedded Add an SDK Site. That's it. No complicated topology, no nested environments. A site is the unit, and you can have as many as you need.
What this unlocks
Once a domain is registered, a lot of things we've wanted to build get much easier to reason about:
- Per-site configuration. Different sites can carry different settings without forcing teams to juggle separate accounts.
- Cleaner observability. Traffic in dashboards and logs can be attributed to a specific site instead of a raw origin string, which matters a lot when you have a dozen subdomains.
- A foundation for trust. Knowing the set of domains a customer expects the SDK to run on is the prerequisite for almost any meaningful origin-based safety check we'd want to add later.
None of that lands today in a single dramatic feature, and that's intentional. We'd rather ship the primitive cleanly and build on it than bundle six half-finished ideas behind one launch.
The shape of it
Registration itself is deliberately boring: name the site, give it a domain, save Add an SDK Site. We've kept the form to the minimum because we expect most teams to register sites once and forget about them — the value isn't in the act of adding a site, it's in everything downstream that can now assume sites exist.
If you've been using the SDK across multiple properties, this is a good moment to go list them out. It will make the next few releases land more usefully for you.
What's next
With the registry in place, we're turning to the features that depend on it: site-scoped configuration, better attribution in analytics, and origin-aware controls for teams that want them. Expect those to roll out over the next few releases. As always, if there's a piece of this you'd want us to prioritize, tell us — the shape of what comes next is still very much up for discussion.