Install our app for a better experience!

Complete Onboarding Walkthrough

Complete Onboarding Walkthrough

This is the whole student-onboarding process end to end, in order, with copy‑paste examples — from getting your API key to the student logging in and starting their course. If you only read one page, read this one.

The goal: when a customer buys (or you decide to enrol someone), one API call creates their account, gives them the course(s) you choose for the duration you choose, and emails them a login link. No manual steps, no pre‑setup, safe to repeat.

Base URL: https://<your-platform-host>/api/v1/ Replace <your-platform-host> with your platform's domain, and <your-key> with your API key.


Step 1 — Get your API key

Any organization admin can create one:

  1. Sign in and open your Organization dashboard.
  2. Click More Actions → API Keys & Integrations (super‑admins: Actions → API Keys & Integrations).
  3. Enter a name (e.g. Pabbly – production) and click Create key.
  4. Copy the key now — it's shown once and never again. Only a hash is stored.

The key identifies your organization, so every call automatically acts on your org — you never send an organization id, and you can't touch anyone else's data. Treat it like a password.


Step 2 — Confirm your key works

curl -s https://<your-platform-host>/api/v1/ping/ -H "X-API-Key: <your-key>"
{ "status": "ok", "organization": "Acme Prep", "organization_slug": "acme-prep" }

Seeing your organization's name back means the key is valid. A 401 means the key is missing, mistyped, or revoked.


Step 3 — See which courses you can grant

curl -s https://<your-platform-host>/api/v1/courses/ -H "X-API-Key: <your-key>"
{
  "status": "ok",
  "course_types": [
    { "name": "ielts",        "display_name": "IELTS" },
    { "name": "pte_academic", "display_name": "PTE Academic" },
    { "name": "gmat",         "display_name": "GMAT" }
  ]
}

Use the name values (e.g. ielts) in the courses field in the next step. You do not need to set courses up first. Students are enrolled into your organization's default course for each type — and if you don't have one yet, the platform creates it automatically (a perpetual "Quick Enroll" course) the first time you enrol someone into that type.


Step 4 — Onboard a student (the main call)

One POST creates the account and enrols them into the course(s) you pick, for the duration you pick.

curl -s -X POST https://<your-platform-host>/api/v1/provision/student/ \
  -H "X-API-Key: <your-key>" \
  -H "Content-Type: application/json" \
  -d '{
        "email": "[email protected]",
        "first_name": "Jane",
        "last_name": "Doe",
        "courses": ["ielts"],
        "tenure_months": 6,
        "external_ref": "wc_order_1234"
      }'

What each field does:

Field Required What it controls
email The student's identity. The same email always maps to the same account.
first_name Used on the account and in the welcome email.
last_name Optional.
courses Which course(s) to grant, by name. One ("ielts") or several (["ielts","gmat"]). Omit to create the account with no course (a member who'll only use custom tests).
tenure_months How long they get access, in months (1–120). Starts today. Omit to use your org's default (~3 months).
external_ref Your own reference (e.g. an order id). Stored so you can trace this student back to your system.
send_welcome_email true by default. Set false if you'd rather email the student yourself.

Successful response (201 for a new account):

{
  "status": "success",
  "user_id": 4821,
  "created_user": true,
  "enrollments": [
    {
      "course_type": "ielts",
      "course_id": 12,
      "enrollment_id": 5567,
      "status": "active",
      "start_date": "2026-07-24",
      "end_date": "2027-01-24",
      "already_enrolled": false
    }
  ],
  "login_url": "https://<your-platform-host>/login/",
  "set_password_url": "https://<your-platform-host>/reset/MzQ/abc.../",
  "welcome_email_sent": true
}

What just happened (behind that one call)

  1. Account — Jane's account was created (created_user: true). If she'd existed already, it would be reused (created_user: false) — never duplicated.
  2. Organization — she was added to your organization as a member.
  3. Course — she was enrolled in your org's default IELTS course. Because you had no IELTS course set up yet, the platform created a default one automatically (a perpetual "Quick Enroll" course) and placed her in it. Every future IELTS student you onboard joins that same default course.
  4. Duration — her access runs from today (start_date) to 6 months later (end_date). After that there's a short grace period, then access ends on its own — you don't have to expire anyone.
  5. Ready to study — she gets full practice access (reading, listening, speaking, writing + whatever AI features your org enables) and a few starter practice tests.
  6. Login — a one‑time set‑password link (set_password_url) was generated and emailed to her (welcome_email_sent: true).

Step 5 — The student's side

  1. Jane receives a "Welcome — set your password" email.
  2. She clicks the link, sets a password, and lands logged in.
  3. She logs in any time afterwards at login_url, sees her IELTS course, and starts practising.

Prefer to send your own email? Pass "send_welcome_email": false and use the set_password_url from the response in your own message. That link is only returned for brand‑new accounts.


Everyday cases (all handled by the same call)

You don't need different endpoints for these — just call provision/student/ again with the same email.

You want to… Do this Result
Give a second course Call again with "courses": ["gmat"] Adds GMAT alongside their IELTS.
Renew / extend an expired student Call again with a new tenure_months Their lapsed enrolment is reactivated with fresh dates (not duplicated).
Re‑run the same call (e.g. a webhook retried) Send it again, unchanged Safe — you get status: already_provisioned, already_enrolled: true, nothing double‑enrols.
Create an account with no course Omit courses Account + membership only; enrollments: [].
Re‑enable a suspended student Not via the API A suspension is left untouched (skipped_reason: "suspended"). Lift it in the platform — the API won't override a manual admin decision.

Full field‑by‑field response reference and the complete scenario matrix are on the API Reference page.


Step 6 — Automate it

Everything above is one HTTP POST, so any automation tool can do it with no code — when a payment or signup happens on your side, send the same call. Step‑by‑step recipes for Pabbly Connect, Zapier, and Make.com are on the Automation Setup page. A typical flow:

WooCommerce order paid  →  Pabbly/Zapier/Make  →  POST /api/v1/provision/student/  →  student onboarded + emailed

Full example, start to finish

# 1. Confirm the key
curl -s https://<your-platform-host>/api/v1/ping/ -H "X-API-Key: <your-key>"

# 2. Onboard a student into IELTS + GMAT for 6 months, don't send our email (you'll send your own)
curl -s -X POST https://<your-platform-host>/api/v1/provision/student/ \
  -H "X-API-Key: <your-key>" -H "Content-Type: application/json" \
  -d '{
        "email": "[email protected]",
        "first_name": "Jane",
        "last_name": "Doe",
        "courses": ["ielts", "gmat"],
        "tenure_months": 6,
        "external_ref": "wc_order_1234",
        "send_welcome_email": false
      }'
# → status: success, created_user: true, two entries in enrollments[], set_password_url returned

# 3. Same call again = safe. Nothing duplicates.
#    → status: already_provisioned, each enrollment already_enrolled: true

That's the entire onboarding process. For deeper detail see API Reference (every field + all scenarios), Automation Setup (Pabbly/Zapier/Make), and Troubleshooting & Security.