An LMS API lets your product create users, enroll them in courses and read completions back, with no one opening the LMS admin screen. Whether a vendor’s API can carry that integration depends on four answers, and they often sit outside the reference docs. You need the rate limit on the tier you’re quoted, what a webhook does when your receiver goes down, the OAuth grant it supports, and whether the API is on your plan at all. Miss one, and the build stalls after the contract is signed.
This guide gives you the endpoints to check by object, the four answers with vendors’ own figures, and twelve questions for the demo.
Key Takeaways
- Check four objects first (users, enrollments, completions and events), since each missing call becomes manual work.
- Docebo’s docs say not to assume a fixed rate limit, but its pricing page prints 100 calls a minute for Enterprise.
- Docebo deactivates a webhook when a single message fails to deliver over 60 hours.
- API access is a plan line at SkyPrep (Premium, not Lite) and Continu (Enterprise), so check the tier in your quote.
Try Mini Course Generator free – build a course from the help docs you already have and embed it in your product.
What an LMS API Lets Your Product Automate
For a product team, an LMS API does four jobs, and each one turns a product event into an LMS call.
| Product event | LMS API call | What comes back |
|---|---|---|
| A user signs up or starts a trial | Create the user, then find them by your own ID | The LMS user ID to store beside yours |
| A user reaches a plan, role or feature | Assign the user or their account’s group to a course | An enrollment |
| A user finishes a course | Receive a completion event, or poll for recent completions | Status, timestamp, score, certificate |
| Nightly, for reporting | Export activity in bulk | Rows for your warehouse or analytics |
Two LMS words carry most of the weight. An enrollment is the record that ties one user to one course or learning path, with a status and often a due date. A completion is that record changing state, usually with a timestamp and a score, and it’s what the certificate comes from.
If the rest of the vocabulary is new, what an LMS does covers it in one read.
Not every flow needs your code. A completion that only has to update one field in another tool runs fine through Zapier or Make. The LMS integration guide lays out the choice between a connector, an automation platform and a custom build.
The API earns engineering time when your product itself calls the LMS, whether that’s creating users at signup, deciding enrollments from product data or showing progress in your own interface. That’s the headless LMS pattern.
Write your three or four flows in that table’s shape before you open anyone’s docs, because every row becomes an endpoint you have to find.
The Endpoints to Check, by Object
Vendors describe their APIs as “user management” and “reporting,” labels that hide whether the call you need exists. eLeaP’s API reference names every call, so the table below uses its names as a worked example of a complete set.
| Object | Calls you need | eLeaP’s names for them | What to check in any vendor’s docs |
|---|---|---|---|
| Users | Create, read, find, update, deactivate | Add, Get, Find, Edit, Activate, Deactivate, Remove, Custom Fields | Find works with your own ID, not only email. Custom fields hold your account ID |
| Enrollments | Assign or unassign a user or group, list who’s assigned | AssignUser, UnassignUser, AssignUserGroup, AssignedUsers, on Courses and Learning Paths | A group call exists, so one request enrolls a whole account |
| Completions and activity | Recent completions, activity, bulk export, certificates | Recent Completions, Activity, Export Activity, Export Certificate | The time window each call covers, and a bulk call for backfill |
| Events | Subscriptions to completion and enrollment events | None in its reference | Event names, payload fields and failure behavior |
Two details in that set change how you build. The first is timing. eLeaP’s Recent Completions returns courses completed in the last 24 hours, and its reference has no webhooks, so completions reach your product by polling.
A sync job that fails for more than a day misses records unless you backfill from Export Activity. Ask every vendor the same pair of questions: what window does the “recent” call cover, and which call backfills?
The second detail is offboarding. eLeaP offers both Remove and Deactivate for users, so when a customer churns or a seat moves, check which call the vendor recommends and whether the user’s completion records survive it.
In the demo, open the reference beside this table and tick each row. A row with no call becomes a manual job for someone on your team, or a vendor ticket every time it comes up.
Which Auth Model You’re Building Against
This section is about how your servers authenticate to the API. How your users sign in to the courses is a separate integration, and the LMS SSO guide covers it.
| Pattern | Vendor example | What it means for your build |
|---|---|---|
| OAuth 2.0 authorization server | Docebo runs what it calls “a full-fledged OAuth 2.0 server.” A legacy key and secret still work, but Docebo “strongly recommend[s] updating your clients to OAuth2” | Token requests and expiry live in your client. An integration on the legacy key needs a migration plan |
| One token on every request | eLeaP requires an api_token parameter on all requests, issued to an administrator under Company Profile > API |
Quick to start. It’s one account-wide credential, so decide who holds it and what happens if it leaks |
| HTTP Basic with key and secret | Learnifier joins key and secret with a colon, Base64-encodes them and sends them in the Authorization header. Its older X-Authentication header is deprecated | No token exchange. The secret travels with every call, so it stays on your server |
Then check the grant. For a sync that runs on your servers with no user at the keyboard, the grant built for the job is Client Credentials. RFC 6749 says it “MUST only be used by confidential clients.” That means a backend that can keep a secret, never your front end or a mobile app.
Some setup guides have you trade an admin’s username and password for a token. That’s the resource owner password credentials grant, and RFC 9700, the IETF’s 2025 OAuth security best practice, says it “MUST NOT be used.” Treat it as an item for your security review, not a detail for the sprint.
Docebo’s setup guide doesn’t list the grants it accepts. It tells you to “double-check the grant types” when you create the app, so the list is a question for the demo. Ask which grants the authorization server accepts, how long access tokens live and whether a client can be read-only, then put the answers in the scoping ticket before anyone estimates the work.
Webhooks: What Happens When Your Receiver Is Down
A webhook is only as reliable as its failure policy, and that’s the part vendors document least. Docebo documents its own in unusual detail, which makes it a good list of what to ask everyone else.
| Question | Docebo’s documented answer | What to build or ask |
|---|---|---|
| How many events and webhooks? | Up to 8 events per webhook and 10 webhooks enabled at once, 80 events in total. Raising the limit goes through the account manager | Count your event types before designing one webhook per event |
| How fast do events arrive? | About one message per second | Bulk actions arrive slowly, as the example below shows |
| What counts as delivered? | A 2xx or 3xx reply within 5 seconds. A 4xx or 5xx is logged as a failure, and a slow reply triggers a reschedule |
Store the event, acknowledge it, then process it |
| Can one event arrive twice? | Yes. Docebo tells receivers to be idempotent and to spot duplicates by message id | Keep a record of processed message ids |
| When does it give up? | If a single message fails to deliver during a 60-hour period, the webhook is deactivated | Alert on the “Webhook disabled by the system” entry in the audit trail |
| How does the receiver know it’s genuine? | Optional basic auth over HTTPS. When you rotate the password, Docebo advises keeping the old one valid for a while | Ask whether payloads are signed |
| Is queue delivery available? | SQS and EventBridge depend on the pricing plan, and a webhook’s type can’t be changed after saving. Docebo retries queue webhooks 5 times, and AWS tries each 3 times, for 15 attempts | Confirm the delivery type on your quote first |
Two worked examples show why those numbers matter. Both are illustrations built on Docebo’s documented figures, not measurements.
A weekend outage. Your receiver fails on Friday at 6 p.m., and nobody notices until Monday at 9 a.m. That’s 63 hours, so any message that started failing before 9 p.m. on Friday has crossed the 60-hour line, and under Docebo’s policy the webhook is off.
New events stop arriving, and your product shows stale progress until someone re-enables the webhook and backfills from the API. Uptime monitoring on your receiver catches the outage on Friday evening. The alert on the deactivation entry is the backstop for when that monitoring misses it too.
A bulk enrollment. A customer’s admin enrolls 3,000 users at once. At about one message a second, 3,000 separate messages take 50 minutes to arrive.
Docebo can group several events into one message, where the payload field becomes payloads. That may speed delivery up, but your interface still shouldn’t promise instant progress after a bulk action.
Before you sign, get the failure policy in writing: the reply window, the retry schedule for your delivery type, the deactivation trigger and how you’ll be told. Then build the receiver to survive it.
Rate Limits: Find the Number for Your Tier
The rate limit decides how you design the integration, and it’s often printed somewhere other than the API reference.
| Vendor | Published limit | Where it’s printed |
|---|---|---|
| eLeaP | 2,500 requests an hour, then a 429 |
API reference |
| Litmos | “APIs (up to 100 RPM per site)” | Pricing page, on all three tiers |
| Docebo | 100 calls a minute on Enterprise, as “Upgraded API access.” No figure for Elevate | Pricing page. The developer docs say not to assume a fixed quota |
| Continu | No figure | Not on its pricing page |
| SkyPrep | No figure | Not on its pricing page |
Docebo’s split is the lesson. Its developer docs describe a token bucket and tell clients not to assume “any fixed rate window or quota.” A 429 comes back with no Retry-After header, no remaining quota and no reset time.
RFC 6585 allows that, since it says a 429 response “MAY include a Retry-After header.” The number you can plan around sits on the pricing page, tied to a tier.
So your client needs its own backoff. Docebo suggests jittered delays that roughly double each time. They start at 500 to 1,000 milliseconds, reach 8 to 16 seconds, cap at 30 to 60 seconds and stop after five to seven attempts. That’s a sensible default for any LMS API that won’t tell you when to retry.
Worked example: one sync, two limits. Say you sync 3,000 users every night with one call per user.
- At 100 calls a minute, the job takes 30 minutes.
- At 2,500 requests an hour, the last 500 calls get a
429and wait for the next hour. - If each lesson view in your product makes two live calls, 100 a minute covers 50 views a minute for all users.
That last line is the design rule: don’t call the LMS API in your product’s request path. Cache enrollments and progress on your side, update them from webhooks, and keep API calls for writes and the nightly check.
Ask for the limit on the tier you’re quoted, per minute and per hour, and whether it counts per site or per account. If it isn’t in the order form, you can’t plan around it.
Is the API on Your Plan, and Can You Reach the Other System?
Two access questions come before any code. Does your tier include the API, and does the system on the other end let you in?
On the first, API access is a plan line at several vendors, as printed on their pricing pages:
- SkyPrep lists “API and SSO” on Premium, and its entry Lite tier includes neither.
- Continu lists API access, webhooks and an extra sandbox on Enterprise, its top tier.
- Docebo lists two sandboxes on Enterprise, the same tier that carries its rate limit.
- Litmos lists APIs and webhooks on all three of its tiers.
The sandbox matters as much as the API. Without one, your first integration test runs against production users and real completion records.
The second question applies when your plan also touches an HR or payroll system. Paylocity, an HR and payroll platform, restricts its LMS API to “LMS providers that have signed a Paylocity technology partnership agreement,” and those endpoints only create and read training content.
You can’t get that access by creating a key. Ask the LMS vendor whether it’s a signed partner of the system you need, and what the connection moves.
Put both answers in the evaluation doc: the tier that carries the API, the sandbox and queue delivery, and every partnership your plan depends on. If you’re tracking several vendors, the LMS requirements checklist has rows for the API and webhooks.
The Pre-Signing Question List
Copy these into the vendor call. Each one comes with the kind of answer you can build on.
| Area | Question | A usable answer |
|---|---|---|
| Endpoints | Which calls create, find, update and deactivate a user? Does find accept our own ID? | The call names and the ID field |
| Endpoints | How does one request enroll a whole customer account? | A group or bulk assignment call |
| Endpoints | How do completions reach us, and what window does the “recent” call cover? | A webhook event, or a polling call with a stated window |
| Endpoints | Where does a certificate come from? | A call or a payload field your product can read |
| Auth | Which OAuth grants do you accept? Can a client be read-only? | Client Credentials, and named scopes |
| Auth | How long do access tokens last? What’s the plan for legacy keys? | A lifetime and a stated deprecation plan |
| Webhooks | What reply counts as delivered, and how long do you wait? | A status range and a timeout in seconds |
| Webhooks | What’s the retry schedule, and when do you deactivate a webhook? | Numbers, plus the alert you send |
| Webhooks | How can our receiver confirm a payload came from you? | Signed payloads, or basic auth over HTTPS |
| Limits | What’s the rate limit on our tier, per minute and per hour? | A number that goes into the order form |
| Limits | What does your 429 response include? |
A Retry-After header, or a backoff schedule |
| Access | Which tier includes the API, a sandbox and queue delivery? Are you a partner of the systems we need? | Tier names, and a yes or no per system |
The non-technical half of the demo script is in LMS demo questions. In a formal process, these twelve belong in the technical section of an LMS RFP template, and your security team’s review has its own LMS security checklist.
Where Mini Course Generator Fits
Mini Course Generator is our product, and the list above applies to it the same way. Its REST API and Headless LMS are on the Custom plan, along with SSO for learners. That plan is scoped in a demo, so bring these twelve questions to the call.
Webhooks sit lower than the API, on the Pro creator plan and every business plan. If all you need is a completion reaching another tool, Automations handles it on Zapier or Make with no API work. MCG has no native HR system or CRM connector and no SCIM provisioning, so those flows go through webhooks, an automation platform or the API.
There’s also a different kind of automation. The Mini Course Generator MCP Server lets AI assistants such as Claude, ChatGPT and Cursor connect over OAuth, then create, edit, publish and manage courses in your account. It automates building and updating courses, not syncing users, so it sits beside an API integration rather than replacing one.
Get Four Answers in Writing Before Anyone Writes Code
Before you sign, open the API reference and tick the four objects: users, enrollments, completions and events. Then get four answers in writing: the rate limit on your tier, the webhook failure policy for your delivery type, the OAuth grant your servers will use, and the tier that carries the API and a sandbox.
If a number isn’t in the order form, design for the worst case. And if the plan is courses inside your own product, run this list against a headless LMS platform for in-app training and see how the courses render where your users already work.
Frequently Asked Questions
Is the LMS API the same thing as SSO?
No. The API is how your servers read and write LMS records, using a credential your backend holds. SSO is how your users sign in to the courses with the login they already have, so they never see a second password. Some vendors put both on the same tier, as SkyPrep does with “API and SSO” on Premium, but you build and test them as two integrations.
Do you still need polling if the LMS sends webhooks?
Keep a nightly reconciliation job anyway. Docebo’s webhooks can deliver an event twice and can switch off after a long outage, as the weekend example shows. A scheduled call that checks recent completions against your records catches what the events missed. Where a vendor sends no webhooks at all, as with eLeaP, polling is the whole integration.
What if the vendor changes its API after you’ve built on it?
Authentication is where it has already happened at two vendors in this guide. Docebo still accepts its legacy key and secret but strongly recommends moving clients to OAuth 2.0, and Learnifier has deprecated its older X-Authentication header in favor of HTTP Basic. Ask how much notice the vendor gives before it retires an endpoint or an auth method, and get that notice period into the contract.
Do you need an LMS developer to build the integration?
No. The developer your team assigns needs REST, OAuth and a reliable webhook receiver, not LMS experience. Hiring a specialist LMS developer makes sense when you’re building the learning platform itself. That’s a different decision, with its own build-your-own-LMS costs.
What should you test in a vendor’s sandbox?
Your own flows, end to end, rather than the vendor’s sample calls. Create a user with your own ID, and enroll a group of realistic size to watch how the events arrive. Then stop your receiver to see how the failure gets logged, and send a burst of calls to see what a 429 looks like. A trial without API credentials tests the admin screens, not your integration.
Sources
- RFC 6749 – The OAuth 2.0 Authorization Framework, IETF
- RFC 6585 – Additional HTTP Status Codes, IETF
- RFC 9700 – OAuth 2.0 Security Best Current Practice, IETF, 2025
- Docebo developer documentation: activating and managing the API and SSO app, creating and managing webhooks, and handling API rate limits
- Docebo pricing page
- eLeaP API documentation
- Learnifier API documentation
- Paylocity developer documentation, LMS API overview
- Litmos plans and pricing
- Continu pricing
- SkyPrep pricing
- Vendor pricing pages and developer documentation read September 2026
