TikTok Shop Scraper API — Products, Reviews, GMV | $20/mo
Pricing
$20.00/month + usage
Scrape TikTok Shop in 6 markets (US, SG, MY, TH, VN, PH): keyword search, categories, full product details with variants, reviews one-per-row, store analytics with GMV estimates and creator profiles. Local prices and currencies. No login, no API key, no proxy setup. Clean JSON, CSV and Excel export.
![TikTok Shop Scraper [NO COOKIES] ✅ avatar](https://images.apifyusercontent.com/19hg3d40D0AYRrOpNZsFNdyRHHdIZBNmXd51M9i64RI/rs:fill:76:76/cb:1/aHR0cHM6Ly9hcGlmeS1pbWFnZS11cGxvYWRzLXByb2QuczMudXMtZWFzdC0xLmFtYXpvbmF3cy5jb20vc0NDU2R3bm1LTUoxUTJzVG4tYWN0b3ItQzk3U1VpTWxiWjc1eDZ1MjItTTRLdXpqR2FERi10aWt0b2stbG9nby1wbmctZmlsZS0xMTY2MTYzNzYyNng0cTF3c2djc3kucG5n.webp){kind=avatar}
shop.tiktok.com/gb/s?q=... and /th/store/... answer a bare 404, and so does a US store URL requested from a Singapore IP. Picking an unsupported mode for a region now fails immediately with a message naming the regions that do serve it, instead of scraping nothing for five minutes.POST /api/shop/brandy_desktop/s/product_list — is routed on every edge except the EU one, so search no longer needs the page. It works in the US, Singapore, Malaysia, Thailand, Vietnam and the Philippines. The keyword travels in load_more_params.search_word, and one call returns up to 199 products (count=200; anything higher answers empty, and offset/cursor/page_token are echoed back unchanged, so 199 is the whole result set). That also lifts the US ceiling: a US keyword used to yield 20-50 products across ten server-rendered pages, and now returns up to 199 in one request. A sorted US search still takes the old page, which is the only surface that applies a sort order. Three markets have no web search and are marked as such in the input: the UK edge routes neither the search page nor the feed endpoint (404 on both, and on the suggestion endpoint and the H5 view too), and Japan and Mexico accept the request but answer with an empty result set for every keyword and every request shape tried.ttwid, plus dkms-token and dkms-type, which carry the edge WAF's verdict on the session. On every non-US edge the search feed refuses any request that presents that pair — code=10000, on every exit IP, from two different proxy providers, signed or not — and serves the very same request with ttwid alone. Measured: full jar 0/6, ttwid only 5/5 with 140-180 products of the market's own catalogue. The search request now drops those two cookies (it has to clear the jar: curl_cffi merges a per-request cookies= mapping into the session's jar rather than replacing it). US is the opposite and keeps its full jar, so the policy is per region.X-Tts-Oec-Bsid does not merely fail to help on this endpoint, it breaks it: in a paired test on one session the plain request returned 20 products and the signed one that followed answered code=10000. Twice.ttwid, plus dkms-token and dkms-type, which carry the edge WAF's verdict on the session. Every non-US edge refuses a search request that presents that pair — code=10000, on every exit IP, from two different proxy providers, signed or not — and serves the very same request with ttwid alone. Measured: full jar 0/6, ttwid only 5/5 with 140-180 products of the market's own catalogue. The search request now clears those two out of the session jar; it has to be the jar, because curl_cffi merges a per-request cookies= mapping into it rather than replacing it. The US edge is the opposite and keeps its full jar, so the policy is per region.X-Tts-Oec-Bsid does not merely fail to help on this endpoint, it breaks it: in a paired test on a single session the plain request returned 20 products and the signed one that followed answered code=10000. Twice over.ttp for the US, sg for SEA/JP/MX, eu for the UK — each with its own unisec loader, core, bssdk and webmssdk bundle and its own msToken host. The sidecar had the US bundles hardcoded, so every signed request made for a non-US storefront carried a signature the wrong service would never accept. All three stacks are now vendored under signer/sdk/<stack>/ and the sidecar is spawned on the one belonging to the region, with the mocked page pointing at that storefront. This is what makes escalation meaningful outside the US at all.proxyConfiguration keep working; the value is simply ignored.https://shop.tiktok.com/gb/store/... is scraped from UK IPs even if the dropdown was left on United States, and a run may mix markets — each query gets the right country. A URL naming a market the Actor cannot reach is rejected up front with the list of supported ones.www.tiktok.com, which answers most non-US residential exits with a WAF challenge instead of the profile (measured 6/6 on Japanese, Mexican and SEA exits, 0/5 on US). That one mode is now pinned to US IPs regardless of the selected region, so it keeps working while the rest of the run stays in its market.storefront (us, gb, th, …) and currency fields on every product, review and store record, and as columns in the dataset views — prices arrive as bare numbers, so a dataset mixing markets was previously ambiguous. Creator rows are left alone: they have no market and no prices./gb, while on Thailand the reverse is true (a warmed session captcha'd 8/8, cold passed 3/3). Each region carries the measured answer instead of one global rule.www.tiktok.com with HTTP 200 and no captcha marker (measured on roughly a third of Apify's Singapore exits), and www.tiktok.com serves a 1.5 KB WAF interstitial that also looks like a normal page. Both are now detected and rotate the session to a new IP rather than surfacing later as "component not found".maxItems is respected exactly. Pages arrive in batches of 20–30, and the last batch used to stream into the dataset whole before the limit was applied — a run capped at 25 items pushed 30. On the pay-per-result plan those extra rows were also billed.Accept-Language header now follows the storefront, and log lines print the market's currency instead of a hardcoded $.SSLError: curl: (35) TLS connect error ... invalid library (0). That error is a residential exit node resetting the TLS handshake, and three network calls on the pagination path had no retry at all — a single reset on any of them killed the whole query, so a category run that had already parsed 15 products pushed 0 items. Every network call now retries (src/net.py), and a request that keeps failing raises NetworkError, which restarts the query on a new proxy IP instead of ending it.code=0 as long as the request carries the cookies TikTok's own page handed out; the X-Tts-Oec-Bsid signer (Node.js sidecar, Bablosoft fingerprint, /bs/rt bootstrap) is spawned only if TikTok answers with code=10000/100000. A 60-product category scrape went from a ~90 s signer warmup plus a hard failure to ~13 s end to end.code=10000 for every unverified session; unsigned requests get the real listing, and the products already rendered on the store page are used as the first page, so store products survive even when the endpoint is risk-controlled.impersonate="chrome" alias follows the newest profile in the installed library (0.15.0 → chrome146), and TikTok blocks the TLS fingerprints of recent Chrome builds — PDP and store pages answered with a captcha on every request. The profile is now pinned to chrome124 (IMPERSONATE in src/signer.py).review_info in the SSR payload) instead of the reviews API, which answers code=10000 for signed and unsigned requests alike. Total review count and the full star breakdown stay exact; sorting, filtering and the item limit are applied to the reviews we actually have. The API is still tried when more reviews are requested than the page carries, so extra pages are picked up automatically if TikTok reopens it.includeReviews no longer makes a second request or starts the signer — the reviews ship with the product page response.signer/fingerprint.json fallback. Bablosoft turned its fingerprint endpoint into a paid one ({"valid":false,"message":"Key is empty"}), and the fallback pointed at a file that did not exist, so category and store runs failed outright. Sessions no longer waste retries on that endpoint either.ttwid cookie from the warmup GET got a captcha on product and store pages.