Roadmap¶
This page describes the direction of the Cognassist API: the capabilities we are building toward, so you can design an integration that extends cleanly as they land. It is a statement of intent, not a commitment. Shapes may change and there are no dates here. Everywhere the docs mark something as planned, they link back to this page.
Everything below builds on the same model the API already uses: the same join keys, and the same golden thread where every reasonable adjustment traces to an assessed barrier and every record of support traces back through it. Build on what is live today and these additions slot in without a rewrite.
In short, for a non-technical reader: the assessment, results, evidence export, webhooks and single sign-on you rely on are all live now. What is coming is richer structured data, more webhook events, and cohort and site-level reporting. None of it changes what works today.
What is live today vs planned¶
Most of the surface you need is already live. Design against the Live today column now; treat the Planned column as direction only. For the exact request and response shapes of everything in the Live today column, see the interactive API reference.
| Area | Live today | Planned (direction, not a contract) |
|---|---|---|
| Learners | Create, get, update, delete a learner; paged learner list | Cohort and bulk reconcile endpoints; Tags and Location as filterable fields |
| Staff | Create, get, list, update, delete staff (tutors, tutor managers, client admins, report viewers) | Nothing planned that changes the live surface |
| Assessment | Assessment invite, embedded assessment URL, assessment result | Nothing planned that changes the live surface |
| Results and plans | Result as JSON (domains, classification, support-likelihood rating); full narrative report as a PDF request; the agreed support plan as structured data (barriers, reasonable adjustments, goals and impact, review cadence) | Field-for-field parity of the rest of the PDF in JSON (relative strengths, speed of working, CogType label) |
| Evidence | Support-record read (single and list); bulk evidence export | Nothing planned that changes the live surface |
| Webhooks | Nine events, including Support Plan Changed (plan and review changes, with the changed sections named for re-fetch); invocation logs | Nothing planned that changes the live surface |
| Platform | Managed SSO; SFTP; Microsoft Teams app | Downloadable low-code recipes |
Richer result and plan data¶
Today the assessment result returns the nine cognitive domains, the three-tier classification and the support-likelihood rating, the full narrative report is delivered as a PDF, and the agreed support plan is readable as structured data through the support-plan endpoints: barriers, reasonable adjustments, goals and impact, and review cadence, distinct from the per-session evidence you read on support records. We are still working toward a field-for-field equivalent of the rest of that PDF in JSON.
A cognitive profile is a signal about how a learner works best, not a verdict or a diagnosis, and these adjustments are the everyday, practical kind recognised by most awarding organisations. That framing will not change as the data gets richer.
What each planned addition is intended to carry
- Full result parity in JSON: a field-for-field equivalent of the rest of the PDF (relative strengths, speed of working, and the CogType label), so you can render the whole result without parsing a PDF. The agreed reasonable adjustments and goals are already readable through the support-plan endpoints; this item covers the remaining assessment narrative.
The shapes above are intent, not a released contract. Build against the result and support plan you can read today and these slot in alongside it.
Expanded webhook events¶
The nine live events cover assessment, modules, evidence export and support-plan changes — the Support Plan Changed event signals plan edits (including reasonable-adjustment changes) as they happen, so you can react instead of polling. Further review-stage events (for example review completed) are planned. Webhooks are the primary event-driven pattern; the Webhooks guide is the canonical home for how delivery works today.
Cohort and metadata endpoints¶
Staff-account endpoints have landed: you can now create, list, read, update, and delete tutors and other staff through /v1/staff, so provisioning tutor accounts is no longer app-only. See managing staff accounts for how to use them. What remains planned:
- Cohort and bulk endpoints: read and reconcile many learners at once (for example a per-cohort coverage summary such as assessed, plan agreed, modules active, last reviewed) rather than iterating learner by learner.
- Tags: arbitrary labels such as course codes, kept separate from the course description that drives assessment personalisation, planned as a first-class filterable field.
- Location: see Location: first-class sites below.
Location: first-class sites¶
Your organisation is a single client today: one credential set covers the whole organisation. Location is the planned feature that will make the distinction between sites first-class: a filterable learner field you set on create and filter reporting by.
Related¶
- Core concepts: join keys, enums, access scope and the golden thread, all in their canonical home.
- Planning your integration: the three integration phases and the reconcile pattern.
- Webhooks: the delivery model and the nine live events.
- Integrations: partner-built integrations available now.