Grow LMS API Documentation

Grow by Plenum — Data Integration Overview

How Grow moves training data into and out of your systems.

This document explains, at a working level, how Grow by Plenum exchanges data with the systems your organization already runs — your data warehouse, HRIS, identity provider, BI tooling, and compliance reporting. It is written for a mixed audience: the executive who needs to know whether a capability exists, and the systems analyst or data engineer who needs to know how it behaves in practice.

Throughout, <SCHOOL_ID> refers to your organization’s dedicated Grow environment. Plenum provisions and operates this environment on your behalf; you receive the credentials and endpoints specific to it during onboarding.


1. The short version

Grow is built to be integrated, not islanded. Training and compliance data does not have to live only inside Grow — it can flow continuously into the systems your business already trusts for reporting, auditing, and decision-making.

There are two directions of data flow, and Grow supports both:

  • Push (real-time): the moment something happens in Grow — a learner completes a course, earns a certificate, gets enrolled or unenrolled — Grow can send a signed, structured notification to an endpoint you control, in near real time. No polling, no waiting for a nightly batch.
  • Pull (on-demand): your systems can query Grow directly for the current state of any record — a learner’s progress, their enrollments, their certificates, their profile — whenever you need it, on whatever schedule you choose.

Most production integrations use both: push for timeliness, pull for reconciliation and backfill. The rest of this document explains each.


2. Push: real-time event delivery

When a meaningful event occurs in your <SCHOOL_ID> environment, Grow can deliver a notification to a URL you specify (commonly called a webhook). The notification is an HTTP POST carrying a structured payload that describes exactly what happened and to whom.

What this is good for: keeping a downstream system — your data warehouse, an HRIS, a compliance tracker — current in near real time without continuously asking Grow “has anything changed?”

Events Grow can push

The events most relevant to a compliance-training and workforce-readiness program include:

Event What it tells you
Course completed A learner finished a course. The payload distinguishes a naturally earned completion from an administratively applied one (an manually_completed flag), so your audit trail can tell the two apart.
Certificate awarded A certificate was issued to a learner — the trigger for renewal clocks, badge systems, or downstream credential records.
User updated A learner’s profile changed (contact details, attributes, custom fields).
Unenrolled from a product A learner lost access to a course or bundle.
Tag added / tag removed A classification label was applied to or removed from a learner — useful when you drive cohorts, regions, or job roles off tags.
Learning program completed A learner finished a multi-course program or learning path.

How you know the data is genuine

Every pushed notification is cryptographically signed. Grow includes a signature header derived from a secret that only Grow and your receiving endpoint share. Your endpoint recomputes the signature over the received payload and compares — if they don’t match, the message is rejected. This means a third party cannot forge a “course completed” event into your pipeline, and you can trust pushed data as authoritative.

One-time setup, then it just runs

Subscribing your endpoint to these events is a configuration step Plenum performs once during onboarding for your <SCHOOL_ID> environment. After that, delivery is automatic and ongoing. There is nothing your team has to operate day-to-day on the Grow side.


3. Pull: querying Grow directly

Alongside real-time push, Grow exposes a secured API that your systems can query directly to read the current state of records. This is the path you use to pull data on a schedule, to backfill history, or to answer a specific question on demand.

The records most organizations pull are:

  • Learner progress — per course, per section, and per individual unit: whether a learner has started, their completion status, percent-complete, average assessment score, time spent, and the timestamp of completion.
  • Enrollments — which learners have access to which courses, bundles, and programs.
  • Certificates — what has been issued, to whom, and when.
  • Learner profiles — identity, contact, attributes, tags, role level, and any custom fields you maintain.
  • Course catalog — the courses available in your environment and their current state (e.g. published, draft, closed).

Reconciliation: the safety net under push

Grow also exposes an event log that can be queried by activity type and by time window (everything that happened after a given moment, before a given moment, or for a specific learner). This is the recommended reconciliation path: if a downstream system was offline when a real-time push was sent, you replay the event log for the gap and catch up with confidence. Push keeps you current; the event log guarantees you never permanently miss anything.

Access and pace

Access to the API is authenticated and scoped to your <SCHOOL_ID> environment — covered in detail in the companion Authentication & Access Setup document. On throughput: Grow has comfortably sustained continuous extraction at production scale in Plenum’s own operations. We have not encountered a rate ceiling in normal integration use; if your use case involves unusually high-volume polling, we’ll size it with you during integration design rather than have you discover a limit in production.


4. What the data looks like

A few characteristics of Grow’s data model are worth knowing up front, because they shape how you design the downstream side:

  • Completion and access are timestamped separately — and they are different things. Completion is recorded on the progress record as a definitive completed-at timestamp (a Unix epoch value, empty until completion actually occurs) — this is the field your compliance and renewal logic should key off. Access is tracked on the enrollment record, which carries its own granted and expiry timestamps. Keeping the two distinct lets you answer both “has this person finished?” and “does this person still have access?” without conflating them.
  • Progress is granular. You are not limited to a single “done / not done” flag. Status resolves to not started, completed, or not completed, and is available broken down to the individual unit within a course — so you can report on partial progress and stalled learners, not just finishers.
  • Identity is rich. Learner records support tags, role levels, attribution data, and custom fields, which means you can carry your own organizational structure (region, crew, job classification, contractor vs. employee) inside Grow and have it travel with every record you pull.

The field-level specifics for each record type are documented in the companion Data Schema Reference; this overview is intentionally about shape and flow rather than every field.


5. Identity and single sign-on

Grow supports enterprise single sign-on so your people sign in with the credentials they already have, and so access can be governed centrally by your IT organization. Both major standards are supported — SAML and OIDC — and there is a dedicated, documented path for Google Workspace. Plenum has implemented standards-based SSO of this kind on prior engagements and will map it to your identity provider during onboarding.

Full configuration detail lives in the companion SSO & Identity Integration document.


6. Security and hosting posture

For the IT and security reviewers in the room:

  • Hosting: Grow runs on Google Cloud Platform and inherits that platform’s compliance posture, including SOC 2 / SOC 3 and ISO 27001.
  • Encryption in transit: TLS 1.2 throughout.
  • Payment data: card handling is fully offloaded to dedicated payment processors (Stripe / PayPal) and never touches the learning platform layer — relevant if any part of your program involves paid enrollment.
  • Data authenticity: as described in Section 2, real-time event delivery is HMAC-signed, so pushed data is verifiable rather than trusted blindly.

7. Where to go next

This overview is the front door. The companion documents go a level deeper on the topics your team is most likely to drill into:

  1. Authentication & Access Setup — how systems securely connect to your <SCHOOL_ID> environment.
  2. Real-Time Data: Webhooks — the full event catalog, payload structure, and signature verification.
  3. Pull-Based Data Access — the queryable record catalog, pagination, and the event-log reconciliation pattern.
  4. SSO & Identity Integration — SAML / OIDC and the Google Workspace path.
  5. Integrations & Notifications Capability Overview — native integrations, embedding external tools, and notification options.
  6. Data Schema Reference — field-level detail for the records you’ll consume.

Prepared by Plenum Solutions for your evaluation. “Grow by Plenum” is operated and supported by Plenum on your behalf. For integration design support, contact your Plenum engagement lead.