SCORM Webhooks: Event-Driven Tracking for Learning Content
Most SCORM hosting platforms give you a dashboard where you can look up completions after the fact. That works for manual review, but modern L&D operations need data to flow automatically — into CRMs, compliance databases, certificate generators, and analytics warehouses. Webhooks make this possible by pushing event data to your systems through signed, queued deliveries when tracked events are recorded.
Push vs Poll: Why Webhooks Matter
Without webhooks, the only way to get data out of your SCORM platform is to poll the API on a schedule — every minute, every five minutes, every hour. Polling is wasteful (most requests return nothing new), introduces latency (you only learn about a completion at the next poll interval), and creates unnecessary API load. Webhooks invert this: the platform queues a signed delivery when a tracked event is recorded.
This matters for operational workflows. A recorded compliance event can trigger a signed, retryable delivery without waiting for the next poll; actual processing time still depends on the queue and receiver.
Supported Event Types
AllureConnect supports the following webhook event types:
| Event | Fires when |
|---|---|
session.launched | A learner opens a SCORM session |
session.completed | A learner completes a course (status set to “completed” or “passed”) |
session.scored | A score is recorded for a session |
package.updated | A new version of a SCORM package is uploaded |
usage.threshold | Monthly launch count reaches 80% or 100% of plan limit |
You can subscribe to all events or select specific types. Most integrations start with session.completed and add others as workflows mature.
Setting Up Webhooks
Step 1: Register Your Endpoint
Create a publicly accessible HTTPS endpoint on your server that accepts POST requests. Then register it in the AllureConnect dashboard under Settings → Webhooks, or via the API:
curl -X POST https://app.allureconnect.com/api/v1/webhooks \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://yourapp.com/webhooks/allureconnect",
"events": ["session.completed", "session.scored"],
"description": "Production completion handler"
}'Step 2: Select Event Scopes
You can scope webhooks to specific packages or dispatches. For example, if you only want completion events for compliance courses, create a webhook that listens to session.completed and scope it to the relevant package IDs. This keeps your endpoint from receiving irrelevant traffic.
Step 3: Verify with a Test Event
After registering your webhook, use the Send test event button in the dashboard. AllureConnect sends a synthetic event to your endpoint so you can verify connectivity, response codes, and payload parsing before real learner data flows through.
Step 4: Handle Events in Your Backend
When an event fires, AllureConnect sends a POST request to your endpoint with a JSON payload. Every request includes an X-AllureConnect-Signature header containing an HMAC-SHA256 signature. Always verify this signature before processing the payload.
Here is an example payload for a session.completed event and the corresponding signature verification:
// Example webhook payload
{
"id": "evt_01HYX9K2M3N4P5Q6R7S8T9U0V1",
"type": "session.completed",
"createdAt": "2026-04-10T14:32:00Z",
"data": {
"sessionId": "sess_abc123",
"packageId": "pkg_def456",
"dispatchId": "dsp_ghi789",
"learnerId": "learner-42",
"completionStatus": "completed",
"successStatus": "passed",
"scoreRaw": 92,
"scoreMax": 100,
"totalTime": "PT12M34S"
}
}
// HMAC-SHA256 signature verification (Node.js)
const crypto = require('crypto');
function verifyWebhookSignature(payload, signature, secret) {
const expected = crypto
.createHmac('sha256', secret)
.update(payload)
.digest('hex');
return crypto.timingSafeEqual(
Buffer.from(signature),
Buffer.from(expected)
);
}Your endpoint should return a 200 status code within 10 seconds. If it returns a non-2xx status or times out, AllureConnect will retry with exponential backoff.
Retry Behavior and Dead-Letter Queue
AllureConnect retries failed webhook deliveries using exponential backoff: 30 seconds, 2 minutes, 10 minutes, 1 hour, then 6 hours. After 5 failed attempts, the event is moved to a dead-letter queue visible in the dashboard. You can manually retry dead-lettered events at any time, or configure a secondary fallback URL.
If your endpoint is consistently failing (5 consecutive failures across any events), AllureConnect automatically pauses the webhook and sends you an email notification. You can re-enable it from the dashboard once the underlying issue is resolved.
Common Use Cases
- Push completions to Salesforce — listen for
session.completed, map the learner ID to a Salesforce contact, and update a custom “Training Status” field. Enables sales teams to see which prospects have completed onboarding courses. - Trigger certificate generation— when a learner passes a course, fire a webhook to your certificate service. Generate a PDF, email it to the learner, and store a record for compliance audits.
- Sync to a data warehouse— forward all session events to a pipeline (e.g., Segment, Fivetran, or a direct Snowflake insert) for cross-platform learning analytics.
- Usage-based billing — use
session.launchedevents to track consumption per client and generate invoices based on actual usage rather than estimates. - Compliance alerts — combine
session.completeddata with due dates to identify learners who have not completed mandatory training and trigger escalation workflows.
Best Practices
- Always verify signatures. Never process a webhook payload without checking the HMAC-SHA256 signature. This prevents spoofed requests from triggering actions in your system.
- Respond quickly, process asynchronously. Return a
200immediately, then queue the event for background processing. Long-running synchronous handlers risk timeouts and retries. - Handle duplicates. Network issues can cause the same event to be delivered more than once. Use the event
idfield to deduplicate in your handler. - Monitor your dead-letter queue. Set up a weekly check (or an alert) for dead-lettered events. These represent data that did not reach your system and may require manual reconciliation.