Third-Party Data Vendors

Five jobs, four actors — apify/instagram-scraper is used twice for two different purposes.

A routine refresh makes two calls in sequence. First apify/instagram-profile-scraper is asked {"usernames":[handle]} and returns the profile — and 12 complete posts inside the same reply. Then apify/instagram-scraper is asked for posts and buys those same posts again. That is the whole story of this tab.

Comments come from scrapesmith/instagram-comments-scraper, which needs post URLs and therefore cannot run until posts exist. Commenter profiles then need usernames from the comments, so the chain is three deep: posts → comments → commenter profiles. Followers come from scraping_solutions/instagram-scraper-followers-following-no-cookies and need only the handle.

Bright Data serves nothing on Instagram except the Web Unlocker, which rescues a blocked single-post fetch.

Comparing the two live runs key by key, the bundle holds 14 of the 17 fields the dashboard stores. Every "how often" number below is counted straight from the database. The three gaps and their answers:

So the honest claim is one call covers every stored field on about 97% of posts, with a rare second call for the rest — provided the two top-up branches are actually built. Leave them out and the saving is real but 117 rows of data stop being collected.

One thing to know about views: it is filled on only 102 of 482 Instagram posts, because Instagram publishes a view count for videos only — and there are 103 videos. That does not change the decision to reject apidojo, which returned no view count on any post, video or not.

Seven jobs across two vendors — the only platform where Bright Data and Apify compete for the same work.

Posts have two tiers. The registry names Bright Data's gd_lkaxegm826bjpoo9m5 primary at $0.0015, with apify/facebook-posts-scraper as the fallback. In practice the fallback does almost everything — 302 of 310 stored posts — because Bright Data takes 40.5 s against Apify's 5.3 s.

The page profile is a separate paid call to apify/facebook-pages-scraper: it is the only source of an exact follower count, and it returns no posts, so there is no Instagram-style bundle to exploit here.

Comments come from apify/facebook-comments-scraper and need post URLs from the posts job. One post by URL goes to danek/facebook-posts-fast, resharers to danek/facebook-posts-share-scraper, and the Meta ad library to apify/facebook-ads-scraper.

Two things Facebook cannot do at any price: page followers are not enumerable (verified across three candidate actors — none returns the people), and a Page has no public following list. Both are platform limits.

Five jobs, and TikTok is already on the cheapest wiring in the project.

apidojo/tiktok-scraper does two jobs at once: it takes a profile URL or a video URL in the same startUrls field, and it returns the full channel object with every post — so the profile costs nothing extra. At $0.0003 a post it is the cheapest post source of any platform here.

Bright Data's gd_l1villgoiiidt09ci sits behind it as a fallback. It works, but it returns top posts ranked by engagement rather than a chronological history, so it can miss a brand-new post.

Comments come from apidojo/tiktok-comments-scraper and need post URLs. Followers come from clockworks/tiktok-followers-scraper and need only the handle. Ads come from data_xplorer/tiktok-ads-library-fast, searched by advertiser name rather than id.

Not obtainable at any price: per-post resharer lists. All three "TikTok Repost Scraper" actors take profile links and answer a different question.

Five jobs across four actors, and the best-mapped platform in the project — likes, comments_count, shares, reposts_count, quotes_count, bookmarks_count, thread_id and posting_tool are all 398/398.

Posts run through apidojo/tweet-scraper. The tier resolver is called, but pull-data-x.js line 45 hardcodes the run URL, so the resolver's answer is discarded — see the misconceptions below.

Replies are the one place xquik/x-tweet-scraper is used, in conversationIds mode, and it reuses posts.thread_id so it needs the posts job first. One tweet by id goes to kaitoeasyapi/twitter-x-data-tweet-scraper-pay-per-result-cheapest, followers to kaitoeasyapi/premium-x-follower-scraper-following-data, and retweeters to api-ninja/x-twitter-replies-retweets-scraper.

Bright Data cannot serve X at all: its gd_lwxkxvnf1cynvib9co dataset needs a specific tweet URL and cannot enumerate a profile.

posting_tool records "Twitter Web App" or "Twitter for iPhone". It is complete data, but no tab, chart or filter reads it. If it stays unused, the switch costs nothing at all.

YouTube is the only one of the seven networks with a genuinely free enumeration route, and it is wired free-first.

A pull starts by asking fetchFree(). That resolves the channel id once (cached on the account), reads the public RSS feed at feeds/videos.xml?channel_id=…, then enriches each video through the official YouTube Data API v3 to fill the like and comment counts RSS omits. No key for RSS; the Data API needs YOUTUBE_API_KEY and gives 10,000 units a day free.

fetchFree() returns null the moment limit > 15 — the RSS feed carries only 15 entries. FIRST_PULL_LIMIT is 30, so every initial backfill falls straight through to streamers/youtube-channel-scraper. Incrementals ask for 8 and correctly stay free.

Comments are a separate paid call to streamers/youtube-comments-scraper. Bright Data cannot serve YouTube at all — gd_lk56epmy2i5g7lzu0k needs a specific video URL and cannot enumerate a channel.

15× faster, free, and the only route that returns like counts. The paid actor wins on exactly two things: more than 15 videos, and the channel stats block.

Not obtainable at any price: subscriber lists and a channel's subscriptions. Both are private by platform design — every candidate actor returns a count, not the people.

Nine jobs across two vendors, and the most expensive platform per unit — LinkedIn is the hardest network to scrape, which is why competition is thin and prices are higher.

Company posts come from harvestapi/linkedin-company-posts, which has a floor of 8: asking for 2 returned 8 and billed for 8.

Both profile jobs lead with Bright Data, and that position is earned on price rather than assumed — gd_l1vikfnt1wgvvqz95w for a company and gd_l1viktl72bvl7bjuj0 for a person, both at $0.0015 against Apify's $0.004. The harvestapi actors sit behind them as fallbacks.

Comments come from harvestapi/linkedin-post-comments and need post URLs, so the chain runs three deep: posts → comments → commenter profile. One post by URL goes to apimaestro/linkedin-post-detail, resharers to datadoping/linkedin-post-repost-scraper, and ads to data_xplorer/linkedin-ad-library-scraper.

Bright Data's LinkedIn Posts dataset gd_lyy3tktm25m4avu764 is never wired — it needs a specific post URL and cannot discover an account's posts.

5.9× the cost. Reactions bill at $0.002 each — the same as a post — and 47 arrived for a 10-post ask. Worse, the extras come back as separate flat rows, not nested arrays: the first item's keys are type, id, reactionType, actor, postId, query, a reaction record rather than a post. The existing parser would need rewriting. And it yielded 2 comments across 10 posts, so it is a poor comment source too. Leave both switches off — but rewrite the note, because "ignored" is wrong.

Not offered: LinkedIn followers and following. A company-followers actor exists but has about 315 users and has never been run, so its rate is unknown and it is not wired.

One call, one actor, no fallback. Threads is the project's only documented single point of failure — and its payload is the richest of any platform, about 80 keys.

futurizerush/meta-threads-scraper is asked {"usernames":["nasa"], "max_posts": 10} and returns posts and the entire profile attached to every post: followers_count, bio, is_verified, display_name, profile_pic_url, user_id, plus emails, phones, bio_links and external_links. All present on 10 of 10 posts.

max_posts has a hard minimum of 10, so every Threads pull costs $0.045 whether one new post exists or ten.

Everything else on Threads is a dead end — comments, resharers and followers are all platform or actor limits rather than wiring gaps. Bright Data serves nothing here.

One actor plus a local OCR step. 427 Google ads stored.

automation-lab/google-ads-scraper is asked for ads from the Google Ads Transparency Center. Where an advertiser id is on file it uses {advertiserIds: ["AR137…"], maxAds: 10} — an exact lookup; otherwise it falls back to {searchTerms: [name]}, a fuzzy name search. There are 17 ids on file in google_advertiser_ids.

What comes back is a picture, not words. So every creative image is then read by tesseract.js running locally — no vendor, no key, no bill — using the Worker API with { blocks: true } to get line-level positions rather than a flat text blob.

The result reaches ads with ad_copy_source set to 'ocr'. Bright Data has no ad-library endpoint for any network, so all four ad capabilities in the project are legitimately single-tier.