会员建档与生命周期

会员是你的用户。我方给他一个身份与一套账本，其余的（定价、限额、风控）都是你的事。

我方在会员这件事上只做两件：给他一个在你这个商户下唯一的身份，以及一套按资产记账的账本。

不做的事，因为那是你的生意：


POST /v1/members
{ "external_member_id": "u_88123", "email": "…" }

external_member_id 是你系统里的用户 ID。我方用它做幂等：同一个值再建一次返回 200 与原来那个会员，不会新建，也不会发member.created 事件。

⚠ 幂等命中返回 200、首次创建返回 201。靠状态码分辨「是不是新用户」是

可靠的；靠 member.created 事件分辨也是可靠的。别靠两者的组合猜 ——

事件是异步的。

你拿到的	长什么样	用在哪
`id`	UUID	路径参数 `/v1/members/{id}`
`external_member_id`	你给的字符串	`x-on-behalf-of` 请求头

⚠ x-on-behalf-of 收的是 external_member_id，不是 id。

传错的表现是 404 而不是 400 —— 因为那个值在我方看来只是「一个不存在的

外部 ID」。


POST /v1/members/{id}/suspend   { "suspended": true }

这一位只影响该会员在你这边的可用性。停用与恢复共用一条事件（member.suspended），方向靠 data.status 区分。

⚠ 这条事件会来第二次（停用 → 恢复 → 再停用），且 status_version 恒为 0。

它是全部事件里唯一真的要按 created_at 排序的地方 ——

别写「version 相等就跳过」，那会让恢复那条被丢掉，你这边的人永远解不开。

平台级封禁是另一套，你看不到。 会员触犯平台底线时我方会停掉他，那与你这一位无关，也不会因为你恢复而解除。