Rate Limits

API Request Limits

Rate limits are based on your team's total connected social accounts: the more accounts you've scaled to, the higher your requests-per-minute ceiling. Limits use a sliding window, so capacity frees up continuously instead of resetting all at once on a fixed boundary.

One API key is enough — including for multi-tenant integrations serving many customers. Your limit grows automatically as you connect more accounts, so you never need extra keys for throughput. Create additional scoped keys when you want access control (per-tenant isolation, read-only dashboard keys), not more requests.

Connected accounts are counted across the whole billing team (owner + invited members).

Legacy AppSumo lifetime tiers get a flat 600 req/min regardless of tier.

Per-Second Limits for Analytics Endpoints

Analytics endpoints are rate limited on a 1-second window rather than a 1-minute window. The per-second cap is derived from your req/min limit:

requests_per_second = max(6, requests_per_minute / 60)

Every plan has a floor of 6 req/s, sized so a dashboard that fans out several analytics requests per page render doesn't get throttled on the lower tiers.

Legacy AppSumo lifetime tiers get a flat 10 req/s on analytics endpoints regardless of tier.

These endpoints use the per-second window:

• GET /api/v1/analytics
• GET /api/v1/analytics/best-time
• GET /api/v1/analytics/content-decay
• GET /api/v1/analytics/daily-metrics
• GET /api/v1/analytics/post-timeline
• GET /api/v1/analytics/posting-frequency

All other endpoints continue to use the standard 1-minute window from the table above.

Rate Limit Headers

Every API response includes these headers:

Handling Rate Limits

When you exceed the limit, the API returns 429 Too Many Requests:

{
  "error": "Rate limit exceeded. Please retry after 12 seconds.",
  "details": {
    "currentCount": 601,
    "limit": 600,
    "retryAfterSeconds": 12
  }
}

Best approach: check X-RateLimit-Remaining before making requests, and back off when it's low. If you receive a 429, honor the Retry-After header — it's a relative number of seconds, so it works correctly even if your server's clock is skewed. details.retryAfterSeconds carries the same value in the body.

Posting Velocity Limits

Independent of API rate limits, there are per-account limits on how fast you can publish posts to prevent platform-level throttling:

These limits protect your accounts from being flagged by social platforms. If a post is rejected due to velocity limiting, you'll receive a 429 explaining the cooldown period.

Analytics Data Freshness

Analytics endpoints have their own caching and refresh behavior rather than strict rate limits:

• Post analytics - Cached for 60 minutes. Requests trigger a background refresh if cache is stale.
• Follower stats - Refreshed once per day automatically.
• YouTube daily views - Data has a 2-3 day delay from YouTube's Analytics API.

See the Analytics endpoints for details.

Tips for Staying Within Limits

• Use one key per service - Your limit scales with connected accounts, so a single key comfortably serves even a large multi-tenant integration. Reach for scoped keys for access control, not throughput.
• Use pagination - Don't fetch all resources at once. Use limit and skip parameters.
• Cache responses - Store data locally instead of re-fetching frequently.
• Use webhooks - Subscribe to webhooks instead of polling for post status changes.
• Batch operations - Use bulk upload instead of creating posts one at a time.