Before browser APIs, JavaScript bridges, or client-side tracking, AICC courses talked to the LMS through something beautifully simple: plain HTTP POST requests.
This mechanism was called HACP, short for HTTP AICC Communication Protocol. It was a lightweight, server-based way for learning content to exchange information with an LMS, using the same basic principles that still power web communication today.
đ¨ The Essence of HACP
Every Assignable Unit (AU), meaning every lesson or training module, could report its status directly back to the LMS using a simple HTTP call.
When a learner launched a course, the LMS generated a unique session ID and passed it to the content. The content then used that ID whenever it needed to send updates back.
Each update was a small, human-readable message: a set of key-value pairs like:
AICC_SID=123456
AICC_DATA=core_lesson_status=completed,core_score.raw=95
The content would send this data using a POST request to the LMSâs communication URL (the AICC_URL).
The LMS would process it, update the learner record, and respond with a simple âOKâ, or an error if something went wrong.
No browser scripting.
No LMS plugins.
No version-specific JavaScript APIs to maintain.
Just the web, as it was meant to be used: requests and responses.
𧊠Why HACP Mattered
In an era before widespread JavaScript adoption, HACP was remarkably forward-thinking.
It separated presentation from communication, allowing content to run in any environment capable of sending HTTP requests: Windows, Mac, or even standalone CD-ROM players that used dial-up callbacks.
This approach also made debugging and integration straightforward. Developers could inspect the raw messages being sent, reproduce them with tools like
curl
, and clearly understand what the LMS expected in return.
AICC effectively built one of the earliest forms of stateless web APIs for learning, long before REST became a buzzword.
đ Reliability Through Simplicity
HACP worked because it relied on the webâs most universal primitive: the POST request.
It didnât try to control the browser. It didnât embed logic inside the course. Instead, it let each system do what it did best:
The content gathered learner data.
The LMS stored and interpreted it.
HTTP handled the communication.
And that was enough.
In modern terms, it is similar to designing an API that does not need SDKs or libraries, only the core protocol itself.
Thatâs why, even today, many LMSs still support HACP as a fallback or legacy option. It just works.
đĄ Developer Reflection
AICCâs approach reminds us that powerful systems donât always need complex technology.
Sometimes the simplest protocols (the ones you can explain in a paragraph) are the ones that endure the longest.
Itâs a humbling reminder that clarity scales better than cleverness.
When was the last time you designed something so straightforward that it could still run thirty years later?
đ Whatâs Next
Next week, weâll dig into the AICC Data Model, the structure that defined what information was exchanged through HACP: learner status, scores, time spent, and more.
Youâll see how this early model laid the groundwork for SCORMâs CMI structure and even echoes in modern xAPI statements.
đ˘ 3 of 8 | AICC â The Origins of E-Learning Standards
