For decision makers¶
A concise technical overview for the person signing off the integration: a CTO, a technical lead, or the developer who will scope the work. It answers the four questions a due-diligence review actually asks, is the approach sound, how does it work, what does it touch, and what is live today, and links to the pages your team needs to go deeper. It is code-light on purpose; the detail lives one click away.
The short version: Cognassist is a UK-hosted REST API that your systems call outbound over HTTPS. There is nothing to install and nothing runs in your data centre. Your credentials only ever see your own organisation's data, and everything described in these docs is live and callable today.
How the integration works¶
An integration is a set of outbound calls from the systems you already run (your MIS, your learner portal, your reporting stack) to the Cognassist API. The direction of travel is always the same: your systems reach out to Cognassist, and Cognassist never reaches into your network. Because there is nothing to host, there is nothing to patch, scale, or keep running; the work is building and maintaining the calls, not standing up infrastructure.
It follows three phases, and the first delivers value on its own:
| Phase | What it does |
|---|---|
| 1. Get started | Learners are created and assessed, and the right people see the results |
| 2. Put the data where it is needed | Cognitive profiles appear inside the tools your tutors already use |
| 3. Pull data out | Evidence and reporting flow into your own funding and audit processes |
Ship Phase 1, then layer the rest on later. Planning your integration breaks down each phase, and the integration checklist is the ordered runbook your developer follows.
How you receive results¶
The delivery model is webhooks first. When a learner finishes, Cognassist sends an Assessment Completed notification (event id 100) to an HTTPS endpoint you register, so your systems react to events instead of asking repeatedly whether anything has changed. This is the primary, event-driven pattern and the one to design for.
If you cannot expose an inbound HTTPS endpoint (a common on-premises constraint) a low-code receiver such as Power Automate or Logic Apps can catch the webhook for you; it is a helper to receive webhooks, not an integration method in itself. Polling is the fallback, used only when webhooks genuinely cannot be received in any form. These docs are written for a competent technical reader doing a real REST integration, with low-code shown as an assistive option where it helps, not the primary way in.
Keep in sync owns the delivery-model decision (webhooks, the low-code receiver pattern, and polling as the fallback); Webhooks owns the delivery contract (the eight events, the HMAC signature, and idempotency).
What it touches¶
The shape is small: your systems call the Cognassist API outbound, Cognassist calls back to a webhook endpoint you register, and you match learners with a join key you already own.
flowchart LR
YOURS["Your systems<br/>(MIS, portal, reporting)"] -->|"Outbound HTTPS calls"| COG["Cognassist API<br/>(UK-hosted)"]
COG -->|"Assessment Completed<br/>webhook"| HOOK["Your webhook endpoint<br/>(or low-code receiver)"]How Cognassist is used shows the same picture across the full lifecycle, including where results flow into your delivery tools, BI, and exams process.
Three things, all standard:
- Outbound HTTPS from your systems to the Cognassist API. This needs no inbound firewall change; your systems open the connection.
- An inbound HTTPS endpoint to receive webhooks (the primary model). This does require inbound access: either an endpoint you host, which means an inbound firewall rule, or a low-code receiver in your own tenant such as Power Automate or Logic Apps, which needs no inbound change to your own network. Skip this only if you fall back to polling.
- A join key you already own. You match learners across systems using your own
clientReference(typically the learner's id in your MIS). Your organisation is a single client, so one credential set covers the whole organisation rather than one per site. Identifiers, enums, and how matching works are defined once in Core concepts.
Two identity and delivery choices are worth settling early with your team: single sign-on or email invites, and the invite email or an embedded assessment URL. Both are covered in Planning your integration. To get learners in from a file-only source, a one-way-in SFTP upload is a limited fallback.
Where the data lives and how it is protected¶
This is usually the heart of a due-diligence review.
Cognassist runs as a UK-hosted service, and learner data is processed in the UK. The credentials issued to your organisation are scoped to your organisation and that scope is enforced on every request; Core concepts is the canonical definition of what your credentials can see. A call can only ever return your organisation's learners, and there is no configuration in which one customer reaches another's data. Isolation is a platform-level access-control guarantee, not a setting your integration has to get right.
A cognitive profile is a signal, not a diagnosis and not a deficit label; it leads with strengths, and any support that follows is offered, not imposed. When a learner and their tutor agree a support plan, the learner's consent to share it is recorded at that point. This framing is deliberate and baked into how the product presents results; How Cognassist is used shows where it sits in day-to-day practice.
For information-governance and procurement checks, the authoritative documentation comes through your Cognassist contact rather than this site, so you always get the current version.
What to request from your Cognassist contact
- The data-protection and data-processing terms for your contract
- Current security and compliance documentation
- Data-retention arrangements
These are provided through your account or support route so they never drift out of date here. Confirm the exact route with your Cognassist contact.
You do not have to point a new integration at live learner data on day one; your team can build and check the connection against test data first. See Test safely for the recommended approach, and confirm the exact test-access setup with your Cognassist contact.
What is live today, versus planned¶
Everything described in these documentation pages is live and callable today: creating and managing learners, sending assessments and reading results, the narrative report, support evidence, bulk export, webhooks, single sign-on, and SFTP uploads. A few capabilities that come up in conversation, chiefly leadership dashboards as a queryable API, structured support-plan data, and cohort-level reporting endpoints, are planned rather than live, and are flagged wherever they appear. The roadmap lays out plainly what exists now and what is coming; if a capability is not marked as planned, it is available today.
Next steps¶
- Hand the technical pages to your team. Before you start sets out what a developer needs and in what order, and the integration checklist is the runbook.
- Read Core concepts for the identifiers, result codes, and access model the whole integration rests on.
- Ask about fit for your situation. For a view on your specific MIS and processes, ask your Cognassist account manager. The technical answer is on this site, so that conversation can focus on your specifics.
Phase 1 is a well-documented job your own team can self-serve, and you can stop there and still get value.