通知与推送 API
本页接口都位于 /api/v1,但包含两个不能互换的身份面:
字段、枚举和响应 Schema 以当前 OpenAPI为最终事实源。
可信业务服务准备
- 在 Admin 创建启用状态的 API Client,设置到期时间和可选 CIDR。
- 分配
notify.message.submit;查询还需要notify.message.status.read。 - 广播到全部有效 App 成员需要
notify.message.broadcast。 - 提交
news_operations还需要notify.operations.publish。 - 在 API Client 的应用授权中显式选择目标 App;空 allowlist 默认拒绝。
- 调用
/auth/client-token换取短期ak-apiJWT。Machine Principal 不签发 Refresh Token。
提交通知
接口:/apps/{app_id}/notifications
成功返回 202 Accepted、message_id、run_id、当前状态、status_url 和创建时间。它表示消息已进入异步流水线,不表示厂商或设备已经接收。
模板内容和受控内联双语内容必须且只能选择一个。请求不接受原始 Token、任意 URL、组件名、脚本或厂商特有载荷。
幂等与取消
Idempotency-Key 长度为 8–255。当前服务按 tenant 与调用身份(M2M 场景即 API Client)隔离,因此同一 API Client 应在它获准访问的所有 App 和来源之间生成全局唯一键。相同键与相同规范化请求体返回原提交;相同键对应不同请求体时返回 409 NOTIFY.IDEMPOTENCY.CONFLICT。
- 查询状态:
/apps/{app_id}/notifications/{message_id} - 取消消息:
/apps/{app_id}/notifications/{message_id}/cancel
状态包含收件人、已评估、设备投递、厂商受理、失败、无效 Token、跳过和打开计数。取消只阻止尚未进入发布或扇出的消息,无法撤回厂商已经受理的通知。
Mobile 当前用户接口
以下请求使用 ak-mobile Bearer Token 和当前 App 上下文:
设备注册请求包含 provider、platform、build variant、Token、规范化语言、SDK 版本和 App 版本。tenant、App、user 和业务设备 ID 从已验证会话与应用上下文派生,不接受客户端覆盖;响应永远不返回 Token。
内部 Go 调用
同一模块化单体内的业务优先依赖 server/internal/platform/notification.Service:
需要与业务事实原子提交时使用 SubmitTx。可信 Scope 由调用方或认证中间件构造,不能从 HTTP Body 中复制 tenant、App 或 actor。业务模块不应直接写 notify.* 表或插入 River Job。
常见错误
日志和审计不记录 Access Token、设备 Token 或完整消息载荷。运行状态与失败处理方式见消息运营工作台;异步语义见消息推送架构。