Skip to main content

GraphQL errors

A GraphQL HTTP response can contain errors even when the transport request completed. Check both data and errors; do not treat HTTP 200 alone as application success.

REST errors

Use HTTP status and the documented response body. Handle invalid credentials, expired tokens, forbidden access, validation errors, rate limits, and server failures separately.

Cursor pagination

Kralis GraphQL lists commonly use Relay-style connections.
Never silently assume a fixed first page contains the whole school. Search selectors, event lists, students, recordings, and other growing datasets must support pagination.

Retry safety

Queries are generally safe to retry. Mutations may not be. Disable duplicate submission, retain operation state, and refetch after an uncertain response before repeating a create, payment, result, promotion, or recording action.

Changing data

Another Kralis Web user or custom client can change the same school data. Refetch after important mutations, use realtime or polling only where the product contract supports it, and avoid assuming cached permissions remain valid forever.