Rate Limiting Overview
Fetchin implements two types of rate limiting to ensure fair usage and system stability:- Per-second rate limit: Configurable per plan (default: 5 requests per second)
- Monthly quota: Based on your plan (1,000 for Trial, custom for Enterprise)
Rate Limit Structure
Per-Second Limit
Plan-basedTrial: 5 requests/second
Enterprise: Custom RPS
Monthly Quota
Plan-basedTrial: 1,000 credits/month
Enterprise: Custom
Per-Second Rate Limit
Your per-second rate limit depends on your plan. Trial plans have a default of 5 requests per second, while Enterprise plans can have custom limits.How It Works
- Requests are counted using a sliding window algorithm
- After exceeding your RPS limit, subsequent requests return
429 - The limit is per API key and applies across all endpoints
- Most endpoints cost 1 unit per request;
/post/engagementcosts 2 units, so your plan’s per-second limit must be at least 2 to call it - Your specific RPS limit is visible in your dashboard
Example (with 5 RPS limit)
Monthly Quota Limiting
Total credits allowed per month based on your plan:- Trial Plan: 1,000 credits/month
- Enterprise Plan: Custom limits
How It Works
- Each successful API request consumes credits from your monthly quota
- Failed requests (errors) also count toward quota
- Quota resets on your renewal date (monthly anniversary of signup)
- Unused credits do NOT carry over to next month
Handling Rate Limit Errors
429 vs 402
The two limits return different HTTP statuses so you can tell them apart from the status line alone (thecode field carries the same distinction):
Per-second limit exceeded — 429 Too Many Requests (code: "RATE_LIMITED").
Back off and retry, honoring the Retry-After header (seconds):
402 Payment Required (code: "QUOTA_EXHAUSTED").
Upgrade your plan or wait for renewal; retrying won’t help until then, and there
is no Retry-After:
Response Headers
Each API response includes rate limit headers:X-RateLimit-Limit: Requests allowed per second (5)X-RateLimit-Remaining: Requests remaining this secondX-RateLimit-Reset: Unix timestamp when limit resets
Rate limit headers show per-second limits. Check your dashboard for both your RPS limit and monthly quota information.
Best Practices
1. Respect Your RPS Limit
Space out your requests to stay under your rate limit (default: 5 per second for Trial plans):2. Implement Retry Logic with Backoff
3. Use Concurrency Control
Limit concurrent requests to respect the rate limit:4. Check Quota Before Bulk Operations
Before processing large batches:- Check remaining quota in dashboard
- Calculate how many requests you need
- Process in chunks if quota is low
3. Queue Requests
For high-volume applications, implement a request queue:5. Cache Aggressively
Store results to avoid repeat requests:Common Scenarios
Batch Processing
Processing 100 profiles at 5 req/s:Real-Time Applications
For real-time applications making frequent requests:- Implement request queuing
- Use websockets for updates when possible
- Cache frequently accessed data
- Batch multiple data points into single requests
Error Responses
429 Too Many Requests (Per-Second)
- Wait 1 second before retrying
- Implement request spacing based on your RPS limit
- Use rate limiting library
402 Payment Required (Monthly Quota)
- Wait for quota renewal
- Upgrade to higher quota plan
- Purchase additional credits (coming soon)
Monitoring
Track your rate limit compliance:- Dashboard - View daily usage patterns and monthly quota
- Error rate - Monitor
429(rate limit) and402(quota exhausted) errors - Response headers - Check
X-RateLimit-*headers in responses - Success rate - Ensure efficient request usage