What are rate limits on a social API?
Rate limits are caps on how many requests you can send in a time window (or how many can run at once). Official platform APIs often enforce per-app or per-user quotas. On Social Fetch, paid metered /v1/* routes have no enforced requests-per-second cap; your practical limit is credit balance, with free routes (whoami, balance) subject to per-key 429 limits.
Why platforms rate-limit
Official social APIs protect capacity and abuse surfaces. Exceeding a quota usually returns HTTP 429 (or a platform-specific error) until the window resets. Integrators add backoff, queues, and sometimes multiple apps to stay under the cap.
Public-data vendors may meter differently: by credits, concurrency guidance, or both. Always read the product docs instead of assuming Twitter-style windows apply everywhere.
How Social Fetch handles throughput
Paid metered marketplace routes do not enforce rate limits or RPS caps. Run parallel requests as your product needs; stay below about 500 concurrent requests for reliability. If upstream is under pressure, you may see 503 temporarily_unavailable (not charged on metered lookup routes) — retry or back off.
Free routes GET /v1/whoami and GET /v1/balance have per-key rate limits and may return 429. See /docs/credits and /docs/errors.
Designing around limits
On credit-metered APIs, budget spend and concurrency, not just RPS. On quota-based official APIs, plan for window resets and elevated tiers. Persist requestId (or the platform's equivalent) so support can tell a throttle from a bad payload.
FAQ
Does Social Fetch rate-limit paid lookups?
Paid metered /v1/* routes have no enforced RPS cap. Practical limits are credit balance and recommended concurrency (~500). Free whoami and balance routes can return 429.
What should I do on HTTP 429?
On Social Fetch free routes, wait and retry with backoff. On official platform APIs, respect Retry-After when present and reduce request rate.
What about HTTP 503 on Social Fetch?
503 temporarily_unavailable can appear when upstream is under pressure. Those responses are not charged on metered lookup routes. Retry immediately or with gradual backoff.
Where is this documented?
/docs/credits (throughput section), /docs/errors, and /reliability for support posture.