SocialRouter is designed to add as little overhead as possible between your request and the upstream provider. Most of the extraction time is spent waiting for the provider itself.

​
Where time is spent

A typical extraction breaks down as:
PhaseDuration
SocialRouter routing + auth5-20 ms
Provider extraction1-30 s (depends on provider and type)
Response normalization< 5 ms
The vast majority of latency comes from the provider. SocialRouter’s overhead is negligible.

​
Performance considerations

​
Provider selection matters

Different providers have very different response times for the same extraction type. For example, a profile.info extraction might take 1.5s on one provider and 8s on another. By default, SocialRouter routes to the cheapest provider. If latency matters more than cost, specify the faster provider explicitly: 
{
  "url": "https://linkedin.com/in/example",
  "type": "profile.info",
  "provider": "apify"
}
Use the providers endpoint to compare providers and their performance characteristics.

​
Credit balance checks

When your credit balance is low, SocialRouter performs additional checks to ensure proper billing. This can add a few milliseconds of latency. To avoid this:
  • Keep your balance above $5
  • Set up top-ups from the dashboard before running large extraction jobs

​
Failover adds latency

When the primary provider fails, SocialRouter retries with a fallback provider. This means the request takes at least twice as long — the failed attempt plus the successful retry. If you’re latency-sensitive and prefer a fast failure over a slow success, you can pin to a specific provider with the provider parameter. This disables automatic failover.

​
Best practices

1

Maintain a healthy credit balance

Keep at least $5-10 in your account. Low balances trigger more aggressive cache invalidation and additional billing checks.
2

Use the right provider for your use case

If you need speed, test providers individually and pin to the fastest one. If you need reliability, let SocialRouter handle failover automatically.
3

Set reasonable limits

Use the limit parameter to cap the number of records. Extracting 50 records is much faster than extracting 1000.
4

Batch wisely

For bulk extractions, send requests in parallel rather than sequentially. Each extraction is independent and can run concurrently.