Unif API Docs速率限制
面向智能体工作流和 HTTP 调用的按工作区、按操作的限制、响应头以及重试行为。
UnifAPI 实施两层速率限制：一层是按工作区的限制，用于在所有 Skills 和 API 调用之间平滑流量；另一层是按操作的限制，用于保护每个公开数据来源。
响应头
每个响应——无论 2xx 还是 429——都携带标准响应头：
| 响应头 | 含义 |
|---|---|
X-RateLimit-Limit | 当前窗口内允许的请求数 |
X-RateLimit-Remaining | 当前窗口内剩余的请求数 |
X-RateLimit-Reset | 窗口重置时的 Unix 时间戳（秒） |
Retry-After | 重试前需等待的秒数（仅 429） |
当工作区限制和端点限制同时适用时，响应头报告其中更严格的那一个。
默认值
| 套餐 | 工作区限制 | 按端点限制 |
|---|---|---|
| Free | 60 req/min | 来源感知 |
| Pay-as-you-go | 600 req/min | 来源感知 |
| Enterprise | 自定义 | 自定义 |
处理 429
async function call(url: string, init: RequestInit, attempt = 0): Promise<Response> {
const res = await fetch(url, init);
if (res.status !== 429 || attempt >= 5) return res;
const retryAfter = Number(res.headers.get("Retry-After") ?? 1);
await new Promise((r) => setTimeout(r, retryAfter * 1000));
return call(url, init, attempt + 1);
}两条需要牢记的规则：
- 遵守
Retry-After。 UnifAPI 会返回操作所需的等待时间——靠猜测通常只会让情况更糟。 - 对反复出现的 429 进行退避。 如果一个 Skill 连续多次触发限制，请缩小查询范围、降低并发，或提高工作区限制。
突发行为
限制采用令牌桶机制：一个空闲了一分钟的工作区可以短暂地突破其稳态限制。不要在生产流量中依赖这一点——请按稳态速率来设计。
申请更高限制
需要更高的限制？发邮件至 support@unifapi.com，附上你的工作区 ID、你正在运行的 Skill 或操作，以及一个大致的 QPS 估计。