Send order emails

Which emails an order sends to the customer and to the store's staff, how to trigger them from the API, and how notification profiles decide which staff get each one.

Goal: know who gets an email when your integration creates or updates an order, and control it. An order sends two kinds of email:

Customer emails go to the order’s contact. You decide when they go out.
Staff emails go to the store’s notification recipients. The store decides who gets each one with notification profiles.

Orders placed through Bolder checkout send these emails as they move through checkout and payment. Orders you create or update through the API send none unless you ask for them.

Customer emails

Status changes

Send notify_status_change: true with the status change. notification_message adds your text to the email. Most statuses also need _policies.allow_status (see Update an order):

curl -X PUT https://api.onbolder.com/v2/orders/A3F09B1 \
  -H "Authorization: Bearer $BOLDER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "fulfillment_status": "shipped",
    "notify_status_change": true,
    "notification_message": "Your charger leaves our warehouse today."
  }'

Change	Customer email
`status` → `in_review`	Order received, under review
`status` → `pending`	Order placed, waiting for payment
`status` → `closed`	Order confirmed (paid). If it was `in_review` before, the “approved after review” version. Without a `notification_message`, it carries the store’s checkout success message
`status` → `completed`	The same confirmation, only when the order has no delivery step (no fulfillment method or deliverables); otherwise the delivery emails already told the customer
`status` → `cancelled`	Order cancelled
`fulfillment_status` → `preparing`	Being prepared
`fulfillment_status` → `ready`	Ready for pickup, only for local pickup orders; nothing otherwise
`fulfillment_status` → `shipped`	Shipped
`fulfillment_status` → `delivered`	Delivered
`fulfillment_status` → `returned`	Returned

The emails go out a few seconds after the change, and only if the order is still in that status by then: moving an order through several statuses in quick succession sends only the ones it stays in.

Customer emails use the store’s email design (logo, colors, header and footer from the admin). When the store has turned on the tracking link (website.track_link_in_emails), they include a “Track my order” link to the store’s tracking page.

Messages

To write to the customer without changing the status, post an order message with notify: true:

curl -X POST https://api.onbolder.com/v2/orders/A3F09B1/messages \
  -H "Authorization: Bearer $BOLDER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "body": "Your installation is booked for Tuesday.", "notify": true }'

The message stays in the order’s conversation and is emailed to the customer. Internal notes (internal: true) are never emailed. This needs a token issued to a user (the message’s author) with the full orders.write scope.

Staff emails

These go to the store’s recipients, not to the customer. The status emails reply to the customer’s address:

Email	Sent when
New order	The order becomes `pending`. The customer’s salesperson gets a copy too
Order in review	The order becomes `in_review`
Order paid	The order becomes `closed` (or `completed` with no delivery step)
Purchase order received	A `purchase_order` document is attached to the order (`POST /orders/{order_id}/documents`), with a link to the order in the admin

The status emails follow the same rule as the customer ones: through the API they are sent only with notify_status_change: true. The purchase order email is sent whenever such a document is attached, whatever the token.

Stores also get staff emails for quotes, subscriptions and customer address changes, and for the alerts in the admin’s notifications feed (low stock, failed integrations…) that a profile opts in to.

Notification profiles

A store manages its recipients in the admin, under Settings > Notifications:

A recipient is a mailbox (name and email), often a staff member’s.
A profile lists the staff emails its recipients get. Each entry can be switched off, and can be narrowed to the orders that meet one of the store’s cart requirements lists. A profile also lists the alert topics its recipients are emailed about; alerts are opt-in.
A recipient without a profile gets everything.

Two more rules apply to order emails. When the order has a fulfillment branch, recipients who are staff users of the store but not assigned to that branch are skipped. And a recipient linked to a user can’t be given emails beyond that user’s role: a vendedor’s profile can’t include subscription emails, for example.

Profiles and recipients are not in the v2 API yet; set them up in the admin.

Sender and replies

Emails are sent with the store’s sender settings: from the store’s name at a Bolder address, from a no-reply address, or through the store’s own mail server when it has one configured. Replies to customer emails go to the store’s first recipient; replies to staff emails go to the customer.

Orders reference: notify_status_change, notification_message, _policies and the messages endpoint.
Receive order webhooks to run your own notifications on the same events.