---
title: 速率限制
description: 每合同的速率限制、Retry-After 响应头以及保持在配额范围内的模式。
canonical: https://developer.unico.io/zh-CN/developers/start/rate-limits
locale: zh-CN
generated_by: markdown-export
---

- [/zh-CN/](/zh-CN/)
- [开始](/zh-CN/developers/start/)
- 速率限制

**本页内容# 速率限制

速率限制定义了应用程序在指定时间段内可以向 API 发出的最大请求数。该机制对于维护服务的整体健康性和可靠性至关重要。
### 为什么使用速率限制​

API 稳定性与性能

防止单个客户端以过多请求压垮服务器。
确保所有客户端获得一致且可预测的响应时间。
保护后端服务免受意外流量峰值的冲击。
在基础设施上维持稳定、可控的负载模式。

安全性

加强对攻击尝试（如暴力破解）的防御。
降低分布式拒绝服务（DDoS）攻击的风险。
减少由实现不佳的集成所造成的影响。
限制 API 凭证泄露后可能造成的潜在损害。

资源分配

确保所有客户端对 API 资源的均衡访问。
防止少数用户的滥用行为降低其他用户的体验。
允许根据业务标准和需求对流量进行优先排序。
鼓励更高效、更可持续的 API 使用实践。

### 速率限制的工作原理​

每次 API 调用都会计入允许的每秒请求数限制。默认值为每个租户 **10 RPS**。超出限制时，API 将返回 `HTTP 429 Too Many Requests`。
请向 Unico 团队确认确切的限制按租户配置。在为高吞吐量集成进行规模估算之前，请联系 Unico 团队以确认适用于您账户的限制。
### 处理 429 错误​

申请提高速率限制
如果您的操作将出现请求量增加（临时或永久），请通知 Unico 团队为您的环境提高速率限制。此申请应在请求量实际增加**之前**提出，以避免您的应用程序停止运行。
审查应用程序行为

审计您的代码以识别低效的 API 使用模式。
检 查是否存在无意的循环或冗余的 API 调用。
将请求更均匀地分散到时间轴上，而不是以大批量突发方式发送。

实现缓存

缓存不经常变化的频繁访问数据。
在整个 1 小时 TTL 内使用 OAuth2 访问令牌——不要在每次请求时调用 `POST /oauth2/token`。
实施适当的缓存失效策略。

使用 Webhook 替代轮询
订阅 [Webhook 和事件](/zh-CN/developers/webhooks-and-events) 的 `PROCESS_STATE_FINISHED` 事件，而不是轮询 `GET /client/v1/process/\{id\}`。在高流量情况下，轮询循环很容易耗尽 GET process 的配额。
### 触达限制时会发生什么​

平台将返回：
```
HTTP/1.1 429 Too Many RequestsRetry-After: 12
```

响应头含义`Retry-After`重试前需要等待的  秒数。请遵守此值。
如果 `Retry-After` 缺失，则采用指数退避策略（1s、2s、4s、8s……），上限为 60s。
### 并发注意事项​

速率限制限制每分钟的请求数，但平台在基础设施层面也有**并发上限**。即使您有 100 次/分钟的配额，在同一秒内同时发出 100 个请求也比将其分散到整个分钟内更容易被拒绝。
对于高吞吐量集成，请以稳定的 RPS 为目标，而不是突发式发送。
### Magic Link Webhook 投递​

Trully 对 Webhook V2 有自己的投递配额。Webhook 服务器预计应在 **1 分钟**内响应；响应更慢的请求将被丢弃（用户的流程不受影响）。为确保一致的处理，请快速确认 Webhook 并异步处理。
### 下一步​

[身份验证](/zh-CN/developers/start/authentication) — 令牌缓存策略。
[Webhook 和事件](/zh-CN/developers/webhooks-and-events) — 用推送替代轮询。
[错误代码 > 重试策略](/zh-CN/developers/start/error-codes#retry-policy) — 何时（以及何时不）重试。
最后更新 于 2026年10月8日**