Introduction

What you can build

Host a web app on your own infrastructure and register it as a room in Zetapad. Rooms can be learning tools, games, or other interactive experiences. Any signed-in member can register and self-publish an app.

One app registration creates one room entry. Your app owns its interface, hosting, activity state, multiplayer behavior, and stored data. Zetapad supplies the room launcher, member consent, approved profile fields, and scoped call access through REST and hosted tiles.

Start building

1. Follow the quickstart to register and preview your app.
2. Configure iframe embedding on your hosted launch page.
3. Implement authentication with the browser example and server example.
4. Follow restrict app access if your app must work only through Zetapad.
5. Add campus calls with the hosted call example when your app needs call tiles, controls, or shared activities. Call access is available by default with registered scopes, verified login, and native member approval.
6. Publish your app to make it available in Rooms.

How the integration works

The room runs your launch URL in an iframe. Your browser code sends version 2 postMessage requests to the Zetapad parent. The ready method identifies the current launch. The authenticate method asks for consent and returns only a short-lived authorization code, its expiry, and the echoed state challenge. It does not return member IDs or profiles.

Every app requires a backend or serverless function to complete login, even with no profile scopes. Your backend validates a session-bound state challenge, exchanges the code using its client ID and secret, and reads the verified member from the REST API. Keep access tokens and client secrets on your server. There is no browser profile method; the app starts after backend login succeeds.

REST userinfo returns the same server-generated primary userId for a given Zetapad account across approved apps, even with scopes: []. Use the server-verified ID to recognize returning members and build persistent experiences across apps. Your backend may return display data to its UI after login, but protected actions must resolve identity from the server session. See why the backend is required and persist experiences across apps.

There is no distributed JavaScript SDK. The examples are raw protocol code to adapt to your framework. There are no refresh tokens or browser-only token exchanges.

Production origins

Purpose	Origin
Trusted iframe parent	https://zetapad.com
Trusted iframe parent	https://www.zetapad.com
REST API base URL	https://zetapad.com

Register the final origin of your app's launch URL. Redirecting the iframe to a different origin prevents it from using the bridge.

Use these docs with an LLM

Every topic has a public Markdown version linked beside its title. Use the documentation index to choose relevant pages or the complete documentation for a single context file.

For exact contracts, use the REST OpenAPI document and the iframe JSON Schema. Examples are included from the same tested source used by the website.