鉴权与速率限制
Bearer / X-API-Key / query 三种写法、套餐速率上限、HTTP 状态码语义。
开放平台所有端点统一通过 API Key 鉴权。本页讲清楚三种 Token 写法、套餐速率限制、以及错误响应的语义。
三种鉴权写法
1. Authorization: Bearer(推荐)
bash
curl https://braidrun.com/api/v1/workflows \
-H "Authorization: Bearer dyk_<id>_<secret>"最标准的写法,所有 SDK 默认支持。生产环境优先使用。
2. X-API-Key Header
bash
curl https://braidrun.com/api/v1/workflows \
-H "X-API-Key: dyk_<id>_<secret>"适合某些封闭网络的代理无法转发 Authorization Header 的场景。功能等同于 Bearer。
3. Query 参数 ?api_key=(仅限不能写 Header 的场景)
text
https://braidrun.com/api/webhook-trigger/approval/appr-123/approve?api_key=dyk_<id>_<secret>谨慎使用 query 参数
Query 参数会被记录在浏览器历史、Referer Header、HTTP server 访问日志、CDN 日志中。仅用于必须用 GET 链接形式触发的场景(例如邮件 / Slack / Telegram 一键审批链接),并配合短 TTL 的 Key。绝对不要把 Bearer 优先级让位给 query 参数。
优先级
Authorization: Bearer dyk_…X-API-Key: dyk_…?api_key=dyk_…
从上到下依次尝试,找到一个非空就停止解析。
速率限制
每个 API Key 各自有「每分钟」和「每日」两个上限,按 Key owner 的套餐自动应用。 每个 Key 独立配额,不与同账号的其他 Key 共享。
套餐对照表
| 套餐 | 每分钟 | 每日 |
|---|---|---|
| Free | 60 | 2,000 |
| Pro | 300 | 50,000 |
| Team | 1,200 | 500,000 |
| Enterprise | 6,000 | 不限 |
窗口语义
- 每分钟(minute window) · 使用 epoch 分钟做 key,每分钟边界自动重置(不是从第一次调用算起的滑动窗口)
- 每日(day window) · 使用 UTC 日期做 key,每日 00:00 UTC 自动重置
达到限额时
http
HTTP/1.1 429 Too Many Requests
Retry-After: 38
X-RateLimit-Limit: 60
X-RateLimit-Window: minute
Content-Type: application/json
{
"error": "Rate limit exceeded",
"window": "minute",
"limit": 60,
"retryAfterSeconds": 38
}客户端应当:
- 读取 Retry-After Header(秒数),延迟相应时长后再重试
X-RateLimit-Window告诉您是哪个窗口被命中(minute / day)- 指数退避 + jitter;不要在收到 429 后立即重试
多 Key 切分流量
需要更高吞吐?为不同环境 / 不同集成签发独立 Key,每个 Key 都拿到完整额度。一个 Pro 用户开 3 个 Key 等于 900 RPM 总能力。这也是事故定位的最佳实践——出问题时只需看哪个 Key 的用量异常。
HTTP 响应码
| 状态码 | 含义 | 应对策略 |
|---|---|---|
200 | 成功 | — |
202 | 已接受(启动 execution 时) | 用返回的 executionId 轮询状态 |
400 | 请求体非法(JSON / 字段错误) | 修正请求;不要重试 |
401 | Token 缺失 / 格式错 / 已吊销 / 已过期 / scope 不足 | 重新核对 Token 与 scope;不要重试 |
403 | Token owner 账号已停用 / 锁定 | 联系账号管理员;不要重试 |
404 | 资源不存在或无可见性 | 检查 ID / scope;不要重试 |
409 | 状态冲突(例如审批已被决策) | 重新查询当前状态 |
429 | 速率限制 | 遵守 Retry-After 后重试 |
500/502/503 | 服务端错误 | 指数退避 + jitter,重试 3-5 次 |
为什么 401 不区分原因
Token 缺失、过期、吊销、scope 不足全部统一返回 401,不暴露具体失败原因——这避免了攻击者通过试错探测哪些 Key 存在 / 哪些 scope 已开启。审计日志中保留了完整的失败原因(reason 字段),管理员可以查到。