> ## Documentation Index
> Fetch the complete documentation index at: https://secdocs.asikoexpress.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Domain Events Catalog
> Every internal event the platform defines, and exactly what happens when each fires
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](/realtime-notifications) — 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](/realtime-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).
| Event | Published by | Customer notification | Admin alert |
| ------------------------------------------------------------------------- | --------------------------------------------------------------------------- | :-------------------: | :---------: |
| `user.registered` (`USER_REGISTERED`) | user-service — retail registration, and completing wholesale `set-password` | ✅ | ✅ |
| `user.email_verification.requested` (`USER_EMAIL_VERIFICATION_REQUESTED`) | user-service | ✅ | — |
| `user.trade.approved` (`USER_TRADE_APPROVED`) | user-service | ✅ | — |
| `user.password_reset.requested` (`USER_PASSWORD_RESET_REQUESTED`) | user-service | ✅ | — |
| `user.password.changed` (`PASSWORD_CHANGED`) | user-service | ✅ | — |
| `user.profile.updated` (`PROFILE_UPDATED`) | user-service | ✅ | — |
| `user.account.deactivated` (`ACCOUNT_DEACTIVATED`) | user-service | ✅ | — |
| `user.account.reactivated` (`ACCOUNT_REACTIVATED`) | user-service | ✅ | — |
| `wholesale.application.submitted` (`WHOLESALE_APPLICATION_SUBMITTED`) | user-service | ✅ | ✅ |
| `wholesale.application.approved` (`WHOLESALE_APPLICATION_APPROVED`) | user-service | ✅ | — |
| `wholesale.application.rejected` (`WHOLESALE_APPLICATION_REJECTED`) | user-service | ✅ | — |
| `order.placed` (`ORDER_PLACED`) | order-service | ✅ | ✅ |
| `order.paid` (`ORDER_PAID`) | order-service | ✅ | — |
| `order.cancelled` (`ORDER_CANCELLED`) | order-service | ✅ | — |
| `order.dispatched` (`ORDER_DISPATCHED`) | order-service — fired when a tracking update sets status `PARCEL_COLLECTED` | ✅ | — |
| `order.delivered` (`ORDER_DELIVERED`) | order-service — fired when a tracking update sets status `DELIVERED` | ✅ | — |
| `product.stock.low` (`PRODUCT_STOCK_LOW`) | product-service | — | ✅ |
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:
| Event | Status |
| ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `review.created` (`REVIEW_CREATED`) | **Published** by product-service on every new review, but has no template — currently a no-op. Likely intended for a future "thanks for your review" flow. |
| `checkout.initiated` (`CHECKOUT_INITIATED`) | Never published, no template. |
| `product.back.in.stock` (`PRODUCT_BACK_IN_STOCK`) | Never published, no template. |
| `product.updated` (`PRODUCT_UPDATED`) | Never published, no template. |
| `loyalty.points.earned` (`LOYALTY_POINTS_EARNED`) | Never published, no template — superseded by the direct in-process call described above. |
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.