⚡ Why Rate Limits Exist
ConnectHub enforces rate limits to maintain platform stability, ensure fair resource distribution across all developers, and protect against malicious traffic. These limits are calculated per API key, per user token, and per endpoint group.
Important: Exceeding rate limits will result in a 429 Too Many Requests response. Repeated abuse may trigger temporary API key suspension.
📊 Current Rate Limits
Limits are enforced using a sliding window algorithm. Burst allowances are included where noted.
| Scope | Category / Endpoint | Window | Limit | Burst | Notes |
|---|---|---|---|---|---|
| Global | All API Endpoints | d>1 hour10,000 req | 100/min | Hard ceiling per API key | |
| Per-User | Profile & Settings | 1 hour | 2,000 req | 50/min | Shared across user-scoped tokens |
| Content | Posts, Comments, Likes | 1 hour | 5,000 req | 150/min | Write operations count double |
| Real-Time | Webhooks & Streams | 1 minute | 1,000 req | 1,000/min | High throughput allowed for live data |
| Auth | Token Refresh / Login | 1 hour | 200 req | 10/min | Prevents credential stuffing |
| Search | Discovery & Graph API | 1 hour | 3,000 req | 200/min | Heavy read operations |
🔑 Response Headers & Status Codes
Every API response includes rate limit headers to help you track usage and adjust your requests accordingly.
Best Practice: Always monitor X-RateLimit-Remaining and implement automatic throttling when it drops below 10%.
🛡️ Handling Rate Limits Gracefully
🔄 Exponential Backoff
When receiving a 429 status, don't retry immediately. Use exponential backoff with jitter:
- Wait 2^N seconds (N = retry attempt)
- Add random jitter (0-500ms)
- Cap retries at 5 attempts
📦 Batch & Cache
Reduce request frequency by optimizing your architecture:
- Use batch endpoints where available
- Cache read-heavy responses (TTL: 60-300s)
- Dequeue non-critical writes asynchronously
📈 Monitor & Alert
Set up internal tracking to prevent unexpected throttling:
- Log rate limit headers per service
- Alert when remaining < 15%
- Track reset timestamps to sync queues
⚙️ Idempotency Keys
Prevent duplicate operations on retries:
- Send
Idempotency-Keyheader - Guarantees safe retries on POST/PUT
- Valid for 24 hours post-creation
📈 Need Higher Limits?
If your integration requires sustained throughput beyond the public limits, you can request a custom tier. We review applications based on traffic patterns, use case justification, and compliance with our API guidelines.
Apply for increased limits: Email api-support@connecthub.dev with your API key, estimated daily volume, and use case description. Enterprise plans include automatic 10x-50x limit boosts.
❓ Frequently Asked Questions
Do rate limits reset daily or hourly?
Limits reset on a sliding 1-hour window. The exact reset time is provided in the X-RateLimit-Reset header as a Unix timestamp.
Are webhooks counted toward limits?
No. Incoming webhook deliveries are separate from API request quotas. However, outbound requests triggered by your webhook handler count normally.
What happens if I get suspended?
Temporary suspensions last 1-24 hours depending on severity. You'll receive an email notice with instructions to resolve the issue and restore access.
Can I track limits in the dashboard?
Yes. The ConnectHub Developer Dashboard provides real-time usage graphs, alert configuration, and historical limit analytics under Settings → API Usage.