client
Client login (issue a bearer token)
Native-client login. Verifies email + password through the same shared path as the browser login (rate limiting, account lockout, bot friction, bcrypt, security logging) and, on success, issues a **bearer token** the client sends on every later request as `Authorization: Bearer <token>`. Unlike the browser flow there's no cookie, no CSRF, and no idle-timeout. The rate limiter's captcha 'challenge' (which a native client can't solve) is reported as a 429 back-off.
Client logout (revoke the current token)
Revokes the bearer token used to make this request, so it can no longer authenticate. Idempotent.
Check the current token (whoami)
Whoami / token check. A cheap endpoint the client can call to confirm its bearer token is still valid: `200` with the user when the token is good, `401` when it's missing, expired, or revoked. (Also renews the sliding expiry, like any authenticated call.)
List a course's assignments + problems (client)
A course's assignments and their problems, scoped by the caller's role in the course (which they must be able to access, else 404): - Admin / course staff (Faculty, TA): every assignment, published or not. - Student: only published assignments they are assigned, and only once past the assignment's available ('unlock') date if one is set. Pre-unlock assignments are withheld entirely. Each assignment also reports whether it is an individual or group assignment, the caller's group name when it is a group assignment they belong to, and whether late submissions are accepted. The answer-key file is never included.
List my courses (client)
The signed-in user's courses (slim shape for the client), scoped to the token's user. Visibility is per the viewer's role in each course, and never lists a deleted or archived course: - Admin: every non-archived course (published or not), enrolled or not. - Faculty/TA: their non-archived courses (published or not) where they are staff. - Student: their published non-archived courses that are currently within the course's start/end date range (a submission tool only lists courses you can submit to now). A user who is staff in one course and a student in another is judged per course.
Get a submission's result (client)
The result of one submission, for polling after a submit. Returns the queue `status` (PENDING/PROCESSING/COMPLETED/FAILED) and, once evaluated, whether it was `correct`, the `grade`, and the `feedback` (the witness / counterexample string). A caller may read their own submission; staff may read anyone's in their course. Anything else is masked as 404.
List my submissions for a problem (client)
The caller's own submission history for one problem (attempt list), newest first, so the client can show past attempts and drill into any one's result via `GET /submissions/{id}`. Scoped to the token's user, so it never exposes anyone else's work.
Submit a solution (client)
Submit a solution file (client). Same multipart body, validation, caps, cooldown, late policy, storage, and queueing as the web `/api/submissions` (it runs the same `createSubmission` service) but authenticated by a bearer token. Returns 202 with the new submission's id + status.
My full course tree (client)
The caller's entire course tree in one call: every visible course with its assignments and their problems, resolved for this user. Lets the native client load once and filter locally (upcoming assignments, unsolved problems) instead of fetching per course. Visibility matches the per-course endpoints: admins and course staff (Faculty, TA) see every assignment, published or not; students see only published assignments assigned to them that have unlocked. Each problem includes a derived `solved` (full marks earned). Answer-key files are never included.