Rate limits
Two surfaces:
- API (bearer token). A key can carry its own per-minute rate limit and
monthly quota, set per service. If you go over either one, the call returns
429. A coarse burst backstop can also return429, even on a key with no limit set. It counts per key and per client IP. The platform checks these limits before it checks your credits. When you reach your plan's credit allowance, calls return402until the allowance resets at the start of your next period (see Credits & pricing). - Web / SSO sessions. Browser-driven traffic has a separate per-minute and
per-hour interaction cap (bot and scrape protection), tuned per plan. Over the
cap returns
429.
Handling 429
When you go over a rate limit you get 429 Too Many Requests. Most 429s carry a
Retry-After header in seconds. Wait for that many seconds, then retry:
HTTP/1.1 429 Too Many Requests
Retry-After: 2
X-Hank-Error-Code: RATE_LIMIT
A burst-backstop 429 also carries X-Hank-RateLimit-Scope. The value is
token or ip, and it tells you which counter stopped the call.
The one exception is a monthly quota 429. It carries
X-Hank-Error-Code: QUOTA_EXCEEDED, plus the X-Hank-Quota-Limit and
X-Hank-Quota-Used headers. It carries no Retry-After, because the reset
is days away. A back-off loop will not clear it. Raise the key's quota at
API Keys, up to your plan ceiling, or wait for the period
to roll over. A limit that your Hank admin set shows a "set by admin" tag.
Only your admin can change that limit.
A rotated key keeps the same limits and the same counts, so rotation does not reset the monthly quota or the per-minute rate window. A new key starts its own counts, but your organization shares one credit allowance across every key.
Add a client-side throttle or debounce. A throttle stops a person from breaking the limit by accident, and it slows an automated client before the request reaches the server.