Rate Limiting
OpenAlex applies rate limits to API requests. Aletheca provides automatic rate limit
handling through bibliofabric's built-in rate limiting, including proactive throttling,
Retry-After header parsing, and exponential backoff on 429 responses.
OpenAlex Rate Limits
| Tier | Rate Limit | Notes |
|---|---|---|
| No key (polite pool) | ~10 requests/second | Requires mailto parameter or User-Agent with contact info |
| API key | Higher throughput | Request at openalex.org |
Without an API key, you are in the "polite pool." The polite pool provides lower priority and slower response times. Adding an API key moves you to a faster pool.
Configuring Your API Key
Environment Variable (Recommended)
export ALETHECA_OPENALEX_API_KEY="your-api-key-here"
.env File
ALETHECA_OPENALEX_API_KEY=your-api-key-here
Programmatic
from aletheca import AlethecaSession
async with AlethecaSession(api_key="your-api-key-here") as session:
...
The API key is sent as a ?api_key= query parameter on every request.
How Aletheca Handles Rate Limiting
1. Proactive Throttling
When enable_rate_limiting=True (default), the client reads rate limit headers
from every response:
X-RateLimit-Limit— total requests allowed in the windowX-RateLimit-Remaining— remaining requests in the windowX-RateLimit-Reset— timestamp when the window resets
If remaining falls below the buffer threshold (rate_limit_buffer_percentage, default 10%),
the client automatically waits until the reset time before sending the next request.
from aletheca import AlethecaSession
from aletheca.config import AlethecaSettings
settings = AlethecaSettings(
enable_rate_limiting=True,
rate_limit_buffer_percentage=0.15, # Start waiting at 15% remaining
)
2. Reactive Handling (429 Responses)
If the API returns a 429 (Too Many Requests):
- The client raises a
RateLimitError. - The retry mechanism catches it and waits based on the
Retry-Afterheader. - If no
Retry-Afterheader is present, it waitsrate_limit_retry_after_defaultseconds (default: 60). - The request is retried up to
max_retriestimes with exponential backoff.
3. Retry with Exponential Backoff
Retries use tenacity with configurable exponential backoff:
from aletheca.config import AlethecaSettings
settings = AlethecaSettings(
max_retries=5,
backoff_factor=1.0, # Wait 1s, 2s, 4s, 8s, 16s between retries
rate_limit_retry_after_default=30, # Wait 30s if no Retry-After header
)
Retryable status codes: 429, 500, 502, 503, 504.
Disabling Rate Limiting
from aletheca.config import AlethecaSettings
settings = AlethecaSettings(enable_rate_limiting=False)
!!! warning
Disabling rate limiting means the client will not proactively throttle or
respect Retry-After headers. You are responsible for staying within limits.
Best Practices
- Always use an API key in production. It provides faster response times and higher throughput.
- Use cursor pagination (
iterate) instead of page-based pagination — it's more efficient and reduces request count. - Set
per_page=200(the maximum) for iteration to minimize requests. - Increase
max_retriesfor batch jobs that may encounter transient rate limits. - Add
backoff_factorproportional to your concurrency level.