← Back to work
WordPress Development · REST APIs

A WordPress REST endpoint that creates the account and enrolls the buyer

One POST with an email address replaces the manual step after every sale: the route creates the WordPress account if it does not exist, then grants the LearnDash course.

Role
Endpoint design and build, integration into the enrollment flow
Company
Brave Leadership
Timeline
11/2020 – 06/2026
Team
Solo, with Codex assisting on the PHP
Impact
7 courses · 150+ students · manual enrollment eliminated

Overview

Brave Leadership sells its leadership courses through a WordPress portal running LearnDash for course delivery and WooCommerce for checkout, carrying 7 courses and 150+ students. Both systems did their own job well, but nothing connected them: a completed purchase did not put the buyer into the course.

Problem

Every sale ended in a manual step, and usually two. A purchase gives you an email address, not a user. Most buyers had no WordPress account at all, so enrolling someone meant creating the account, granting course access, and sending them their login by hand, while they waited on something they had already paid for.

Process

The endpoint had to own both jobs. Creating the account was not an edge case to handle later, it was most of the work, and whatever called the route should not need to know whether the buyer was new or returning.

So the payload is the smallest thing that identifies a buyer, an email address, and the route handles everything downstream of it. Each course has its own route, so adding a course meant adding a route rather than changing a shared one.

Solution

Registered POST routes under a custom REST namespace that authenticate the caller against a bearer token, sanitize the submitted email, and reject the request outright if either check fails. The handler looks the user up by email; if no account exists it creates one with a generated password and fires the WordPress new-user notification so the buyer receives their credentials. Either path then calls LearnDash's ld_update_course_access() to grant the course, and the route returns the user and course IDs as JSON so the calling automation can confirm what happened. Zapier and webhooks connect the purchase event to the route.

  1. POST — Purchase posts the buyer's email
  2. AUTH — Bearer token checked
  3. VALIDATE — Email sanitized and required
  4. BRANCH: Does the account exist?
  5. If No:
  6. CREATE — Account made, credentials emailed
  7. GOAL — Enrolled in the course
  8. If Yes:
  9. GOAL — Enrolled in the course

Results

The outcome here is operational rather than a conversion metric. Manual enrollment was eliminated: a purchase now creates the account, grants the course, and emails the buyer their login without anyone touching it.

Learnings

Returning the user and course IDs rather than a bare success made the upstream automation debuggable. When an enrollment did not land, the response already said whether the account had been created or matched.

Shipping it taught me where the seams are. Secrets belong in configuration rather than in the file, and authentication belongs in the route's permission callback rather than in the handler. That is the refactor this work earned.

My role

Kenneth built these endpoints and wired them into the enrollment flow, using Codex to help write the PHP. He also built and structured the course platform they run on in WordPress, LearnDash, and WooCommerce.

Let's talk.

Open to remote roles in digital marketing, marketing automation, and web development. I reply within a day.

Email

kenjsangalang@gmail.com

Email me →

LinkedIn

linkedin.com/in/kenneth-jon-sangalang-tech

View profile →

GitHub

github.com/ken-turtle-learner

See the code →

Available now · Remote