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
- Query an event visible to the signed-in user.
- Display schedule, access state, media defaults, and recording notice.
- Request admission when the waiting room requires it.
- Observe admission state instead of repeatedly submitting requests.
- Acknowledge the recording notice when required.
- Request short-lived join credentials through Kralis GraphQL.
- Connect using only the returned room information and permissions.
- 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.
Do not embed infrastructure credentials, construct realtime room names, or bypass Kralis admission with arbitrary meeting links. Always request access and room credentials through authenticated Kralis operations.
classroom queries, mutations, inputs, connection fields, and responses. 
