Introduction

Fluxcrawl gives you one API for live public data instead of a separate, fragile integration for every platform you touch. Call /v1/{platform}/{endpoint}, get back the same shape every time, regardless of which upstream provider actually answered the request underneath.

The web keeps changing. Fluxcrawl's job is to make sure your interface to it doesn't.

How it works

Every platform/endpoint pair is served by one or more provider adapters, tried in order. If the first one is down, Fluxcrawl falls back to the next one automatically — you never see which provider actually answered, and you never have to handle that failover yourself.

route → fetch (fallback on provider failure) → normalize → respond

For TikTok specifically, that chain today is LamaTok (primary) falling back to scraptik. Both wrap TikTok's own internal mobile API — you get its real fields (like digg_count for likes), just wrapped in Fluxcrawl's own normalized schema so it looks identical regardless of which of the two actually served the request.

Response shape

Every successful response looks like this:

{
  "success": true,
  "platform": "tiktok",
  "data": { ... },
  "meta": { "credits_used": 1 }
}

data is always shaped the same way for a given endpoint, whichever provider served it. See TikTok for what data looks like per endpoint, with real examples.

Failures look like this instead:

{
  "success": false,
  "error": { "code": "RESOURCE_NOT_FOUND", "message": "..." }
}

See Errors for the full list of codes and what each one means.

Quick example

curl 'https://api.fluxcrawl.dev/v1/tiktok/profile?username=tiktok' \
  -H 'X-API-Key: YOUR_KEY'

{
  "success": true,
  "platform": "tiktok",
  "data": {
    "username": "tiktok",
    "display_name": "TikTok",
    "followers": 95800000,
    "verified": true
  },
  "meta": { "credits_used": 1 }
}

That response is real, live data from the actual endpoint — not a mock.