Skip to main content
The public developer audience for Kralis is an integration audience. These teams are not expected to run the Kralis backend themselves. They are expected to authenticate correctly, call supported APIs correctly, and keep their client inside the authenticated school’s data boundary.

​
Typical uses

  • sign a user in
  • fetch current-user and school context
  • call GraphQL queries and mutations
  • use selected REST resources
  • consume the generated API references

​
Good client habits

  • treat GraphQL as the primary application API
  • use REST where Kralis explicitly exposes auth or read-oriented resources
  • prefer stable IDs over names for follow-up operations
  • handle validation and permission errors explicitly in the client
  • make server rules visible in the UI before submission where possible

​
Examples of rules the client should reflect early

  • a class-bound section should only be shown for the matching class
  • promotion flows should explain when a class-bound section will be cleared
  • duplicate-student hints during import should support operator review rather than hard-blocking on names alone

​
Change coordination

Kralis does not currently publish a separate public versioned API program in this docs repo. Integrators should use the live references and coordinate breaking changes before rollout.