Rate Limits
API requests are rate-limited per API key using a sliding window algorithm. Limits are applied per minute and per day. Exceeding either limit returns HTTP 429.
Tiers
| Tier | Requests / minute | Requests / day | Burst |
|---|---|---|---|
| Free | 60 | 1,000 | 10 |
| Starter | 300 | 10,000 | 50 |
| Pro | 1,000 | 50,000 | 200 |
Contact [email protected] for higher-volume plans.
Rate limit headers
Every successful response includes these headers:
| Header | Description |
|---|---|
X-RateLimit-Limit | Requests per minute allowed for your key |
X-RateLimit-Remaining | Requests remaining in the current window |
X-RateLimit-Reset | Unix epoch when the current window resets |
Rate limit exceeded
When you exceed the limit, you receive HTTP 429 with an additional header:
HTTP/2 429 Too Many Requests
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1746345720
X-RateLimit-Retry-After: 47
{
"errors": [{
"message": "Rate limit exceeded",
"extensions": {
"code": "RATE_LIMIT_EXCEEDED"
}
}]
} X-RateLimit-Retry-After is seconds until you can retry.
Best practices
- Cache responses. Prayer times and masjid data change infrequently. Cache at the edge or in your backend.
- Use webhooks instead of polling. Subscribe to
prayer_times.updatedrather than fetching iqamah schedules on every page load. - Respect Retry-After. Implement exponential backoff starting
from the
X-RateLimit-Retry-Aftervalue. - Request only what you need. Select only the GraphQL fields your application uses.
Sandbox
The sandbox environment has no rate limits. Use it for development and testing.