Notifications and Webhooks
Course activity is worth acting on in two places: inside your site, where members and instructors get email, and outside it, where your CRM or automation platform reacts to enrollments and completions. The module covers both from the same events. Every notification can be switched off, and every webhook fires regardless of email settings.
Email notifications
Seven notification types exist, split by recipient. Members receive five:
- Enrollment confirmation: sent when the member enrolls in a course
- Course completed: sent when they finish
- Quiz passed and quiz failed: sent when an attempt is graded
- Certificate earned: sent when a certificate is issued
Instructors receive two, both off by default:
- New enrollment: a student joined one of their courses
- Student completed: a student finished one of their courses
The toggles live in Sushi LMS > Settings, grouped by recipient. Each type defaults on or off as listed above; a fresh install sends the five member emails and none of the instructor ones.
Every send is logged to the module's notifications table with the channel and timestamp, so you can answer "did the member get the course completed email" from the database rather than the member's inbox.
Emails are HTML, rendered from templates you can override in your theme: sushi-lms/{type} in your theme directory replaces the default body for that notification type. Developers also get filters for recipients, subject, and body per type (wpal/torii/sushi_lms/notification/{recipients|subject|body}).
Webhooks
One dispatcher fires nine events, each carrying the site ID, a timestamp, and a payload of the IDs and details involved:
enrollment.createdandenrollment.removedlesson.completed,module.completed,course.completedquiz.submitted, with the attempt number and pass statequiz.passedandquiz.failedcertificate.earned
These are WordPress actions, not outbound HTTP calls. The module fires wpal/torii/sushi_lms/webhook with the event name and payload, and delivering them to an external system is your code's job: a small mu-plugin or automation bridge that listens on the action and posts to your endpoint. Nothing needs configuring in the admin, because nothing is sent until you wire it.
A practical pattern for membership sites: tag-driven automation. Listen for course.completed and apply the course's completion tag in your CRM; members who lose the access tag lose the course, and the completion tag drives your upsell or renewal sequences. The completion tag can also be applied directly by the course settings box, without any code, when the CRM is the same system that controls access.
Choosing what to wire up
The instructor emails are the pair most worth trying. A short "new student in your course" email keeps part-time instructors engaged without giving them a dashboard habit. The member emails for quiz passed and failed pair naturally with a retake policy: quiz failed plus an attempt limit is the signal to send encouragement rather than silence.
Webhooks shine where a second system needs to know. Billing systems that charge per course completion, CRMs that track certification progress for compliance, and analytics warehouses all consume the same nine events. Inside WordPress only, none are needed; the Students and Analytics screens already hold the data.