Developer documentation
Access and security
Understand public content, private grants, origins, viewer isolation and page policies.
Public and private access
Public access mints guest viewer sessions for a published experience. The experience UUID is public and must not be used as a password.
Allowed domains control browser framing. They do not authenticate a person or form a paywall against non-browser clients. Choose Public only for content you intend viewers to access.
Private access requires a short-lived grant signed on your server with the experience signing secret. It does not give the viewer a RapidEye account or a saved browser profile.
Three separate boundaries
| Boundary | What it controls |
|---|---|
| Framing | The published domain allowlist becomes the iframe response’s frame-ancestors policy. |
| Viewer identity | The server mints and validates a viewer session token. A host-origin claim or referrer is attribution, not authorization. |
| API access | Runtime requests require that viewer identity and the current published experience/capabilities. |
The wrapper sends to the loader’s RapidEye origin and accepts messages only from its own iframe at that origin. The runtime accepts only its parent window on the validated host origin.
Credentials and isolation
- Keep the experience signing secret on your server.
- Never put owner sessions, account credentials or private signing secrets in HTML.
- Do not place grants in iframe URLs, query strings or analytics logs.
- Let the runtime manage viewer token rotation.
- Do not request viewer credentials or payment details through browser tasks.
Viewers do not receive owner account memory, account chat history, the upload catalog or saved browser credentials. Their conversation is scoped to their viewer session.
Content Security Policy and permissions
Your page must allow the generated loader origin in script-src and the runtime origin in frame-src, or their applicable fallback directives. Merge those origins into your existing policy.
A locally owned loader helper still needs permission for its external script. External JavaScript files or your site’s nonce mechanism can avoid introducing inline-script exceptions.
The wrapper sets microphone, autoplay, fullscreen and clipboard-write delegation on its iframe. Browser permission and autoplay rules still apply.
Voice capture additionally requires HTTPS, the published Voice capability, microphone delegation and a viewer gesture. A parent Permissions Policy can still deny microphone access.
If your page is itself inside another iframe, every ancestor must satisfy the experience’s framing policy. Review the actual browser console rather than weakening policies blindly.