Three-tier rate limiting system with sliding window algorithm protecting the API from abuse while ensuring fair usage.
Jiro uses a 3-tier rate limiting system with a sliding window algorithm. Each request is checked against per-second, per-minute, per-hour, and per-day limits simultaneously — if any window is exceeded, the request is immediately rejected with a 429 status code and a rate_limit_exceeded error.
The system enforces four independent sliding windows per tier: - Per-second — burst protection - Per-minute — sustained throughput - Per-hour — medium-term capacity - Per-day — daily cap
All windows use a sliding algorithm, meaning the window moves with time rather than resetting at fixed intervals.
Rate limit headers are included in every response:
- X-RateLimit-Limit-Sec — max requests per second
- X-RateLimit-Remaining-Sec — requests remaining this second
- X-RateLimit-Limit-Min — max requests per minute
- X-RateLimit-Remaining-Min — requests remaining this minute
- X-RateLimit-Limit-Hour — max requests per hour
- X-RateLimit-Remaining-Hour — requests remaining this hour
- X-RateLimit-Limit-Day — max requests per day
- X-RateLimit-Remaining-Day — requests remaining today
Jiro offers three subscription tiers with different rate limits. Each tier defines per-second, per-minute, per-hour, and per-day request limits, plus a burst size for handling traffic spikes.
| Name | Type | Description |
|---|---|---|
Free | 5 RPS | 5 requests/second, 60/minute, 500/hour, 5,000/day. Burst size: 10. Default for new accounts. |
Pro | 20 RPS | 20 requests/second, 200/minute, 5,000/hour, 50,000/day. Burst size: 50. For professional developers. |
Enterprise | 100 RPS | 100 requests/second, 1,000/minute, 50,000/hour, 500,000/day. Burst size: 200. For high-throughput workloads. |
In addition to per-request rate limits, each tier has monthly usage quotas. Quotas reset on the 1st of each month. If you exceed a quota, subsequent requests of that type are rejected until the next billing cycle.
| Name | Type | Description |
|---|---|---|
Free | 1,000 searches | 1,000 searches, 500 scrapes, 100 AI queries per month. Max 5 concurrent requests. |
Pro | 50,000 searches | 50,000 searches, 25,000 scrapes, 5,000 AI queries per month. Max 20 concurrent requests. |
Enterprise | 1,000,000 searches | 1,000,000 searches, 500,000 scrapes, 100,000 AI queries per month. Max 100 concurrent requests. |
Each search engine has its own RPM limit shared across all users. This prevents any single user from monopolising a particular engine and ensures equitable access. When an engine's limit is reached, requests to that specific engine are rejected while requests to other engines continue normally.
| Name | Type | Description |
|---|---|---|
Google | 10 RPM | 10 requests per minute, burst: 2. Most restrictive due to upstream API constraints. |
Amazon | 10 RPM | 10 requests per minute, burst: 2. Product search with strict rate limits. |
Baidu | 10 RPM | 10 requests per minute, burst: 2. Chinese search engine with conservative limits. |
Bing | 30 RPM | 30 requests per minute, burst: 5. Default engine with moderate limits. |
Brave | 30 RPM | 30 requests per minute, burst: 5. Independent search engine. |
eBay | 15 RPM | 15 requests per minute, burst: 3. Auction and product search. |
YouTube | 20 RPM | 20 requests per minute, burst: 3. Video search. |
Yandex | 20 RPM | 20 requests per minute, burst: 3. Russian-language search. |
DuckDuckGo | 60 RPM | 60 requests per minute, burst: 10. Most permissive engine limits. |
When a rate limit is exceeded, the API returns a 429 status with the following JSON body:
X-RateLimit-Remaining-* headers to proactively throttle