What are rate limits on a social API?
Rate limits cap requests per time window or concurrent load. Official platform APIs enforce per-app quotas with HTTP 429. On Social Fetch, paid metered /v1/* routes have no request quotas — credit balance is the practical limit; extreme concurrency may queue or return 503, not a billed 429.
Why platforms rate-limit in the first place
Official APIs protect shared capacity and cut abuse via per-window quotas — hit the cap, get 429 until reset. Integrators add backoff, queues, and sometimes multiple apps to stay under caps unrelated to spend.
Public-data vendors vary: credits, concurrency guidance, or both. Read the specific product's docs — first-party quotas don't always apply.
How Social Fetch handles throughput
Paid /v1/* routes have no published per-minute or per-day cap. Credit balance is the ceiling. Concurrency is capped at 200 requests in flight per workspace; above that, extra requests get 503, not 429.
Under load, requests may queue. Extreme concurrency, or going over the in-flight cap (reason concurrency_limit), yields 503 temporarily_unavailable with Retry-After — not billed. Free routes (whoami, balance) have per-key limits and can return 429.
What this looks like in practice
A bulk YouTube channel job on an official API is bounded by per-minute quota regardless of compute. On Social Fetch it's bounded by credits and the 200 in-flight cap — no per-minute window to wait out.
Overshooting concurrency yields 503 with Retry-After, not wasted credits — delay, not double billing.
How this compares to typical per-minute quota models
Fixed-window quotas decouple throughput from budget — you can be within spend and still get 429. Social Fetch paid routes tie throughput to credits and your own concurrency, not a clock to wait out.
Common mistakes and misconceptions
Porting 429 backoff logic from official APIs onto Social Fetch paid routes — saturation returns 503, not 429. Handle 429 on free whoami/balance; 503 with Retry-After on paid routes.
Retrying a 503 immediately instead of honouring Retry-After — over 200 in flight it returns 503 concurrency_limit, not 429. It isn't billed; check meta.creditsCharged.
Designing around limits
On credit-metered APIs, budget credits and concurrency, not RPS windows. On quota-based official APIs, plan for resets and elevated tiers.
Persist meta.requestId with retry metadata so support can trace throttle vs bad payload vs a lookup issue.
FAQ
Does Social Fetch have a rate limit?
Paid /v1/* routes: no request quotas; credits are the limit. Free whoami/balance routes have per-key limits and can 429.
What happens if I exceed the rate limit?
429 on free routes — back off. Paid routes: no quota to exceed; over 200 in flight per workspace, or under extreme load, you get 503 with Retry-After (not charged).
How many requests per second can I make?
No published RPS cap on paid routes. Concurrency is capped at 200 requests in flight per workspace.
Does Social Fetch return 429 or 503 under load?
Paid saturation: 503 with Retry-After. 429 reserved for free whoami/balance.
Am I charged credits for a 503 response?
No. 503 and lookup_failed don't complete a lookup. Completed lookups including not_found do charge.
How does this compare to Twitter/X or other official API rate limits?
Official APIs use fixed quotas and 429 regardless of budget. Social Fetch paid routes tie throughput to credit spend.
Should I still implement backoff and retries?
Yes — 429/Retry-After on free routes, 503/Retry-After on paid. Log meta.requestId per attempt.
Where is throughput behavior documented?
/docs/credits (throughput), /docs/errors (429, 503), /reliability.