Notifications & Event Feeds
Trigger email and in-app notifications for buyers, sellers, and admins from a single event-driven system in Mercur. Mercur’s Notifications module turns key platform events-like orders, approvals, and account changes-into clear, consistent messages for the right people. Instead of hard-coding emails and alerts in every service, you define templates, channels, and triggers once, and reuse them across the whole platform.
How you manage notifications in Mercur
Keep everyone in the loop - customers, marketplace vendors, and your internal team - without gluing together ad-hoc email scripts and dashboard alerts.
With the Notifications module, you can:
- Define notification channels such as email, admin in-app feed, and seller in-app feed.
- Configure notification types for buyers, sellers, and internal operators.
- Attach templates (subject, body, variables) to each notification type.
- Specify triggers based on Mercur events (order created, order paid, product request approved, password reset, etc.).
- Decide who should receive each notification: specific users, roles, vendors, or admins.
- Extend the system with custom events and providers when you need more channels or more advanced logic.
Build custom marketplace with Mercur
Create your unique multi-vendor platform with our powerful, flexible marketplace solution that adapts to your business needs.
What the Notifications module delivers for your business
Unified notification layer
Instead of scattering email logic, toasts, and alerts across microservices and frontends, Mercur gives you one place to define who gets notified, when, and how.
Multi-channel, role-aware messaging
Send transactional emails to customers, surface operational updates in admin feeds, and keep sellers informed through their own dashboard - using the same underlying events.
Marketplace-ready communication
Handle vendor-specific notifications like new orders, catalog approvals, and account changes out-of-the-box, so your marketplace can actually run day-to-day.
Consistent customer experience
All transactional emails - order confirmations, password resets, shipping updates - are built on the same template system and event triggers, making your communication feel coherent.
Developer-friendly & extensible
Use standard providers for email and built-in in-app feeds, then plug in new providers or custom events as your use cases grow, without rewriting core business logic.
Core capabilities
1. Notification channels
Model how messages are delivered:
- Email
- Transactional emails for customers and sellers (orders, account events, approvals, password reset).
- Integrations with external email providers (e.g. SendGrid, SES, or your preferred SMTP) via provider abstraction.
- Transactional emails for customers and sellers (orders, account events, approvals, password reset).
- Admin Feed
- In-app notification stream inside Mercur Admin.
- Shows events that require operator attention: new seller onboardings, product requests, errors, or moderation tasks.
- In-app notification stream inside Mercur Admin.
- Seller Feed
- In-app notification stream inside the seller / vendor dashboard.
- Highlights new orders, catalog decisions, and account updates relevant to that seller.
- In-app notification stream inside the seller / vendor dashboard.
Each event in Mercur can target one or multiple channels, so critical events can appear both in email and in-app feeds.
2. Buyer email notifications
Keep your customers informed throughout their journey:
- Order lifecycle
- Order confirmation, payment received, order shipped, partially fulfilled, cancelled, or refunded.
- Optional emails for delivery updates or shipment tracking links (via fulfillment events).
- Order confirmation, payment received, order shipped, partially fulfilled, cancelled, or refunded.
- Account & security
- Password reset emails with secure, time-bound links.
- Account activation and email verification messages.
- Notifications about important changes (e.g. email change, security-relevant events).
- Password reset emails with secure, time-bound links.
- Marketplace interactions
- Updates tied to marketplace flows (e.g. when a multi-vendor order is split or updated, where relevant to the customer experience).
- Updates tied to marketplace flows (e.g. when a multi-vendor order is split or updated, where relevant to the customer experience).
All of these use configurable templates with dynamic placeholders (customer name, order number, links) so you can keep branding and content consistent.
3. Seller notifications (email + seller feed)
Give your vendors a live operational inbox:
- New orders for sellers
- Notifications when new orders or order lines are assigned to a vendor.
- Updates for changes in order status or fulfillment that impact the seller (e.g. cancellations, returns).
- Notifications when new orders or order lines are assigned to a vendor.
- Product & catalog requests
- Notifications when a seller’s product requests are approved or rejected.
- Similar flows for related catalog structures (e.g. category, collection, type, tag requests) if you expose such workflows.
- Notifications when a seller’s product requests are approved or rejected.
- Account & onboarding updates
- Changes to seller account status (approved, suspended, additional documents required).
- Guidance through onboarding steps, so vendors know what’s next.
- Changes to seller account status (approved, suspended, additional documents required).
Some of these events can be delivered via email for high-importance changes, while day-to-day operational info can live primarily in the seller feed.
4. Admin feed notifications
Give your operations and marketplace teams a real-time view of what needs attention:
- Operational events
- New sellers awaiting approval.
- Product or catalog requests pending review.
- Orders or system operations that require manual intervention.
- New sellers awaiting approval.
- Moderation & approvals
- Content or catalog changes that require a decision from an operator (approve/reject).
- Escalations from system rules (e.g. suspicious activity flags, incomplete data).
- Content or catalog changes that require a decision from an operator (approve/reject).
- System health & background jobs (if wired via custom events)
- Failed background jobs, integration errors, or sync issues that may impact customers or sellers.
- Failed background jobs, integration errors, or sync issues that may impact customers or sellers.
The admin feed becomes a “to-do inbox” for platform operators, embedded directly into Mercur Admin.
5. Templates & content management
Control what your notifications look like and say:
- Email templates
- Define subjects and bodies for each notification type (e.g. forgotPasswordEmailTemplate, order confirmations, shipping updates).
- Use placeholders for dynamic content: customer name, order ID, links, prices, dates, seller name, etc.
- Define subjects and bodies for each notification type (e.g. forgotPasswordEmailTemplate, order confirmations, shipping updates).
- Branding & layout
- Keep header, footer, and style consistent across emails while still customizing message content per event.
- Update branding and copy in templates without changing backend logic.
- Keep header, footer, and style consistent across emails while still customizing message content per event.
- Localization & multiple languages
- Support multiple language versions of templates by using locale-aware template sets.
- Use event context (e.g. customer locale, region) to pick the right version.
- Support multiple language versions of templates by using locale-aware template sets.
Templates are managed at the backend level, so any frontend or channel benefits from the same communication design.
6. Event triggers & extensibility
Drive notifications from domain events instead of ad-hoc calls:
- Event-driven architecture
- Notifications listen to Mercur’s domain events: order created, order updated, fulfillment created, product request approved, customer created, password reset requested, and more.
- When an event fires, the module evaluates which notification types, channels, and recipients it should trigger.
- Notifications listen to Mercur’s domain events: order created, order updated, fulfillment created, product request approved, customer created, password reset requested, and more.
- Custom triggers
- Add your own event types in the code where your custom business logic lives.
- Wire them into the notification engine so new flows (e.g. subscription renewals, KYC status changes) can reuse the same structure.
- Add your own event types in the code where your custom business logic lives.
- Conditional logic
- Decide when to send (or skip) notifications based on event payload, roles, or configuration.
- Avoid noisy or duplicate messages by centralizing this logic.
- Decide when to send (or skip) notifications based on event payload, roles, or configuration.
This makes Notifications a coherent layer on top of the entire platform, not a collection of random email calls.
7. Provider architecture
Plug in and swap providers without rewriting flows:
- Email providers
- Use abstractions to integrate with any email provider (SendGrid, SES, SMTP, etc.).
- Switch providers or support multiple providers across environments with minimal changes.
- Use abstractions to integrate with any email provider (SendGrid, SES, SMTP, etc.).
- Local notification provider
- Built-in provider for admin and seller feeds, persisting notifications in your Mercur database.
- APIs and UI components can then consume these feeds to render in-app notification centers.
- Built-in provider for admin and seller feeds, persisting notifications in your Mercur database.
- Future channels
- The same architecture can be extended to SMS, push notifications, or chat tools by adding new providers and mapping events to them.
- The same architecture can be extended to SMS, push notifications, or chat tools by adding new providers and mapping events to them.
This keeps your platform future-proof: when you add new channels, your existing events and templates are ready to be reused.
Build custom marketplace with Mercur
Schedule a guided tour of Mercur Marketplace tailored to your specific marketplace requirements. Connect with our team to discuss how we can help bring your marketplace vision to life.