Our API implements rate limiting to ensure fair usage and protect the system from abuse. This page details our rate limiting policies and how to handle them effectively.Documentation Index
Fetch the complete documentation index at: https://docs.hyperline.co/llms.txt
Use this file to discover all available pages before exploring further.
Rate limits
Core API
| Operation Type | Limit | Window |
|---|---|---|
| Read (GET) | 200 | 10 seconds |
| Write (POST, PUT, PATCH, DELETE) | 50 | 10 seconds |
Events ingestion API
The events ingestion API has separate rate limits:| Operation Type | Limit | Window |
|---|---|---|
| All requests | 1,000 | 10 seconds |
POST /v1/events/batch: maximum of 5,000 events per requestDELETE /v1/events: maximum of 5,000 event IDs per request
Rate Limit Headers
API responses include the following rate limit headers:X-RateLimit-Limit: The maximum number of requests allowed in the current windowX-RateLimit-Remaining: The number of requests remaining in the current windowX-RateLimit-Reset: The date and time when the rate limit window resetsRetry-After: The minimum number of seconds to wait before retrying (only when the limit has been reached)
Handling Rate Limits
When you exceed the rate limit, the API will return a 429 Too Many Requests HTTP status code. The response body will be:Best Practices
- Monitor Rate Limits: Track the
X-RateLimit-Remainingheader to anticipate when you’re approaching the limit - Implement Backoff: When you receive a 429 response:
- Wait until the date specified in the
X-RateLimit-Resetheader - Consider implementing exponential backoff for retries
- Wait until the date specified in the
- Batch Requests: When possible, combine multiple operations into a single request
- Caching: Cache responses when appropriate to reduce the number of API calls

