用户、团队与角色
Bird 中的人员访问基于角色：用户在工作区上持有一个角色，每个角色对应一组固定权限。无需其他配置，选对角色即可获得相应权限。
角色控制 人员 在控制面板中能做什么。 服务 能做什么由 API 密钥权限范围控制：同一套权限词汇，按密钥而非按角色授予。
工作区角色
每项权限是一个 {scope, level} 对，其中 level 为 read 或 write（write 包含 read）。角色是这些权限对的命名固定集合：
| 权限范围 | write 的含义 | admin | developer | analyst |
|---|---|---|---|---|
| workspace | 编辑工作区设置（名称、通知） | write | read | read |
| api_keys | 创建和撤销 API 密钥 | write | write | none |
| emails | 发送邮件 | write | write | read |
| email_management | 管理屏蔽列表和邮件配置 | write | write | read |
| email_marketing | 管理联系人、受众和群发 | write | write | read |
| domains | 添加、验证和移除发送域名 | write | write | read |
| webhooks | 配置 webhook 端点 | write | write | read |
| sms | 发送 SMS | write | write | read |
| sms_management | 管理 SMS 发送方、屏蔽列表和设置 | write | write | read |
| verify | 发送和校验验证码 | write | write | read |
| verify_management | 配置验证发送方和国家/地区 | write | write | read |
| 发送 WhatsApp 消息 | write | read | read | |
| whatsapp_management | 管理 WhatsApp 模板和设置 | write | write | read |
| assets | 上传、更新和删除资源及文件夹 | write | write | read |
| compliance | 管理注册身份、提交内容和证明材料 | write | write | read |
| lookup | 查询电话号码、电子邮件地址和身份匹配 | write | write | none |
| mailbox | 发送和回复邮箱消息 | write | write | read |
| mailbox_management | 创建、更新和删除邮箱及接收规则 | write | write | read |
| realtime | 创建应用和发布事件 | write | write | read |
| voice | 读取通话记录和统计数据，以及发起呼叫 | write | write | read |
| voice_management | 管理中继、网关、号码、主叫 ID 和目的地 | write | write | read |
| ip_pools | 查看组织的 IP 池（只读） | read | read | read |
| members | 管理工作区团队和邀请 | write | read | read |
| analytics | 查看报告和送达率分析 | read | none | read |
| audit | 查看审计日志 | read | none | read |
| request_logs | 查看请求日志（只读） | read | read | read |
实际使用中，admin 管理整个工作区，包括团队和设置。developer 可以构建集成、管理域名和 webhook，以及创建 API 密钥。analyst 拥有只读权限。
有两行值得特别说明。ip_pools 即使对 admin 也是只读的，因为购买专用 IP 和管理 IP 池需要组织级别的 org:ip_pools:write 权限范围。WhatsApp 的权限也将管理与消息发送分开。developer 可以通过 whatsapp_management:write 管理模板和设置，但只能通过 whatsapp:read 读取消息；发送仍限于 admin。其他产品使用相同的 {scope, level} 模型添加权限范围。
任何端点返回 403，表示已认证的主体缺少该端点所需的 {scope, level}。解决方法是更改角色（针对人员）或创建具有正确权限范围的新密钥（针对服务）。
组织角色
工作区背后是一个组织，它拥有账单和整体成员列表。两个角色管理该层级：
- owner：全部权限。对组织和工作区操作拥有完整的读写权限。一个组织可以（也应该）有多个 owner。创建账户的人默认为 owner。
- billing_admin：账单和组织设置（org:billing:write、org:settings:write），以及对组织成员列表和工作区元数据的读取权限。无法访问工作区内部的资源。
这些角色在日常中很少用到：大多数团队成员只需要一个工作区角色。
成员与团队
成员资格是隐式的：如果用户持有组织角色或工作区角色，就属于 "in" 你的组织。不存在需要单独管理的成员记录。
你可以在控制面板的 Settings > Team 中管理工作区的人员，由工作区 members 权限范围控制；工作区 admin 无需任何组织级角色即可在此管理团队。团队管理属于人的操作，因此 API 密钥不能持有 members 权限范围（参见身份验证）。
移除某人的工作区访问权限只会移除该角色，不会影响其持有的任何组织角色。将某人从组织中移除则会撤销其全部账户访问权限。他们创建的 API 密钥会继续工作，因为每个密钥独立于其创建者，归属于工作区。
邀请
在 Settings > Team 中，输入邮箱地址并选择角色即可发出邀请，Bird 会自动处理后续流程。按钮背后是一个 智能邀请：同一个流程既能处理已在组织中的同事，也能处理从未接触过 Bird 的新用户。
- 已是组织成员：立即以指定角色加入工作区。无需邮件，无需等待；响应为成员对象。
- 尚未成为成员：Bird 创建一封邀请，向其发送注册链接，响应为带有 pending 状态的邀请对象。链接有效期为 7 天；过期后需重新邀请。
响应中的 type 字段（team_member 或 invitation）表明发生了哪种情况。对同一邮箱发起第二次待处理邀请会返回 409 而非创建重复记录，你可以随时在同一页面撤回待处理的邀请。
Owner 可以邀请其他 owner 或 billing_admin。该邀请需要 org:members:write，只有 owner 持有此权限。
防护机制
无论由谁发起，每次角色变更都会执行两个不变量：
- 最后一个 owner 不可变更。 降级或移除组织中唯一的 owner 会返回 409：组织永远不能没有 owner。请先提升第二个 owner。
- 不能更改自己的访问权限。 更改自己的角色或移除自己会返回 403。这既防止意外自锁，也防止悄悄自我提权；必须由另一个 admin 或 owner 来执行变更。
上下文的选择方式
成员和团队端点存在于两个层级，请求指向哪个组织或工作区取决于其认证方式：
- 会话认证（控制面板或以你的身份操作的工具）按请求提供上下文：在组织级端点上提供 X-Organization-Id，在工作区级端点上提供 X-Workspace-Id。
- API 密钥隐式携带上下文。密钥归属于你的工作区，同时确定了组织；无需请求头，与密钥冲突的上下文请求头会被拒绝并视为格式错误（400）。
参见工作区了解完整的上下文解析模型。
后续步骤
- 身份验证与 API 密钥：服务的权限范围，以及谁可以管理密钥
- 工作区：这些角色所附属的工作区
- 账单与用量：组织级账单角色管理的内容
相关资源
继续查阅此主题的文档、指南和示例。资源为英文。