Grow LMS API Documentation

Grow by Plenum — Provisioning & Workforce Management

Getting your workforce into Grow, organized, and cleanly off again — at scale.

The earlier integration docs cover reading data out of Grow. This one covers the other direction: how your systems create, enroll, organize, and deprovision learners programmatically, so onboarding thousands of workers and keeping them current is automated rather than manual. It’s the operational backbone of an enterprise rollout.

Every operation here uses the same credentials as the rest of the API — the Pl-Client header and Authorization: Bearer <ACCESS_TOKEN> from Authentication & Access Setup. Throughout, <SCHOOL_ID> is your dedicated Grow environment.

1. The short version

Grow’s API is built to administer at scale. Where content authoring happens in the platform’s studio, the management of people and access — creation, enrollment, grouping, tagging, suspension — is fully API-driven. A typical enterprise rollout wires three things together:

  1. Provision learners (create accounts, or let SSO create them on first sign-in).
  2. Enroll them into the required courses or programs — individually or in bulk.
  3. Organize them into groups and tags that mirror your org structure, so reporting and assignment follow your real hierarchy.

And the same surface handles the end of the lifecycle: suspend or deprovision when someone leaves.

One convenience worth knowing up front. Almost every per-user operation accepts either the Grow user ID or the learner’s email address (URL-encoded) as the identifier. You can act on your own people by the email you already know them by, without first looking up an internal ID.

2. Creating learners

Create a learner with a POST; the response is the created user record.

curl -X POST "https://<SCHOOL_ID>/admin/api/v2/users" \
  -H "Pl-Client: <CLIENT_ID>" \
  -H "Authorization: Bearer <ACCESS_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{ "email": "worker@your-org.example", "username": "worker@your-org.example" }'
  • email and username are required; password is optional.
  • Because your learners sign in through SSO (see SSO & Identity Integration), you typically don’t set a password — identity is asserted by your IdP. You can also let SSO create the account on a learner’s first sign-in, and use the API purely for enrollment and organization.

Either model works; most enterprise rollouts use SSO for identity and the API for everything around it.

3. Enrolling and unenrolling

Enrollment grants a learner access to a product — a course, a bundle, or a program.

curl -X POST "https://<SCHOOL_ID>/admin/api/v2/users/<USER_ID_OR_EMAIL>/enrollment" \
  -H "Pl-Client: <CLIENT_ID>" \
  -H "Authorization: Bearer <ACCESS_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{ "productId": "<COURSE_ID>", "productType": "course" }'
  • Enroll into a course, bundle, or program by identifying the product.
  • Unenrolling removes access and emits the userUnenrolledFromProduct webhook (see Webhooks), so your downstream “who lost access” reporting stays current automatically.
  • For a bulk rollout, iterate enrollment across your roster; for large batches, see the asynchronous pattern in Section 7.

This pairs directly with the read side: you enroll here, and completion/progress flows back through Webhooks and Pull-Based Data Access.

4. Organizing the workforce

Three mechanisms let your Grow structure mirror your real organization. Use them together.

Groups

User groups bundle learners into units you manage together — by department, site, crew, or contractor company. Create a group, then add or remove members:

# Add a learner to a group
curl -X POST "https://<SCHOOL_ID>/admin/api/v2/usergroups/<GROUP_ID>/users/<USER_ID_OR_EMAIL>" \
  -H "Pl-Client: <CLIENT_ID>" \
  -H "Authorization: Bearer <ACCESS_TOKEN>"

Membership is queryable both ways — who’s in a group, and which groups a learner belongs to — so groups can drive both assignment and reporting.

Seats

If your commercial model is seat-based (a block of licensed seats your administrators allocate), Grow supports seat offerings: create an offering, add and remove users against it, and report on who occupies a seat. This is the model for “we bought N seats and manage who fills them.”

Tags

Tags are lightweight labels applied to a learner — region, crew, job classification, employee vs. contractor. Update a learner’s tags with a PUT; the response is the updated user record, and the change emits userTagAdded / userTagDeleted webhooks. Tags are the most flexible cohorting tool because they travel on every record your integration consumes (see Data Schema Reference).

Rule of thumb: groups for managed units you assign and report on, seats for license allocation, tags for flexible cohort attributes that flow through your data.

5. Lifecycle: suspension and deprovisioning

When a worker leaves or access must be cut, you have two complementary levers:

  • Suspend a learner (a PUT against the user) blocks them from signing in or creating another account, while preserving their record and history. Unsuspend reverses it. This is the explicit “freeze access now” control.
  • SSO deprovisioning — because sign-in is delegated to your identity provider (see SSO & Identity), disabling someone in your directory prevents future sign-in as well. Most enterprises drive offboarding from the IdP and use API suspension for immediate, explicit cut-offs or for cases outside the SSO population.

Suspension preserves the compliance record (you keep the history of what they completed and were certified for) while removing access — usually exactly what an audit trail needs.

6. Staff roles and delegated administration

Beyond learners, the API manages roles for your own administrative staff. The role levels are admin, instructor, reporter, seat_manager, license_reporter, and user. You can grant a regional manager reporter access to see their team’s progress, or seat_manager to allocate seats, without making them a full administrator. Roles are assigned and updated through the API, so delegated administration can be provisioned the same automated way as everything else.

7. Operating at scale

A few practices keep large provisioning runs reliable:

  • Identify by email when convenient. Operating by email avoids a lookup step when you’re driving provisioning from an HR roster keyed on email.
  • Expect asynchronous responses for large operations. Bulk actions may return an asynchronous-action handle rather than completing inline; you poll a status endpoint until it reports done. Design batch jobs to submit, then check progress, rather than assuming every call finishes synchronously.
  • Be idempotent. Make re-running a provisioning job safe — re-enrolling an already-enrolled learner or re-adding a group member should be a no-op in your logic, so a retried batch doesn’t create duplicates or errors you have to chase.
  • Drive from a roster of record. Treat your HRIS or directory as the source of truth and reconcile Grow to it on a schedule (provision new hires, suspend departures), rather than managing membership by hand.

8. Where to go next

  • Authentication & Access Setup — the credentials every operation here uses.
  • SSO & Identity Integration — the identity side of provisioning and deprovisioning.
  • Webhooks / Pull-Based Data Access — how the enrollments and changes you make here flow back out as data.
  • Data Schema Reference — the user, enrollment, and progress records these operations create and modify.

Prepared by Plenum Solutions for your evaluation. “Grow by Plenum” is operated and supported by Plenum on your behalf. Exact endpoint paths and payloads are confirmed for your environment during onboarding. For integration design support, contact your Plenum engagement lead.