Skip to main content
Hexagraph enforces rate limits per IP address to ensure fair, stable access for all users. These limits apply to all REST and GraphQL requests. If your integration exceeds a limit, requests will be rejected until the window resets — so understanding and designing around limits upfront will save you from unexpected interruptions.

​
Current Limits

WindowLimit
Per minute30 requests
Per day1,000 requests
Both limits are tracked independently. Staying within the per-minute limit doesn’t protect you from exhausting the daily quota, and vice versa.

​
Checking Your Usage

Send a GET request to /rate-limit at any time to see your current consumption against both windows: 
curl https://hexagraph-core.onrender.com/rate-limit
Example response: 
{
  "rateLimit": {
    "minute": {
      "current": 12,
      "limit": 30
    },
    "day": {
      "current": 47,
      "limit": 1000
    }
  }
}
The response shows your current request count alongside the applicable limit for each tracked window. Use this endpoint to monitor consumption before launching large batch operations.

​
When Limits Are Exceeded

When you exceed a rate limit, Hexagraph returns an HTTP 429 Too Many Requests response: 
{
  "error": "Too Many Requests",
  "message": "Rate limit exceeded. Please wait before sending additional requests.",
  "statusCode": 429
}
The request is not queued — it is rejected immediately. Your client is responsible for backing off and retrying.

​
Designing Around Rate Limits

Follow these practices to stay within limits and build a more resilient integration:
  • Cache responses on your side when the same entity is requested multiple times. If your application frequently looks up the same output or author, store the result locally rather than re-fetching it on every use.
  • Use GraphQL to batch lookups. A single GraphQL request can resolve multiple entities of different types simultaneously, dramatically reducing the number of requests needed for complex operations.
  • Use per_page thoughtfully. Request only the records you need in each call. Fetching excessively large pages wastes quota on data you may not use.
  • Implement exponential backoff. When you receive a 429 response, wait before retrying. Start with a short delay and double it on each subsequent failure to avoid hammering the API during a limit window.
  • Monitor usage proactively. Call GET /rate-limit before initiating large batch operations to confirm you have sufficient headroom in both the per-minute and per-day windows.
GraphQL lets you query multiple entity types — for example, an output, its authors, and their institutions — in a single request. This makes it the most quota-efficient approach for complex or relational lookups.