18 September 2026

Institution API

The application status values have changed

status takes five values instead of three, wherever it appears: on the application, on the outcome, and on each item in the change feed.

PROCESSED was renamed because it read as finished when it means close to the opposite: an assessment has started, and a credit officer may well still be working on it. Nothing else about the value changed. If you treat status as a display string and read finalOutcome for completion, the rename is the only thing that reaches you.

If you branch on it, three things are worth a look before the release:

• anything comparing against the literal PROCESSED
• any client-side enum, schema or deserialiser that rejects a value it has not seen
• any switch with no default, or a default that treats an unknown status as an error

We told you in writing that status had three values and to branch on them, which is what makes this a breaking change rather than an addition. Our apologies for the churn. The table above is the current set, and it is repeated in the Overview.

Telling us the documents are in

POST /institution/applications/{id}/ready

Moves a RECEIVED application to READY. Send it once you hold the applicant’s documents and have found them adequate. There is no request body.

It is advisory, and nothing in our pipeline waits on it. An officer can start an assessment straight from RECEIVED, so an application you never mark ready is not stranded. What the call buys you is position: READY is something our officers can filter and sort their queue on, so a ready application is easier to pick up than one nobody has vouched for.

Safe to retry. Calling it on an application that is already READY returns it unchanged rather than failing. 409 if the application has moved past RECEIVED, 404 if we do not hold it.

Withdrawing an application

POST /institution/applications/{id}/withdraw

Moves the application to WITHDRAWN and closes the assessment if one had started, so it stops appearing in an assessor’s queue.

The body is optional, and you can post without one. Send a reason and we store it on the application, where our officers see it:

{ "reason": "Applicant accepted an offer elsewhere" }

404 if we do not hold the application, 409 if it is already withdrawn.

Management Portal

Applicants can apply directly

There is now an applicant-facing portal alongside the API. An applicant signs in, gives their details, records the qualifications they are claiming credit for, asks for the credit they believe they are owed, and submits. What arrives is an ordinary application in RECEIVED, sitting in the same queue an officer works, assessed the same way.

You control what it asks and how it reads. Application Portal in the portal has the pages and their data elements, which qualification types an applicant may record and what each one captures, the rules behind a credit request, and the wording, branding and email templates.

An applicant cannot upload documents yet. That is the next release.

Documents on an application

An application has a Documents tab holding its own files and the files attached to each of its qualifications, so an officer reads the evidence and the claim in one place rather than opening a qualification at a time.

A dashboard for officers

The officer’s landing page is now a dashboard of the work: what nobody has picked up, and what is assigned. Both tabs filter on applicant or program, stream, intake, status and owner, each tab remembers its own filters between visits, and a set of filters an officer uses often can be saved by name and picked from a list.

Who owns an application

Application Ownership under Users holds the rules that decide which team an application belongs to when its assessment begins. A rule is a condition over the application’s stream, source, intake, cohort year, program and owning faculty or school, and the first rule that matches names the group. Nothing matching leaves the application unassigned rather than guessing.

Officers assign by hand as well, to themselves or to somebody else, and the assign dialog leads with the assignees the rules suggest. Details.

Unspecified course codes

Some credit is granted against a code that stands for a quantity of study rather than a named subject. Those codes are now managed as data, under Catalogue → Unspecified Codes: an officer can read what exists, add a code and edit one, scoped to the faculty or school it belongs to, with codes shared across the institution visible to everyone.

They are selectable wherever credit is authored, both in a credit mapping and in a manual match on an application, and the lists now show what a code means instead of the bare code.

Smaller things

• Block credit is called Unspecified credit throughout, which is what the credit team calls it.
• A workflow status can carry a public label, the wording an applicant would be shown for it. Admin writes them; nothing displays them yet.