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; staff-assignment endpoints; Tags and Location as filterable fields
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	Field-for-field result parity in JSON; a structured support plan and reasonable adjustments as first-class data
Evidence	Support-record read (single and list); bulk evidence export	Nothing planned that changes the live surface
Webhooks	Eight events; invocation logs	Plan and review events (plan updated, reasonable adjustment changed, review completed)
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, and the full narrative report is delivered as a PDF. We are working toward a field-for-field equivalent of that PDF in JSON, and toward the agreed reasonable adjustments as first-class structured data (distinct from the per-session evidence you read today on support records).

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 PDF (declared barriers, relative strengths, speed of working, the CogType label, and the personalised reasonable adjustments and goals), so you can render the whole result without parsing a PDF.
• A structured support plan: one entry per agreed adjustment, carrying at least its name, implementation, goal and impact. This is distinct from the support-record evidence you read today.

The shapes above are intent, not a released contract. Build against the result you can read today and these slot in alongside it.

Expanded webhook events

The eight live events cover assessment, modules and evidence export. Planned additions cover the plan and review stages of the graduated approach, for example plan updated, reasonable adjustment changed and review completed, so you can react to plan changes as they happen instead of polling for them. Webhooks are the primary event-driven pattern; the Webhooks guide is the canonical home for how delivery works today.

Cohort, staff and metadata endpoints

• 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.
• Tutor-account endpoints: create or list tutor (staff) accounts through the API. Today you set the primary tutor on create, name secondary tutors on create with secondaryTutorEmails, and update the secondary set with PUT /v1/learners/{learnerId}/secondarytutors; provisioning the tutor accounts themselves is still done in the Cognassist app. See Core concepts for how assignment governs visibility.
• 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 eight live events.
• Integrations: partner-built integrations available now.