Skip to main content
The backend uses an internal event bus (RabbitMQ) to fan actions out to notifications without every service having to know how to send an email or push a WebSocket message itself. This isn’t part of the public API surface, but it directly determines what shows up as an in-app notification or a real-time push — so it’s documented here in full rather than left implicit. There are 57 defined events. This table accounts for every one of them, so nothing is left ambiguous about what’s actually wired up versus reserved for a feature that doesn’t exist yet.
“Customer notification” and “Admin alert” below mean: persisted in-app notification + email + live WebSocket push to the customer, or a live admin-alert WebSocket push (plus an ops email) respectively. See Real-time Notifications for the delivery mechanics.

​
Live — actively published and wired

These 17 events are published by a backend service today, and each one triggers a real, content-complete customer notification and/or admin alert (not placeholder copy).
Loyalty point awards (leaving a review, referring a friend, sharing a product) notify the customer too, but not through this event bus — LoyaltyService calls NotificationsService.createInApp(...) directly, in-process, since both live in engagement-service. See loyalty.service.ts. The loyalty.points.earned and referral.reward.earned enum entries below exist for a bus-based version of this that was never needed once the direct call was in place.

​
Dormant — content ready, nothing publishes them yet

These 35 events have complete, real (non-placeholder) rendered content in engagement-service/src/notifications/templates.ts, and DomainEventsListener is already subscribed and ready to act on them — but no service in the codebase ever calls messaging.publish(...) for them, because the feature that would trigger them doesn’t exist yet (returns, carrier/logistics integration, wholesale billing, cron-based reporting, staff CRUD, support ticketing, etc.). Wiring one of these up is “call publish() from the right place,” not “write the notification.”
return.request.received, return.approved, return.rejected, refund.processed, delivery.carrier.assigned, delivery.ready_for_collection, delivery.delayed, delivery.failed, delivery.rescheduled, order.recurring.reminder, order.reorder.suggestion, cart.abandoned
wholesale.delivery_instructions.needed, wholesale.credit_terms.updated, wholesale.account.suspended, wholesale.account.reinstated, wholesale.statement.ready, wholesale.catalogue.updated, wholesale.price.change
wishlist.reminder, support.ticket.received, support.ticket.resolved, user.totp.setup_reminder, user.data_export.ready, user.login.new_device, policy.updated, referral.reward.earned
staff.account.created, staff.role.updated, staff.account.deactivated, product.published, product.removed
category.updated, reports.sales.daily, reports.sales.weekly

​
Defined but effectively unhandled

Five events fall into neither bucket above — they exist in the DomainEvent enum but have no rendered template of any kind, so DomainEventsListener isn’t even subscribed to them:
If you’re adding a new notification-worthy action, check this table first — there’s a good chance the event and its copy already exist in templates.ts and just need a publish() call added at the right point in the relevant service.