TikAPI alternative: ScrapingBot vs TikAPI

TikAPI and ScrapingBot overlap on public TikTok data: profiles, videos, sounds, comments, followers and search. They split on two questions. Do you need to act as a TikTok user, and is your volume shaped by the day or by the month?

The short version

ScrapingBot vs TikAPI at a glance

The TikAPI figures assume a 30-day month at the full daily limit: Starter is 300 × 30 = 9,000 requests for $29, or $3.22 per 1,000. Days you don't use don't carry over. Bandwidth can run out before requests do if you download media; extra bandwidth is sold separately.

Daily caps vs a monthly pool

TikAPI counts your requests over the last 24 hours, starting from your first request. On Starter, the 301st request in that window returns 429 with "API Key Rate-Limit reached." That is predictable for a steady trickle and awkward for batch jobs: walking a viral sound with 5,000 videos takes about 500 pages, nearly two days of Starter's allowance.

ScrapingBot has no per-day number. The same 500 pages cost 500 credits and finish as fast as your concurrency allows, and the remaining credits stay available for the rest of the month. The trade-off is that unused credits don't carry into the next month.

Coverage

Public endpoints line up closely. TikAPI has /public/music and /public/music/info for sounds, comment and reply lists, followers and following by secUid, and search for users, videos and autocomplete. ScrapingBot has the matching /music/posts, /music/info, /comment/list, /comment/reply, /user/followers, /user/following, /user/search and /feed/search. ScrapingBot's follower lists return one page of up to 50 accounts.

Beyond that, TikAPI is the only one of the two that can sign in as a user, which is what you need for inbox tools, scheduling or creator dashboards built on a creator's own analytics. ScrapingBot instead adds Instagram, Google and Amazon data on the same balance.

Migrating from TikAPI

TikAPI uses one GET path per endpoint with an X-API-KEY header. ScrapingBot uses one POST URL with the endpoint in the body. The videos that use a sound, before and after:

// Before: TikAPI
const res = await fetch(
  "https://api.tikapi.io/public/music?id=7682907287056337667&count=30",
  { headers: { "X-API-KEY": process.env.TIKAPI_KEY } },
);
const page = await res.json();
const items = page.itemList;
const next = page.hasMore ? page.cursor : null;

// After: ScrapingBot
const res = await fetch("https://scrapingbot.io/api/v1/tiktok", {
  method: "POST",
  headers: { "x-api-key": process.env.SCRAPINGBOT_KEY, "Content-Type": "application/json" },
  body: JSON.stringify({ endpoint: "/music/posts", params: { music_id: "7682907287056337667", count: 30 } }),
});
const page = (await res.json()).data;
const items = page.videos;
const next = page.hasMore ? page.cursor : null; // send back as params.cursor

Two things change in your parsing. TikAPI returns errors as {"status": "error", "message": …}; ScrapingBot returns {"success": false, "error": …} with a matching HTTP status. And ScrapingBot's videos are flat objects (video_id, title, play_count, digg_count, author.unique_id), so map those fields once. /user/info returns data.user and data.stats with TikTok's own names, such as followerCount.

Common questions