Event catalog
All ten toggles above are per recipient — including
notifySubscriptionPlanChanged and notifyChargeback. Two people on the same store can subscribe to different events, and update-recipient accepts any of the ten.Nine of the ten default to on. notifyChargeback is the exception: it defaults to off, and a recipient receives chargeback mail only when that flag is explicitly true. A key missing from a stored recipient reads back as its default, so omitting it never switches chargeback mail on.The delivery address follows the recipient list: merchant notifications go to the configured recipients, never to supportEmail. While the list is empty nothing is sent — no address is substituted.Limits
Each store may have at most 5 recipients. Exceeding the limit returns 400. There is no lower bound, and an empty list means silence: emptying it stops this store’s merchant notifications entirely (see below). Consumer-facing transactional email (order receipts, subscription confirmations) is a separate pipeline and is unaffected.The primary recipient
A new store is seeded with one recipient — the merchant account email — markedisPrimary: true. That flag is provenance only: the row carries no privilege, behaves like any other recipient, and can be removed like any other. It is also the row that update-store’s legacy store-level notify* write mirrors onto.
Removing every recipient, the primary one included, is accepted: the store then sends no merchant notifications, and nothing is synthesized to take its place. Add an address back to resume delivery.
Environments
Recipients are not environment-scoped. Requests may carryX-Environment as usual, but it does not filter or shape recipient reads and writes — the same store returns the same list in test and in prod.
Listing recipients
There is nolist-recipients endpoint — querying the recipient list goes through the top-level GraphQL query storeNotificationRecipients, which returns [] when the store has no recipients: