SocialRouter adds as little overhead as possible between your request and the upstream source. Most of the time is spent waiting for the source itself.

​
Where time is spent

The vast majority of latency comes from the offer. SocialRouter’s overhead is negligible.

​
Deadlines

Two timers bound every call:
  • Per offer: up to 5 min, clamped to whatever the request budget has left — in practice ~255 s today. A stalled offer is cut off and the chain moves to the next one.
  • Per request: 270 s, just under the 300 s platform function cap. Hitting it returns 504 with request_hard_timeout (or request_soft_timeout when no activity was seen). A soft-timeout is a global abort, not a failover trigger.
Because a single attempt can now use nearly the whole request budget, failover after a timeout is only possible when the first offer gave up early. Failover after an error (network, rate limit, upstream 5xx) is unaffected — those fail fast and leave the rest of the budget to the next offer. When every offer in the chain is spent, the error names what denied the request so you know whether to retry: The last two only ever appear on a run placed on your own provider key — they name what to change, because nobody else can change it. Retrying without changing it will fail the same way. On those same BYOK failures the error carries an extra provider_detail: the provider’s own explanation, sanitized (their wording, with the key you registered scrubbed out and the length capped). It is what distinguishes “your plan does not include this endpoint” from “this endpoint requires a master key” — two different fixes behind one status code. Runs placed on SocialRouter’s own provider accounts never carry it; there is nothing for you to fix there. Every failure that happened after routing began also carries an extraction_id — quote it in a bug report, it ties the response to the run’s routing trail. GET /v1/extractions/{id} replays the same error object afterwards. Larger jobs than that fit in belongs to the asynchronous API (coming).

​
Performance considerations

​
Offer selection matters

Two offers of the same service can differ by several seconds. If latency matters more than resilience, pin the fast one:
Compare offers on GET /v1/services/{platform}/{service} or at socialrouter.io/services.

​
Failover adds latency

When the head of the chain fails, the request takes at least twice as long: the failed attempt plus the successful retry. Pinning an offer removes that tail risk, at the cost of the resilience it buys (see the failover guide).

​
Batch caps

Every offer declares max_inputs. Sending a batch larger than the chain’s biggest cap is rejected. Sending one larger than a particular offer’s cap simply drops that offer from the chain, which can push you onto a slower or pricier one. Check max_inputs before sizing batches.

​
Credit balance checks

When your balance is low, SocialRouter runs extra billing checks that add a few milliseconds. Keep the balance above $5 and set up top-ups before large jobs.

​
Best practices

1

Maintain a healthy credit balance

Keep at least $5-10 in your account so pre-flight billing checks stay cheap.
2

Pick per use case

Need speed? Pin the fastest offer. Need reliability? Leave provider out and let the chain run.
3

Set reasonable limits

limit caps the records returned (max 250). 50 records come back much faster than 250.
4

Parallelize across requests, not inside one

Runs are independent, so send several concurrently rather than growing a single batch past the caps.