Ownership rule. A world you make in the Studio is stored with no
app_id
and your account as its author. Your secret key can still mint a session
for it — the API matches the world’s author against your key’s account owner.
In short: your key runs the worlds you authored, even the ones that were
never created through the API. It will never run another account’s world.Copy the world ID
Open the world in the Studio and use the Developer / API row in the share panel to copy its ID. The ID is the world’s identity everywhere in the API; the slug is only a play handle. It looks like:Run it
Embedding is the same two steps as any world: mint a short-lived session token on your server, then boot the world in the browser with the session token (never your secret key).1
Mint a session token (server)
Call The response is the usual
POST /v1/sessions/token with your secret key and the Studio world’s
UUID as worldId. Bind it to the player and to the origin you’ll embed on.{ token, expiresIn, worldId, slug, jti }. If the
world isn’t one you authored (or the key’s account doesn’t own it), the mint
fails closed with 404 — never a cross-account read.2
Boot the world (browser)
Exchange the session token for a runtime connection with
POST /v1/sessions/connect, or let the SDK do it for you. Pass the session
token, never your secret key./v1/sessions/connect returns { worldId, reactorJwt, expiresIn, expiresAt, world } —
the same runtime payload an API-generated world returns, so nothing else in
your integration changes.Notes
- Identity is the UUID. Always reference the world by its ID. The slug can change; the ID never does.
- Author match only. The bridge allows exactly one thing beyond app-scoped worlds: a world whose author is your key’s account owner. Deleted worlds are excluded, and no other account’s worlds are ever reachable.
- Everything else is identical. Quotas, concurrency, origin binding, and the
drift-refresh handoff all behave the same as for a world you
created through
POST /v1/worlds.
It works both ways
The bridge runs in the other direction too. A world you create with a live secret key throughPOST /v1/worlds is attributed to your account,
so it shows up in your web Studio under My
Creations right alongside the worlds you built visually — same account, one
library. Open it there to view and play it. Editing and publishing follow the
Studio’s normal rules: API-created worlds land unlisted, and — exactly like a
world you built by hand — saving changes or publishing requires your account to
have creator access, so if the Studio blocks a save or publish that’s the creator
gate, not the bridge. Test-key creations stay out of the Studio list on purpose, so
your fixtures never clutter your real worlds.
Next steps
Embedding
Theming, events, token refresh, and cross-origin security.
Session handoff & continuity
Keep long streams clean with the drift-refresh double-buffer.