The API enforces per-client rate limits to ensure fair access for all subscribers.
Limits
| Window | Limit |
|---|---|
| Per minute | 100 requests |
| Per day | 10,000 requests |
Limits are applied per API key using a fixed window: each window starts at your first request and the counter resets when it expires. Both windows apply simultaneously, and whichever is closest to exhaustion is the one reported in the response headers.
The unauthenticated POST /v1/invites/claim endpoint is limited separately, by IP address,
at 10 requests per 15 minutes.
Rate limit headers
Responses include headers for monitoring current usage (in the rare event the limit store is unavailable, requests are allowed through unthrottled and these headers are omitted rather than reporting numbers that were not measured):
| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum requests allowed in the current window |
X-RateLimit-Remaining | Requests remaining in the current window |
X-RateLimit-Reset | Unix timestamp when the window resets |
Retry-After | Seconds to wait before retrying (only on 429 responses) |
Exceeding a limit
A request over the limit is rejected with 429 Too Many Requests and a Retry-After header
giving the seconds until the window resets:
{
"error": "Too many requests — please try again later",
"retryAfterSeconds": 42
}Wait for Retry-After before retrying. Retrying sooner is simply rejected again — the window
does not extend, so an early retry costs nothing but delays nothing either.
Caching guidance
H2GC data is updated on a monthly cadence. Responses can be safely cached for the remainder of the month without risk of missing updates. A local cache significantly reduces the total request count and is the recommended approach regardless of rate limits.
Increasing limits
Organisations that require higher limits should contact the H2GC team to discuss available options.