FlintflintDocs

Customer email delivery

Flint emails your buyers about receipts, deliveries, subscriptions, failed payments, Returns, and invoices. You can take any of those over.

This is one setting per family, not one setting for everything. Most merchants who want their own receipts are happy to let Flint keep sending dunning, and there is no reason to make that an all-or-nothing trade.

The six families#

Each field on customer_email_delivery takes flint_sends, the default, or merchant_sends.

Bash
curl -X PATCH https://api.withflintpay.com/v1/settings \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "customer_email_delivery": {
      "order_receipts": "merchant_sends",
      "fulfillment_updates": "merchant_sends"
    }
  }'
FamilyFlint stops sending
order_receiptsPurchase receipts
fulfillment_updatesShipment and delivery notices
subscription_lifecycleRenewals, pauses, cancellations, trial endings
dunningFailed payment and past-due notices
returnsReturn approvals, labels, and resolutions
invoicesInvoice delivery and reminders

customer_email_delivery is merchant-scoped. Setting it at an organization, location, or device scope returns CUSTOMER_SETTINGS_REQUIRE_MERCHANT_SCOPE.

The events keep firing#

Turning a family off stops Flint's mail and nothing else. The webhook events behind it are unchanged, which is the whole mechanism: you subscribe to what Flint would have written about, and write it yourself.

FamilySubscribe to
order_receiptsorder.paid
fulfillment_updatesorder.fulfillment.status_changed, order.fulfillment.event.created, order.fulfillment.shipment.created, order.fulfillment.shipment.updated, order.fulfillment.package.created, order.fulfillment.package.updated
subscription_lifecyclesubscription.created, subscription.activated, subscription.canceled, subscription.paused, subscription.resumed, subscription.payment_succeeded
dunningsubscription.payment_failed, subscription.past_due
returnsreturn.created, return.updated, return.decision_recorded, return.canceled, return.completed, return.reopened
invoicesinvoice.created, invoice.opened, invoice.sent, invoice.updated, invoice.payment_failed, invoice.paid, invoice.voided

Not every event in a family deserves an email. fulfillment_updates fires six ways because a parcel changes state more often than a buyer wants to hear about it; Flint's own version does not send one message per event either. Pick the transitions your buyers care about. See choosing the right event.

Set up delivery before you switch

Between flipping a family to merchant_sends and your handler going live, that family sends nothing at all. There is no queue and no catch-up.

Subscribe, verify you are receiving the events, and confirm your own send works. Then flip the setting.

Templates#

Flint does not currently support editing its email templates.

branding controls how Flint's email looks: colors, typography, and your logo. To control what it says, set that family to merchant_sends and send it from the events above.

Buyer email that Flint sends contains account links resolved at click time against your customer account settings. That is a separate decision from this one.

If you only want Flint's email to point at your own account pages, set customer_account.mode and leave customer_email_delivery alone. Repointing links is not the same as owning the mail, and it is much less work.

Next steps#

Rate this doc