Apify vs TikHub for TikTok Scraping, Priced Honestly

Neither Apify nor TikHub is "the" TikTok scraper. Apify actors win when you need deep post history and rich per-video fields and are happy to pay per result; TikHub wins when you want a cheap, fast pull of an account's recent posts and can live with a fixed page size. The choice is a billing-shape decision before it is a data-quality decision, and both run behind one wallet, so you never have to guess which contract to sign.

Both providers sit on Monid, a pay-per-call data API marketplace that gives you one key and one wallet to discover, inspect, and run hundreds of external data endpoints without a separate signup per vendor. That means you can price the exact same TikTok job against both sources in an afternoon and let the invoice, not the marketing page, pick the winner.

TL;DR

• Apify actors bill per result: you pay for each row returned, so cost scales with how much history and how many fields you keep.
• TikHub bills per call: one flat charge per request, but its user-posts route returns a fixed page and needs a secUid, not a raw handle, so deep history means many paginated calls plus a resolve step.
• Apify's apidojo/tiktok-scraper takes startUrls (profile, video, search, tag, music, or place URLs) or keywords, caps output with maxItems, and returns rich per-post fields.
• Rule of thumb: deep, field-heavy, one-time pulls lean Apify; shallow, high-frequency, per-account checks lean TikHub.
• Discover and inspect are free on Monid. You only pay on run. Magnitudes live at monid.ai/tools.

The two billing shapes, and why they decide the winner

Per result and per call are not two prices for the same thing. They are two different cost curves, and your job shape sits on exactly one of them.

Apify's apidojo/tiktok-scraper is a PER_RESULT endpoint. Every post it hands back is a billable row, at a fraction of a cent each. Pull ten posts from one profile and you pay for ten rows; pull the last thousand posts across a creator's whole history and you pay for a thousand. The cost tracks the data you keep, which is exactly what you want when the depth is the point and painful when you accidentally leave maxItems wide open.

TikHub's /api/v1/tiktok/web/fetch_user_post is a PER_CALL endpoint. One request is one charge, flat, regardless of how the response comes back. The catch is what a single call returns: this route pages an account's posts a fixed slice at a time and advances with a cursor, so getting a long history is not one cheap call, it is many cheap calls stitched together. For a shallow skim (the most recent posts from one account), that is the cheapest route on the board. For deep history, the call count climbs and the per-call advantage narrows.

A fair comparison

The honest read is a routing rule, not a scoreboard. If you are harvesting a creator's full back catalog, or pulling every post under a hashtag or a trending sound, Apify's URL-and-keyword inputs and deep fields do the job in one endpoint, and the per-result bill is the fair price for real volume. If you are polling a known set of accounts for their newest posts on a schedule, TikHub's flat per-call charge on the recent page is hard to beat, and you never pay for history you already have.

What each one actually returns, and which fields matter

Depth of history is only half the question. The other half is whether the fields you need come back at all.

The Apify actor is the generous one. Point it at a profile URL and each post carries the full engagement set (views, likes, comments, shares, bookmarks), plus hashtags, audio and song metadata, and media URLs. For research, the fields that earn their keep are rarely the follower count. They are per-post views, which tell you real reach, and the audio metadata, which surfaces a sound breaking out before the pile-on. Because startUrls also accepts search, tag, music, and place URLs, one endpoint covers profile harvesting and discovery harvesting without switching tools.

TikHub's user-posts route is leaner and built for a different rhythm. You hand it a secUid and it returns that account's posts a page at a time, advancing with cursor and an optional sort order. It is precise and cheap for "what did this account post lately," but two practical facts shape any plan built on it: the page size is fixed per call, so depth is a pagination loop, and the input is a secUid rather than a @handle, so a pipeline that starts from usernames needs a resolve step to turn each handle into its secUid before this route will answer. Read the exact params yourself with a free monid inspect -p tikhub -e /api/v1/tiktok/web/fetch_user_post before you script against it, because those two facts are the ones people miss.

The one runnable pull, and the cheaper neighbor

Here is a real Apify run. It points at one profile, caps the output so the first bill is small, and waits inline so the result comes straight back.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More details in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add --label main --key <your-api-key>

More details in the CLI quickstart.

Inspect the schema and price for free, then run one profile with a small maxItems:

monid inspect -p apify -e /apidojo/tiktok-scraper

monid run -p apify -e /apidojo/tiktok-scraper \
  -i '{"startUrls":["https://www.tiktok.com/@gordonramsayofficial"],"maxItems":50}' -w

That returns up to fifty posts for the profile, each a billable row at a fraction of a cent. Raise maxItems when you want more history, swap the profile URL for a #hashtag, sound, or search URL to harvest by topic, or pass keywords instead to run a query.

For the TikHub side, do not copy a command blind. Run the free inspect above to read the current query params, resolve your handle to its secUid, then call /api/v1/tiktok/web/fetch_user_post with that secUid and page through with cursor. It is the cheaper route for a shallow, recurring check, and Monid runs it through the same wallet as the Apify job.

Cost, reasoned in magnitudes

We do not print rates, because the unit that matters is cost per useful post, and that depends on your job. Live magnitudes are on monid.ai/tools. The reasoning that survives any price change:

• For a one-time deep pull, Apify's per-result price times your post count is the whole bill, and it is usually the cheaper way to get thousands of field-rich rows in a single sweep.
• For a recurring shallow check of known accounts, TikHub's flat per-call charge on the recent page beats paying per result for posts you mostly already have.
• The crossover is history depth. The deeper you page TikHub for old posts, the more its call count climbs toward what Apify would have charged in one run, so map your depth before you pick.

Because both are the same wallet, the safe move is to run each on one account, compare the returned fields against what TikTok shows by hand, and route the rest of your list to whichever shape wins for that list.

One honest caveat

Field names, coverage, and page sizes shift as TikTok changes and as each provider updates. Do not trust this table over your own run. The Apify actor is the more flexible input surface and the richer output, but it bills for every row, so a runaway maxItems is where a bill quietly grows. TikHub is genuinely cheaper for shallow, frequent pulls, but the secUid requirement and fixed page size are real friction that a handle-first pipeline has to plan around. Inspect both, run one account through each, and let the two invoices decide.

FAQ

Which is cheaper for TikTok scraping, Apify or TikHub? It depends on depth. For a deep, one-time, field-heavy pull, Apify's per-result billing is usually cheaper per useful post. For a shallow, recurring check of known accounts, TikHub's flat per-call charge wins. Magnitudes are on monid.ai/tools.

What does per result versus per call actually change? Per result means every post returned is a billable row, so cost scales with the data you keep. Per call means one flat charge per request, but TikHub's user-posts route returns a fixed page, so deep history is many calls, not one.

Can I pass a plain @handle to both? To Apify, yes: startUrls accepts profile URLs directly. To TikHub's fetch_user_post, no: it needs a secUid, so a handle-first pipeline adds a resolve step. Confirm the params with monid inspect -p tikhub -e /api/v1/tiktok/web/fetch_user_post.

Do I need two accounts to compare them? No. Both Apify and TikHub are reachable from one Monid wallet, billed pay-as-you-go at the price shown before you run.