I ran 1,000 public Instagram post and Reel URLs through Apify’s Instagram Scraper and the ScrapeCreators Instagram Post API.
The short answer: ScrapeCreators was cheaper and faster. Apify had a better first-attempt success rate.
I run ScrapeCreators, so I had every reason to want a clean win. That is not what happened. The useful result is more specific.
The result
| Metric | ScrapeCreators | Apify Instagram Scraper |
|---|---|---|
| Unique URLs tested | 1,000 | 1,000 |
| First-attempt matched results | 996 | 1,000 |
| First-attempt success rate | 99.6% | 100% |
| Cost for the tested workload | $1.8725 on the $47 pack | $2.2977 on Bronze |
| High-volume ScrapeCreators cost | $0.9900 on the $497 pack | $2.2977 on Bronze |
| 997-URL batch, concurrency 16 | 201.8 seconds | 147.0 seconds |
| 997-URL batch, concurrency 100 | 50.8 seconds | 147.0 seconds |
| Concurrency 100 plus one retry wave | 58.7 seconds | 147.0 seconds, no retry needed |
| Paired single-URL median | 5.52 seconds | 13.71 seconds |
| Paired single-URL p95 | 8.90 seconds | 35.00 seconds |
ScrapeCreators cost 18.3% less on its entry paid pack and 56.8% less on its larger pack. At concurrency 100, it processed the 997 URLs 2.9 times faster than the Apify Actor. Apify returned every item on the first attempt.
The higher-throughput ScrapeCreators run returned 988 of 997 items on the first attempt. The nine failures were not charged, and all nine worked in one retry wave. That brought total wall time to 58.7 seconds, still 2.5 times faster than Apify’s 147.0 seconds.

What I tested
I wanted a test set that did not quietly favor ScrapeCreators.
I took the 50 most-followed Instagram accounts from Wikipedia’s July 2026 table. I then asked Apify’s own Instagram Scraper to collect up to 20 posts from each profile.
That produced 997 unique post and Reel URLs. I added three URLs from an earlier paired pilot to reach exactly 1,000 unique URLs.
This gives Apify an advantage in the sample selection. If Apify failed to discover a post during the first collection run, that post could not appear in the 997-URL batch. I did this deliberately so nobody could say I hand-picked URLs that were bad for Apify.
The comparison then used the same URLs on both services:
- Apify received the 997 URLs in one Actor run with
resultsTypeset topostsandresultsLimitset to1per URL. - ScrapeCreators received one
/v1/instagram/postrequest per URL. I ran the same 997-URL corpus at concurrency 16 and concurrency 100. ScrapeCreators recommends staying below 500 concurrent requests. - A request counted only when the output contained the requested shortcode. An HTTP 200 or
SUCCEEDEDActor status was not enough. - Apify ran on the paid Starter account’s Bronze pricing tier.
- ScrapeCreators requests did not use
cache_max_age, so each successful request was a normal one-credit live call.
The three top-up URLs came from the separate paired test and had already succeeded on both services.
You can download the normalized 1,000-URL results as CSV. The file includes the public URL, both ScrapeCreators runs, retry outcome, credits charged, and the returned play count where available.
Cost comparison
Apify charged exactly $0.0023 for each successful result on Bronze. One thousand successful results therefore cost $2.30 at the published unit rate. The measured 1,000-URL workload cost $2.2977 because 997 results came from the batch and three came from the paired pilot.
ScrapeCreators charged 996 credits. The four failed requests cost zero credits.
| Pricing basis | Cost per 1,000 successful one-item results | Difference from Apify Bronze |
|---|---|---|
| Apify Bronze | $2.30 | Baseline |
| ScrapeCreators $47 pack | $1.88 | 18.3% less |
| ScrapeCreators $497 pack | $0.994 | 56.8% less |
There is one important billing difference. Apify’s $29 Starter subscription includes $29 of monthly usage. If you already pay for Starter and have unused usage left, this Actor run may not create a separate card charge. The $2.30 still consumes that monthly allowance.
ScrapeCreators has no subscription. The $47 and $497 packs are one-time purchases, and the credits do not expire.
I also spent $2.2908 to make Apify generate the original 997-URL corpus. That was research overhead, not part of the same-workload cost table. A customer who already has a URL list would not pay it.
Speed comparison
The speed result changes depending on how you use the products.
Large batch
Apify processed the 997 direct URLs in one Actor run. It finished in 146.956 seconds.
My first ScrapeCreators run used concurrency 16 and took 201.807 seconds. That made Apify look faster, but it mostly measured my conservative client setting.
ScrapeCreators does not enforce a rate limit and recommends staying below 500 concurrent requests. I reran the identical 997 URLs at concurrency 100. That run finished in 50.770 seconds, or 2.9 times faster than Apify.
Nine ScrapeCreators requests returned transient failures in the higher-concurrency run. All nine succeeded in one parallel retry wave. First pass plus retry took 58.739 seconds, or 2.5 times faster than Apify.
This is still not a per-request latency comparison. Apify controls its internal concurrency inside the Actor, while the ScrapeCreators caller controls its own HTTP concurrency. The honest comparison is each provider’s normal high-throughput mode, not an arbitrarily low client limit for one side.
One URL at a time
I also ran a smaller paired test on 12 current Reels. Each pair started together, with three pairs running at once.
| Single-URL result | ScrapeCreators | Apify |
|---|---|---|
| Successful outputs | 12 of 12 | 11 of 12 |
| Median time | 5.52 seconds | 13.71 seconds |
| p95 time | 8.90 seconds | 35.00 seconds |
| Longest outcome | 9.52 seconds | One 45-second timeout |
For an application waiting on one synchronous response, ScrapeCreators was faster in this pilot. The Apify runs had a 45-second Actor timeout. ScrapeCreators used a 60-second client timeout, but no ScrapeCreators call took more than 9.52 seconds.
Reliability and retries
Apify returned all 997 batch items and all three selected top-up items. That is 1,000 of 1,000 matched results on the first attempt.
ScrapeCreators returned 996 of 1,000 on the first attempt. Four carousel posts returned 404 Post not found. Those four requests were not charged.
I checked the public pages and retried each URL twice. Every page was public, and all eight retry calls succeeded. The first retry was enough in all four cases.
So the dated result is:
- Apify: 100% on the first attempt
- ScrapeCreators: 99.6% on the first attempt
- ScrapeCreators with one retry: 100%
That retry still matters. A production client should retry transient failures, but a first-attempt failure adds latency and code. Apify was better on this measure.
The smaller single-URL pilot showed the opposite kind of failure: one Apify Actor hit its 45-second timeout, while all 12 ScrapeCreators calls succeeded. A dozen URLs is too small to overrule the 1,000-URL batch, but it is worth reporting.
The concurrency-100 ScrapeCreators run traded a little first-attempt reliability for throughput. It returned 988 of 997 items on the first pass, or 99.1%. All nine uncharged failures succeeded in one retry wave. Apify remained better on first-attempt reliability, while ScrapeCreators remained faster even after retries.
Did the play counts match?
Both services returned a numeric play count for 346 of the same video or Reel URLs.
Only one pair was an exact match. That sounds bad until you look at the call order: ScrapeCreators finished first, then Apify ran the large batch. Apify returned a higher count in 345 of 346 pairs. Public Reel counts were still increasing between the calls.
For 318 of the 346 pairs, the difference was within 0.1%. The median difference was about 0.0005%.
One pair differed by 3.9%. I cannot prove from this run whether that was rapid view growth, a refresh delay, or a source difference. I would not use this experiment to claim either provider had more accurate engagement data.
A proper accuracy test would need a frozen reference value or near-simultaneous calls with a trusted third source. This benchmark measured whether each service returned the requested item, not which changing counter was “correct.”
API experience
The two products make sense for different architectures.
With ScrapeCreators, the request is a normal synchronous GET:
curl --get "https://api.scrapecreators.com/v1/instagram/post" \
-H "x-api-key: $SCRAPE_CREATORS_API_KEY" \
--data-urlencode "url=https://www.instagram.com/p/SHORTCODE/" \
--data-urlencode "trim=true"
One successful live call costs one credit. The response includes credits_charged, so the application can see the billing result directly.
Apify starts an Actor run. For this batch, the important input looked like this:
{
"resultsType": "posts",
"directUrls": [
"https://www.instagram.com/p/SHORTCODE/"
],
"resultsLimit": 1
}
The caller starts the run, waits or receives a webhook, then reads the dataset. That is more machinery for one URL, but it is useful machinery for scheduled exports and large collection jobs.
Apify also handles arbitrary websites and custom Actors. ScrapeCreators does not. ScrapeCreators focuses on supported social platforms through one set of REST endpoints.
Which one should you use?
Choose ScrapeCreators’ Instagram API when:
- your app wants one synchronous JSON response per URL
- lower cost per one-item result matters
- usage is irregular and you do not want a monthly subscription
- the same product also needs TikTok, YouTube, Facebook, X, Reddit, or other supported social APIs
- you want credits that do not expire
Choose Apify’s Instagram Scraper when:
- you want to submit work as an Actor run and collect a dataset
- schedules, exports, webhooks, or the Apify ecosystem are part of the workflow
- you already have a paid Apify account with unused monthly usage
- you need custom crawling or websites outside ScrapeCreators’ supported platforms
- first-attempt performance on this exact benchmark matters more than the unit-price difference
My honest read: ScrapeCreators was the better fit on price and speed in this post-detail test. Apify still had the cleaner first pass and is the better fit when the rest of the job already belongs inside an Actor workflow.
Data and sources
The test ran on August 19, 2026 UTC. Prices, Actor behavior, Instagram responses, and public counts can change.
Primary sources:
- Apify Instagram Scraper
- Apify Instagram Scraper API
- Apify pricing
- ScrapeCreators Instagram Post API documentation
- ScrapeCreators concurrency guidance
- ScrapeCreators pricing
- Wikipedia list of most-followed Instagram accounts
- Normalized 1,000-URL benchmark CSV
This test used public Instagram data. It did not log into private accounts, automate outreach, or test posting actions.
For profile-level workloads, read the separate tests for profile details, user posts, and user Reels.
For the broader product comparison, read Apify vs Scrape Creators. For other vendors, see the Instagram scraping API comparison.

