Rate limiting
Every Happklaar API endpoint is rate-limited. Rate limit state is tracked per token for authenticated requests and per IP address for anonymous requests.
Response headers
Every response from a /v1/* endpoint includes three rate limit headers:
| Header | Type | Description |
|---|---|---|
X-RateLimit-Limit | integer | Total requests allowed in the current window |
X-RateLimit-Remaining | integer | Requests remaining in the current window |
X-RateLimit-Reset | Unix timestamp | Seconds since epoch when the window resets |
These headers are present on every API response, regardless of whether the limit has been reached.
Example response headers:
Code
Rate limit tiers
| Tier | Limit |
|---|---|
| Authenticated (PAT) | 1000 requests per hour |
| Anonymous | 60 requests per hour |
The authenticated limit applies when a valid Authorization: Bearer <PAT> header is present. The anonymous limit applies to requests without a bearer token.
For production integrations, use a PAT. The 60 req/hour anonymous limit is not suitable for regular API usage.
429 response
When the limit is exceeded, the API returns 429 Too Many Requests with a RFC 9457 error envelope:
Code
The retry_after_seconds extension tells you exactly how long to wait before retrying. The limit extension confirms which limit was hit.
Backoff guidance
When you receive a 429 response:
- Read the
retry_after_secondsvalue from the response body (or equivalently, computeX-RateLimit-Reset - <current Unix time>). - Wait at least that many seconds before retrying.
- Apply exponential backoff with jitter if you are retrying in a loop — do not hammer the API immediately after the window resets.
Example retry logic (pseudocode):
Code
Do not use the Retry-After HTTP header alone — the retry_after_seconds field in the response body duplicates that value for environments where response headers are not reliably accessible.