Notifications

Two different things live under Settings → Notifications: emails that go to your customers, and in-app alerts that go to your staff.

Email provider

Before anything can be sent, MPH needs a way to send it. Choose one:

Provider	When to use it
Environment default	The instance's built-in configuration. Fine for getting started
SMTP	Your own mail server or a provider that speaks SMTP
Resend	An API key from Resend

Then set the from address and name, and a reply-to. Verify the configuration before relying on it - a from address on a domain you have not authorised is the usual reason mail silently lands in spam.

Provider credentials are encrypted at rest.

Customer email purposes

Each purpose is configured on its own page, with routing rules and a template:

Purpose	Sent when
Invoice	An invoice is generated for an order
Order confirmation	An order is confirmed
Order cancelled	An order is cancelled
Shipment dispatched	A shipment is booked and handed to the carrier
Shipment delivered	The carrier reports delivery
Payment received	An order is fully paid
Customs documents	Customs paperwork is sent, normally to a forwarder
Purchase order	A PO is emailed to a supplier

Purposes that attach a PDF also let you choose which print template generates it.

If your sales channel already emails customers about their order, do not switch the same purpose on here as well. Two order confirmations from two systems is worse than one. This matters most for returns, where the platform emails the return label itself.

Routing rules

A purpose does not have to fire on every order. Rules decide when it does, based on events such as:

Order status changed, to a status you choose
Order handling status changed
Payment status changed
Invoice generated
Fulfilment created, or reversed
Shipment status changed
Return requested

Templates

Each purpose has an editable email template - subject and body, with tokens for order number, customer name, tracking number and so on. Templates can be per language, so a customer gets the email in the right one, falling back to the warehouse's fallback language.

Staff notifications

Separate from customer email, the bell in the app header carries in-app alerts for the people who need to act:

Alert	Fires on
New return request	A customer asks to return something
Wallet balance low	The shipping wallet is running down
Wallet balance negative	The wallet has gone negative
Freight claim filed	A claim was submitted
Freight claim status changed	A carrier or MPH moved a claim on
New claim message	Someone replied on a claim thread

These fan out by permission, not by subscription. A wallet alert reaches people with wallet:read; a return request reaches people with returns:read. Nobody has to opt in, and nobody gets alerts about work they cannot do.

Testing

Send yourself one of each before going live, and read them on a phone. Most customer email is opened on a phone, and a template that looks fine on a desktop can be unreadable there.