事件目录
上表 9 个开关全部是逐收件人的 —— 包括
notifySubscriptionPlanChanged 与 notifyChargeback。同一门店下的两个人可以订阅不同的事件，update-recipient 接受这 9 个键中的任意一个。投递地址跟收件人列表走：商户通知发到已配置的收件人（列表为空时回退 owner 账号邮箱），不再发到 supportEmail。限制
每个门店最多 5 个收件人，超出上限返回 400。没有下限 —— 但空列表不等于静默：它会回退到门店 owner 的账号邮箱（见下节）。面向消费者的交易邮件（订单收据、订阅确认）是另一条链路，不受影响。兜底收件人
门店没有显式收件人时，列表里恰好有一条isPrimary: true 的合成条目：地址是门店 owner 的账号邮箱，开关取门店级的 notify*，createdAt 取门店创建时间。它的 id 是形如 OWNER_<storeId> 的稳定哨兵值。
它不是存储里的一行。对该 id 调用 remove-recipient 返回 404 —— 账号邮箱是兜底，不可删除；要取代它就添加一个真实收件人。对该 id 调用 update-recipient 则会就地物化：账号邮箱被写成一条真实收件人，你的 patch 叠加其上，响应返回真实 UUID。
添加第一个显式收件人后，兜底条目随即消失。这是有意的可见行为。
环境
收件人不分环境。请求可以照常携带X-Environment，但它不参与收件人读写的过滤与改写 —— 同一门店在 test 与 prod 下返回同一份列表。
列出收件人
没有list-recipients 端点 —— 查询收件人列表走 GraphQL 顶层查询 storeNotificationRecipients；未配置显式收件人时，它同样返回那条兜底条目：
端点
添加收件人
添加一个接收商户通知的地址。
更新收件人
修改收件人订阅的事件。
移除收件人
从列表中移除一个收件人。