Classroom API Integration

Kralis Classroom is available through authenticated GraphQL workflows. A custom client works with Kralis event IDs and permissions; it does not create public provider meeting links or require separate meeting accounts.

​

Core concepts

​

Recommended join flow

1. Query an event visible to the signed-in user.
2. Display schedule, access state, media defaults, and recording notice.
3. Request admission when the waiting room requires it.
4. Observe admission state instead of repeatedly submitting requests.
5. Acknowledge the recording notice when required.
6. Request short-lived join credentials through Kralis GraphQL.
7. Connect using only the returned room information and permissions.
8. Return to Kralis event history after leaving.

​

Roles and moderation

Render actions from the effective event role and current settings. A host or moderator may receive management actions; an ordinary participant does not. Always handle a rejected mutation because roles or live permissions can change after the screen was loaded.

​

Chat, hand state, and presentation

Use documented Classroom GraphQL operations for application state. Do not invent a parallel chat, admission, or attendance system and expect it to appear in Kralis history.

​

Recordings

Ordinary participants should see only recordings the API exposes to them. Managers can receive processing, failed, ready, published, and deleted states according to authorization. Never expose a playback URL beyond its intended user or assume it is permanent.

​

Whiteboards

Whiteboards can exist without an event. A client may list boards available to the user and attach or open them through documented operations. Editing access and live-view behavior remain subject to current Kralis permissions. Use GraphiQL to inspect the current classroom queries, mutations, inputs, connection fields, and responses.