SocialRouter aggregates multiple scraping providers behind a single API. Each provider has different strengths, pricing, and platform coverage.

​
Provider slug

Every (provider, platform, type) combination has a unique slug of the form <provider>/<platform>/<type>[:<tag>] — for example apify/linkedin/profile.info, brightdata/instagram/post.likes, or apify/googlemaps/place.search:compass. You can find them on the providers page; each row has a copy button. The slug fully and unambiguously identifies the routing target — provider, platform, type, and (optionally) actor variant — in a single field. The :tag suffix is optional and selects a specific actor/dataset variant when the provider exposes more than one for that (platform, type). 
{
  "url": "https://linkedin.com/in/example",
  "provider": "apify/linkedin/profile.info"
}
The same slug grammar is used by both POST /v1/extract (URL-driven) and POST /v1/search (query-driven); the type segment determines which endpoint applies. Providers advertise their search coverage on GET /v1/providers via supported_search_types and search_pricing.

​
How routing works

When you send a request to /v1/extract or /v1/search, SocialRouter:
  1. Parses the provider slug into its components
  2. Looks up the matching service in the provider registry
  3. Builds the chain — the requested provider first, then every other active provider compatible with the same (platform, type) sorted by per-record cost ascending
  4. Calls the head of the chain, normalizes the response, and returns it
  5. If the call fails and fallback is not disabled, walks the chain until one succeeds
The chain is collapsed to the single requested provider when the request sends fallback: false.

​
Current providers

Use GET /v1/providers to see live status and pricing. The catalogue is derived from the provider registry — when a new provider is added, it appears automatically.
Provider availability and pricing can change. Always check the providers endpoint for current information.

​
Failover

If the primary provider returns an error, SocialRouter transparently retries with the next available provider. The response’s provider field identifies the provider that fulfilled the request; when a fallback was used, fallback_from holds the originally-requested provider. You are only charged for the provider that succeeds. See the failover guide for details and per-request opt-out via fallback: false.