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. ~500 concurrent requests is reliability guidance, not a hard reject on the 501st.
Under load, requests may queue. Extreme concurrency may yield 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 ~500-concurrent guidance — you can burst harder if balance and infrastructure allow.
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.
Treating ~500 concurrent as a hard wall that returns 429 — it's guidance. 503 under extreme load 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 upstream 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; extreme load may 503 with Retry-After (not charged).
How many requests per second can I make?
No published RPS cap on paid routes. Stay under ~500 concurrent for reliability.
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.