Publishing and app lifecycle

Register and preview

Create an app in the developer dashboard with a name, description, launch URL, and required permissions. Save the one-time client secret on your server. The client ID stays visible on the app page.

One registration is one room entry. Your app handles hosting, activity state, invitations, and multiplayer behavior. Only members with Developer access enabled by an administrator can build and self-publish.

Use Preview while your app is unpublished. Only its developer owner can launch an unpublished preview. Test version 2 embedding, backend code exchange and userinfo even with zero scopes, and any exclusive access rules before publishing. Readiness and a code reply alone do not complete app login.

Publish an HTTPS URL

Publish your app to list it in Rooms. The launch URL must use HTTPS and a separate origin from Zetapad. Local HTTP exceptions apply only to unpublished previews.

Members launch the app in a full-viewport iframe and approve its registered permissions. Your app must continue to enforce its own hosting and data access policies.

Update an app

Edit the name, description, launch URL, and required scopes from the app's developer page, including while published. Saving keeps the same client ID and secret, preserves publication, and updates the room listing. Published updates must keep an HTTPS launch URL on an origin separate from Zetapad. To use a local HTTP URL, unpublish first.

Each save invalidates existing launches, authorization codes, and access tokens. Members must reopen the room and complete backend authentication again. Name, description, and URL path/query changes on the same origin preserve remembered consent. Changing the launch origin or adding or removing scopes requires approval of the current registered permissions; old approval grants no new access.

Check the current scopes returned by authenticated userinfo before enabling protected features. An existing app session cannot replace current Zetapad permission. On ACCESS_REVOKED, stop protected actions and polling, clear stale call bindings, and have the member reopen the room. Complete ready, obtain a fresh session-bound state, call authenticate, and exchange the new code on your backend. Handle CONSENT_DENIED by stopping initialization. See scope changes and reauthentication.

App call presentation returns to Zetapad after access loss while the native call and device choices continue. After a scope or origin change, attach using the fresh login, obtain native call approval again, and prepare new tiles. Ordinary token renewal within a valid unchanged launch preserves the call presentation.

Unpublishing also immediately ends issued access. Republishing does not revive old credentials. Rotation and unpublishing preserve remembered consent when the configuration still permits it.

Rotate a secret

Rotate the secret from your app's developer page, then update ZETAPAD_CLIENT_SECRET on your backend. Keep the new value out of browser code and logs. Rotation invalidates issued access immediately, so reconnect members through the iframe authentication flow.

The client ID remains the same. Remembered consent is preserved.

Delete an app

Unpublish first, then select Delete app on its developer page and confirm. Deletion permanently removes the registration and member connections and invalidates client credentials, launches, codes, and tokens immediately.

Creating another app produces a new client ID and secret and requires fresh member consent. Your app remains responsible for any data or sessions it previously stored.