Hexagraph is an open access API — no API key, bearer token, or authentication header is required to make requests. You can begin querying scholarly metadata immediately without registering for an account or generating credentials. Access controls are enforced through rate limiting to ensure fair, equitable usage for all consumers.
Access Model
All Hexagraph API endpoints — REST and GraphQL — are publicly accessible without authentication. There are no protected routes, token scopes, or subscription tiers. Rate limiting is applied per IP address, so usage from multiple clients behind the same IP is counted together toward the shared quota.
This model is intentional: Hexagraph is built on open scholarly infrastructure (OpenAlex, Crossref) and is designed to be as frictionless as possible for researchers, developers, and institutions to integrate into their workflows.
Rate Limits
To maintain performance and availability for all users, Hexagraph enforces the following request limits:
| Window | Limit |
|---|
| Per second | — |
| Per minute | 30 requests |
| Per day | 1,000 requests |
Checking Your Usage
You can inspect your current rate limit usage at any time by calling the /rate-limit endpoint:
curl https://hexagraph-core.onrender.com/rate-limit
{
"minute": {
"limit": 30,
"used": 7,
"remaining": 23,
"reset_in_seconds": 41
},
"day": {
"limit": 1000,
"used": 143,
"remaining": 857,
"reset_at": "2025-01-15T00:00:00Z"
}
}
Rate Limit Errors
When you exceed either the per-minute or per-day limit, the API returns an HTTP 429 Too Many Requests response. The response body identifies which limit was breached and how long to wait before retrying:
{
"error": "rate_limit_exceeded",
"message": "You have exceeded the per-minute request limit of 30 requests. Please wait before retrying.",
"window": "minute",
"retry_after_seconds": 34
}
retry_after_seconds field tells you the minimum number of seconds to wait before your next request will succeed. Respect this value in your client logic to avoid compounding blocks.
Best Practices
Follow these guidelines to stay within your quota and get the most out of Hexagraph:
- Cache responses on your end — Hexagraph already uses server-side caching, but caching responses in your own application avoids redundant API calls for the same data
- Batch queries with GraphQL — Instead of making multiple REST requests for related entities, use a single GraphQL query to fetch nested data (e.g. a work and its authors’ institution affiliations) in one round-trip
- Use
per_page to right-size result sets — Only request as many results as you need per call; avoid fetching maximum pages when a smaller set will suffice
- Implement exponential backoff on
429 errors — If you receive a rate limit response, wait for the retry_after_seconds interval, then retry with increasing delays (e.g. 1s → 2s → 4s → 8s) if errors persist
- Avoid redundant polling — For static or slowly-changing records (works, authors), consider storing responses locally rather than re-fetching on every run
Repeatedly exceeding rate limits in rapid succession may result in a temporary block on your IP address beyond the standard reset window. If you believe your IP has been blocked in error, reduce your request frequency and allow several minutes before retrying.
