Build on Auditori

Reading data

Every resource below, documented in full in the reference — every parameter, every field, every response shape. It is generated from our OpenAPI specification, so it cannot describe an endpoint that does not exist or omit a field a route returns.

• studentsread + writestudents:read
• enrolmentsread + writeenrolments:read
• coursescourses:read
• trainerstrainers:read
• venuesvenues:read
• employersemployers:read
• invoicesread + writeinvoices:read
• sessionsread + writecalendar:read
• webhooksread + write

Writing data

Create and update learners, enrol them into a scheduled session, and record unit outcomes. That last one is what most integrations are here for: it is the write that feeds AVETMISS, and it is the reason a marking tool or an LMS wants to talk to us at all.

curl -X PATCH https://app.auditori.com.au/api/v1/enrolments/{id} \
  -H "Authorization: Bearer auditori_sk_live_…" \
  -H "Content-Type: application/json" \
  -d '{"units": [{"id": "…", "outcome": "competent", "assessment_date": "2026-08-20"}]}'

Idempotency

Send an Idempotency-Key when you create something — any string unique to that request. A retry with the same key returns the original response instead of creating a second record. Without it, a connection that drops after we commit but before the response reaches you leaves you with a duplicate learner to find and merge, which is the ordinary behaviour of every HTTP client there is.

Reusing a key for a different request is refused rather than answered — you would otherwise believe your second write happened. Updates need no key: setting named fields to given values is already safe to repeat.

Validation

An outcome must be one of the six we report on. A unit that is not on the enrolment you named comes back as an error listing it, not as a silent skip — reporting success for an outcome that was never recorded is the worst possible answer for compliance data. Plan limits apply here exactly as they do in the app, so an integration is never a way around a cap you would hit in the UI.

Webhooks

Rather than polling for changes, have us tell you. Add an endpoint under Settings → Webhooks and we will POST a signed JSON body the moment something happens.

Verifying the signature

Every request carries x-auditori-signature, an HMAC-SHA256 of timestamp.bodyusing your endpoint’s signing secret. The timestamp is signed along with the body, so reject anything more than a few minutes old and a captured request cannot be replayed at you later.

const ts  = req.headers['x-auditori-timestamp']
const sig = req.headers['x-auditori-signature']

const expected = crypto
  .createHmac('sha256', process.env.AUDITORI_WEBHOOK_SECRET)
  .update(`${ts}.${rawBody}`)
  .digest('hex')

// Constant-time, and check the age.
if (!crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected))) return res.status(400).end()
if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return res.status(400).end()

Managing subscriptions

An integration can manage its own subscriptions with an API key — POST /api/v1/webhooks to subscribe and DELETE /api/v1/webhooks/{id} to stop. The signing secret comes back once, on creation.

Each event needs the read permission for the data it carries: a key that cannot read invoices cannot arrange to be sent them. Omit events and you get everything that key is allowed — which is not necessarily everything. GET /api/v1/webhooks tells you which events the key may have, so you can offer a picker rather than guess and be refused.

Zapier

Those two endpoints are what a Zapier app subscribes and unsubscribes with, which is why our integration triggers within seconds rather than on a polling interval. Triggers for every event above; actions to create and update learners, enrol them and record outcomes; and a search so a Zap can find a learner before acting on one.

Retries

Answer with any 2xx and we consider it delivered. Anything else is retried with backoff — roughly a minute, then five, twenty-five, two hours, ten hours — for six attempts. An endpoint that keeps failing is switched off and shown as such in your settings, rather than us retrying a dead URL forever. Turn it back on once your receiver is healthy.

Deliveries are at-least-once. Treat x-auditori-delivery as an idempotency key if processing the same event twice would matter to you.

MCP server

Auditori speaks the Model Context Protocol, so an AI assistant can answer questions against your own data — “which students are missing a USI, and which trainers have credentials expiring before the next scheduled session?” — without you opening three screens to piece it together.

It uses the same API key, the same scopes and the same plan limits as the REST API. An assistant can only ever see what that key allows.

{
  "mcpServers": {
    "auditori": {
      "url": "https://app.auditori.com.au/api/mcp",
      "headers": { "Authorization": "Bearer auditori_sk_live_…" }
    }
  }
}

One read tool per endpoint above — list_students, list_enrolments and so on. Results are capped and say so when they are truncated, so an assistant knows when it is looking at part of the picture rather than reasoning confidently over a subset.

Write tools

Four write tools — create_student, update_student, enrol_student and record_outcomes — each doing one thing to one record. There is no bulk update and no delete, because the way an assistant goes wrong is rarely one bad field: it is a confident sweep across a hundred rows.

You decide whether this is on at all. The write tools refuse unless the key carries students:write or enrolments:write. Mint a read-only key for your assistant and it can answer questions and change nothing. Every call — read or write — is logged against that key and visible under Settings → API keys, so you can see afterwards exactly what it did.

Values are checked rather than trusted. An outcome must be one of the six we report on, and a unit that is not on the enrolment is refused rather than skipped — a model offering a plausible-sounding "passed" gets an error, not a row in your AVETMISS file.

Course packages

A generated learner guide can be exported as a SCORM 1.2 package and imported into Moodle, or whatever LMS you already run. One page per section, so your LMS builds its own contents list, and the pages load nothing from the network — they work inside a sandboxed course player.

GET https://app.auditori.com.au/api/generate/{session_id}/scorm

1.2 rather than 2004 on purpose: every LMS imports it, and 2004’s sequencing model buys nothing for a linear guide. Requires an active plan or credits — a package is delivered to learners, so unlike a PDF there is no watermarked version that makes sense.

xAPI

The same guide is also available as an xAPI (Tin Can)package. The difference is not the content, it is where the record lands: SCORM reports into whichever LMS is playing the guide, while xAPI posts statements to a Learning Record Store that may be somewhere else entirely. That is usually the reason to want it — completions from several vendors’ content arriving in one store.

curl https://app.auditori.com.au/api/generate/{id}/xapi -o guide-xapi.zip

Both are in the download menu next to the PDF and DOCX exports once a learner guide has been generated. Activity ids are stable across exports, so two deliveries of the same guide report against the same activity rather than looking like unrelated content.