Low-code as an assistive option

Most Cognassist integrations are a direct build: your systems call the REST API to put learners in and read results back, and Cognassist pushes events to a webhook endpoint you own. That is the primary pattern, and the rest of these guides are written for the developer doing exactly that. Start with the Integration checklist for the ordered runbook and Webhooks for the delivery model.

Low-code tools are a secondary, assistive enabler, not a separate way to integrate. They earn their place in two specific situations:

• Receiving webhooks when you cannot host a public HTTPS endpoint. A common on-prem constraint. A low-code flow such as Power Automate's When a HTTP request is received trigger, or an Azure Logic App, gives you a public URL to register with Cognassist so you can still use the webhooks-first pattern. This is a helper to receive webhooks, covered in full on the Webhooks page.
• Bridging a file-only source into the API. If a source system can only emit a CSV, a low-code tool can read that file and call POST /v1/learners for each row, so you keep the API's type checking, your own join key, and downstream events.

Everything below builds on the same REST API used everywhere else, driven from a low-code tool instead of your own code. If your team writes code against the API directly, you do not need this page.

The core pattern: authenticate once, reuse the token

Whether you drive the API from code or from a low-code flow, the shape is the same: make one call to get a bearer token, cache it, and reuse it on every later call until it nears expiry. The Getting started page is the canonical home for the auth flow and token lifetime; this section shows how the same steps map onto a low-code flow.

In a low-code tool, do not reach for a prebuilt or custom connector first. A plain HTTP action that calls the authentication endpoint and stores the returned token in a variable is the reliable, supported approach, and it mirrors exactly what a hand-written integration does.

curlPower Automate / Logic Apps

# 1. Get a token
curl -X POST https://api.uk.cognassist.com/v1/auth \
  -H "Content-Type: application/json" \
  -d '{ "clientId": "your-client-id", "clientSecret": "your-client-secret" }'

# Response: { "accessToken": "eyJhbGciOiJI...", "expiresIn": 36000 }

# 2. Reuse the token on later calls
curl -X POST https://api.uk.cognassist.com/v1/learners \
  -H "Authorization: Bearer eyJhbGciOiJI..." \
  -H "Content-Type: application/json" \
  -d '{ "firstName": "...", "lastName": "...", "email": "...", "clientReference": "..." }'

1. Authenticate. An HTTP action calls POST /v1/auth with your clientId and clientSecret in the body and Content-Type: application/json.
2. Capture the token. A Parse JSON action reads accessToken out of the response, then Initialize variable accessToken to body('Parse_JSON')?['accessToken'].
3. Reuse it. On every later HTTP action, set the header Authorization to Bearer @{variables('accessToken')}.
4. Re-authenticate only near expiry. The response includes expiresIn (lifetime in seconds). Cache the token and fetch a new one only as it nears expiry, not per call.

The worked example in Power Automate shows each of these actions on screen.

For anything on a schedule or using the OAuth 2.0 client-credentials grant, author the flow as an Azure Logic App. Logic Apps are the better home for timed jobs and use the same HTTP actions shown above. For the request and response schemas of any endpoint, use the API reference; this page does not reproduce them.

Which low-code tool, if you have a choice

Tool	Best when
Microsoft Power Automate	You run Microsoft 365 and want light, event-driven or scheduled flows in your existing tenant.
Azure Logic Apps	You want scheduled or client-credentials jobs, and prefer them in Azure alongside the same HTTP actions.
n8n (self-hosted)	You want to self-host and keep flows on your own infrastructure. Its OAuth 2.0 client-credentials support works with POST /v1/auth out of the box.
Make, Zapier, Boomi, Workato	You already run one of these. Import the same OpenAPI spec.

Organisations that already run Microsoft 365 and Entra ID often stay in Power Platform because it is already licensed and governed and keeps data in the tenant's home region. There is no requirement to use it, and it is not the default way to integrate; pick whatever your team already operates.

If your governance mandates a custom connector, plan for two caveats

The explicit-HTTP pattern above avoids both of these, which is why it is the recommended route. A custom connector is only worth attempting if your governance requires one.

1. Custom connectors do not support the OAuth 2.0 client-credentials grant that the Cognassist API uses. You would still fetch the token with an explicit HTTP step, so the connector buys you little over the pattern above. Authoring the flow as an Azure Logic App removes this limitation entirely.
2. Custom-connector import accepts OpenAPI 2.0 (Swagger) only. The Cognassist spec is OpenAPI 3.0.1, so it must be down-converted to 2.0 before import, for example with a converter such as APIMatic or Swagger's own tooling. Logic Apps, n8n, and raw HTTP paths are unaffected.

These two caveats are the reason to prefer plain HTTP actions or a Logic App over a custom connector.

Use 1: receive webhooks without hosting a service

Webhooks are the primary way to learn that something happened (a learner completed the assessment, a report is ready, an evidence export finished). If you cannot host a public HTTPS endpoint to receive them, a low-code flow gives you one.

The shape is: create a flow triggered by When a HTTP request is received, register the URL it generates with POST /v1/webhooks, then in the flow verify the x-cognassist-sha256 signature, skip any DataId you have already processed, and do your work. The delivery model, the eight events, the signature check, and the full receiver walk-through all live on the Webhooks page and its receive-a-webhook section. Follow that page for this; do not treat the flow as a different integration method.

A common recipe: scheduled evidence export, delivered to a low-code receiver

A bulk evidence export is asynchronous: you request it with one call, and the finished payload arrives on your webhook, not in the response. So it pairs naturally with a low-code receiver.

1. Subscribe first. Register your receiver URL for the Learner Export Completed event (700) with POST /v1/webhooks, before you request an export. Subscribing after you trigger means the event can fire before your endpoint exists.

2. Request the export on a schedule. A scheduled HTTP action calls the export endpoint:

   curl -X POST https://api.uk.cognassist.com/v1/learnerexports \
     -H "Authorization: Bearer eyJhbGciOiJI..." \
     -H "Content-Type: application/json" \
     -d '{ "exportFromDate": "2026-04-01", "exportToDate": "2026-04-30" }'
   

3. Catch the finished file. The full payload arrives on your receiver. Verify the signature, then feed the records into your own funding and audit evidence processes.

The response returns a request identifier only. See Export evidence and data for the end-to-end guide and Webhooks for the payload and signature. Your credentials only ever return your own organisation's learners and records, so treat the returned payload as the authoritative set for the date range rather than expecting a specific learner to appear; the access model is explained once in Core concepts.

Use 2: bridge a file-only source into the API

If a source system can only emit a CSV, prefer bridging it through the API over a batch file. Point your low-code tool at the file, transform each row, then call POST /v1/learners. You keep the API's type checking, a stable match on your own clientReference, TLS in transit, and the downstream webhook events a plain file drop would not give you.

The identifiers behind this (why clientReference is your join key, and why the paged learner list matches on email because the list rows do not carry clientReference) are explained once in Core concepts, and the reconcile loop lives in Create and manage learners. This page does not restate them.

Bridging the file through the API this way is preferable to a batch file drop. To get learners in where a source cannot make an HTTPS call at all, a one-way-in SFTP upload is a limited fallback.

Planned: downloadable recipe files

Ready-made recipe files (a Power Platform solution, an n8n workflow JSON, and a Logic Apps template) are planned, not available today, so you can eventually import a starting point rather than build one. The OpenAPI spec every recipe builds on is available now, and the worked example in Power Automate already covers the flow step by step. Track this on the Roadmap.

For partner-built integrations that may already cover your platform, see the Integrations overview.