What it does
- Formatted templates. Full HTML with your branding, not the 160 characters a text message allows.
- Attachments. Proof of delivery, a signed docket, a run sheet, an invoice — the documents that have to travel with the message.
- Trigger-driven sends. The same trigger model as SMS: booking confirmations, status changes, exception notices.
- Scheduled summaries. The digest shape email suits and text does not — a daily recap to a customer, an end-of-shift summary to a manager.
- A delivery log. Sends, bounces, and complaints, recorded per message.
How it works
Same engine, different channel
Requesting an email works exactly like requesting a text: you ask, you get an immediate acknowledgement, and the platform takes on the delivery. Templates, triggers and the delivery log are shared machinery. If you run both modules, you write one integration.
Deliverability is handled for you
Email that reaches the inbox rather than the spam folder depends on sender authentication, a warmed sending reputation, and disciplined handling of bounces and complaints. The platform owns all of that. A hard bounce suppresses the address rather than being retried into a reputation problem, and a complaint is honoured rather than ignored — because one account sending to bad addresses would otherwise degrade deliverability for everyone.
Attachments come from the platform
Because the platform already holds the documents attached to a job, an email can carry the proof of delivery for the stop it concerns without you fetching the file, base64-encoding it, and posting it back.
Why it is its own module
Email and SMS are separately switchable because they are separately wanted. Email is close to free and suits confirmations, receipts and digests; text costs real money per message and suits the handful of moments that need to be read within the minute. Most accounts want a lot of one and a little of the other.
Permissions
This module has no permissions of its own yet. The codes below are the ones planned for it — they cannot be attached to an API credential until the module ships. Anything you build against the module today uses the base-platform permissions listed alongside them.
| Permission | What it allows | Needed |
|---|---|---|
| notifications.read | Read message templates, channel configuration and the delivery log. Planned — not yet issuable. Shared with SMS Notifications. | Planned |
| notifications.write | Create and edit templates, and request a send. Planned — not yet issuable. Shared with SMS Notifications. | Planned |
| documents.read | Read the metadata for documents attached to an outgoing email, such as a proof of delivery. | Available |
| stops.read | Resolve the stop and recipient a message concerns. | Available |
| orders.read | Resolve the order behind a booking confirmation or summary. | Available |
| subscriptions.write | Register the webhook endpoint that triggers your sends. | Available |
API reference
This module has no public API contract yet. Nothing is callable, and there is no spec to read.
When this module ships an API, its generated OpenAPI 3.1 contract will be published by the service itself and linked here — a browsable reference and the raw openapi.json, both resolving to the environment these docs are served from. Every other Mesh API already works that way; see Geofences for the shape of it.
Events
This module does not raise events of its own today. The events it is expected to raise are listed below so you can plan a subscription around them, but they are not yet published on the event stream.
Delivery-status events — sent, bounced, complained — are planned. Today, the events below are the ones you would subscribe to in order to trigger an email.
| Event | Raised when | Tells you |
|---|---|---|
| order.created | An order is placed. | The trigger behind a booking confirmation. |
| order.status.changed | An order moves through its lifecycle. | The status it moved from and to — the trigger behind a progress update. |
| order.completed | Every stop on an order is done. | The trigger behind a completion summary or an invoice email. |
| stop.completed | A stop reaches its terminal completed state. | The trigger behind a delivery receipt, with proof of delivery attached. |
| stop.failed | A delivery or collection attempt fails. | The reason, for an exception notice explaining what happens next. |
| stop.rated | A customer rates a delivery. | The rating — the trigger behind a follow-up on a poor score. |
The envelope these arrive in, the delivery and retry guarantees, and every other event type are in Events & webhooks — or jump straight to the event catalog.