String vs Apify (2026): when a prebuilt Actor pays

Read the Apify number for what it is. It says that when you use Apify the way you would use a scraping API, sending it arbitrary URLs, about one request in five does not come back, and on the hardest sites it is closer to two in five. It does not say a maintained Store Actor fails at that rate on its own site, because no Store Actor was measured. Anyone who quotes this number against Apify's marketplace, including us, is misusing the data.

The prebuilt ceiling: 15 of 100

Here is the number this page owns, and it is computed against our own Actors rather than against Apify's. The counts below come from String's Actor listing on Apify Store, checked November 9, 2026, and the public run file of the October 30, 2026 run.

String publishes 30 Actors on Apify Store, covering job boards, retail, real estate, reviews, public profiles and finance. The benchmark suite has 100 target sites. Those 30 Actors are built for the sites of 15 of the 100 targets: Amazon, Walmart, Home Depot, Etsy, AutoTrader, Zillow, Realtor.com, Indeed, Glassdoor, ZipRecruiter, G2, Capterra, LinkedIn, TikTok and Yahoo Finance. The other 85 have no String Actor at all.

On the 15 sites where a String Actor exists, String's general fetch path returned 5 of 5 on every one of them. On the 85 sites with no Actor, the same general path returned 5 of 5 on 80 of them and averaged 98.4%, with no site returning nothing.

That is the ceiling on any marketplace, ours included. A prebuilt scraper is a per-site asset. Coverage grows one site at a time, by someone deciding a site is worth maintaining. It cannot grow to the shape of a list you make up on a Tuesday. We publish 30 Actors and they reach 15% of a 100 site suite we chose ourselves, which is about as favorable a test as a marketplace could ask for.

The counterpart is the part marketplace critics skip. On those 15 covered sites, the Actor gives you parsed rows. The general fetch gives you the page, and the parsing is your problem. Both paths cover those sites, and they are not the same deliverable.

The right reading is not that prebuilt scrapers are a bad idea. It is that prebuilt coverage and general coverage solve different problems, and a target list of any size will contain both kinds of site.

Where each one breaks

Apify breaks at the edge of the catalogue. When an Actor exists and is maintained, the work is done. When it does not, you either write one or fall back to a general fetch, and the general fetch is the path the benchmark measured at 79.4% on October 30, 2026. Writing one means learning the platform: Actor structure, input schemas, compute unit sizing, storage, queues and proxy groups. Apify runs a free Academy precisely because this is a real project, and it is a different project from the one you thought you were buying. Developers who publish can monetize what they build, which is what keeps the maintained Actors maintained.

Maintenance is the second edge. A site-specific parser is coupled to a site's markup. When the site changes, the Actor breaks, and whether it gets fixed quickly depends on a third party developer's incentives. Apify's Store documentation says an Actor that fails its automated tests is labelled "under maintenance," that a run of it "can fail or return incomplete results," and that an Actor which keeps failing is deprecated. Every Actor has an Issues tab for reporting problems. Actors with real usage tend to get fixed. Actors in the long tail are a bet on one person's attention.

Apify has also finished retiring its rental pricing model. Its migration guide set September 30, 2026 as the deadline and said rental Actors not migrated by then move to pay-per-usage. The Store documentation now lists two models: pay per event, where the developer sets a price per result or other event, and pay per usage, where you pay only the platform resources a run consumes. If you depended on a rental Actor, check what it bills now.

String breaks where structure is the requirement. If you want LinkedIn job rows with clean fields, String hands you a page and you write the extraction. That is not a small amount of work when the site paginates awkwardly or renders through JavaScript, and it is work Apify has already done for the sites it covers. String also has no scheduler, no dataset store and no run history. If you need those, you are building or buying them separately. String's Composer product exists for structured feeds, but the Web Access API is deliberately just fetching.

String did not clear every site on every attempt either. In the October 30, 2026 run file, it returned at least one attempt on all 100 sites, but missed some attempts on five: kroger.com returned 2 of 5, and skyscanner.net, yellowpages.com, marketwatch.com and barrons.com returned 4 of 5. No fetch API in this category is perfect on hard targets, and a page that told you otherwise would be lying.

Cost, honestly

The comparison pages anchor every vendor at the plan nearest $100 a month billed monthly. Apify has no plan near $100. Its ladder steps from Starter at $19 to Scale at $199, so both are named here rather than picking whichever flatters the comparison. Annual billing takes 10% off. The figures below are the monthly ones.

Sources: Apify pricing, Apify Web Fetch pricing and String pricing, checked November 9, 2026.

Three things in that table matter more than the headline rates. Apify prices below are as of November 9, 2026 and String prices as of October 2026, from the sources above.

The units are not comparable, and no honest table can make them so. Apify meters compute: a compute unit is 1 GB of RAM for one hour. What a job costs depends on how much memory an Actor asks for, how long it runs, which proxy it uses and how many times it retries. Apify's pricing FAQ says cost "depends on the number of retries when a request fails," and its Store documentation says pay-per-usage cost is "quite difficult to estimate" beforehand and recommends a test run to find out. String meters requests, and a blocked request is not billed. Those are different risk shapes. Metered compute bills your experiments; per-request billing where blocks cost nothing does not.

Prepaid balances expire on Apify. Its pricing FAQ states that unused usage credits "are not rolled over to the next billing cycle, and they expire at the end of the billing cycle." String's plan fee goes to your usage balance in full, and unused credit rolls over. For steady volume this is irrelevant. For spiky work it is the difference between paying for what you used and paying for the month you planned.

String's cheapest rate is not the rate you should plan on. The $0.16 per 1,000 figure is a plain HTTP fetch through a standard proxy on the $99 Growth plan. Pages needing a premium proxy bill $0.90 per 1,000, a browser render on a standard proxy bills $0.80, and a browser on a premium proxy bills $3.25. On Starter at $19 a month those four paths are $0.25, $2.40, $1.20 and $4.80. The hard sites in this comparison are exactly the ones that land on the higher paths, so quoting $0.16 against Apify's $1.50 Web Fetch rate would be picking String's best case against Apify's list price. On a protected page that needs a browser and a premium proxy, String's $3.25 per 1,000 is above Apify's Web Fetch at $1.50 on Starter, $1.25 on Scale and $1.00 on Business, which includes Apify's platform costs. Apify's proxy line items are documented per type: residential at $8 per GB on Starter and Google SERP at $2.50 per 1,000 SERPs, with external data transfer at $0.20 per GB on Starter. String's fetch requests bill per request; its Browser WebSocket sessions bill bandwidth at $5 to $10 per GB.

There is no clean winner in that table, and the effective cost depends on your mix of easy and hard pages and on how many requests come back. A rate per 1,000 requests is only half of a cost per page: in the October 30, 2026 run, 79.4% of Apify Web Fetch requests returned the page and 98.6% of String's did (public run file, as of October 2026). Both companies publish enough to work it out for your own list, which is the useful part.

Which one to pick, by job

Pick Apify when the site has a maintained Actor and you want rows, not pages. Google Maps, Instagram, TikTok and the big job boards have Actors with real usage behind them. Buying that is cheaper than writing and maintaining a parser, and it is not close.

Pick Apify when you need the platform, not just the fetch. Scheduling, run history, dataset storage, retries and webhooks are all there and integrated. If you would otherwise build that, the platform fee is buying something real.

Pick String when the target list is long, changing, or yours alone. No marketplace has an Actor for the 400 supplier sites in your category. The 15 of 100 number above is the point: prebuilt coverage runs out, and it runs out early. On the sites it has no Actor for, as of the October 30, 2026 benchmark run, Apify's own general fetch path returned 79.4% against String's 98.6% (public run file).

Pick String when an agent is choosing the URLs. An agent that decides at runtime which page to read cannot pick an Actor from a catalogue first. It needs a general fetch, which is why String ships an MCP server. Apify also ships MCP, and it exposes Actors, which is a different capability rather than a worse one.

Pick String when unpredictable bills are the problem. Per-request billing where blocked requests cost nothing is legible in a way metered compute is not.

Use both when your list has both kinds of site. This is the common answer and it is not a hedge.

Running both

If you are on Apify and adding String, the change is small. You keep every Actor that works and add a fetch path for the sites with no Actor. Nothing migrates.

Concretely: keep your Apify Actors and their schedules; point the uncovered part of your target list at String's /fetch endpoint; keep Apify's storage and orchestration if you already use them, because String does not replace those. String's first 20,000 standard fetches are free with no card, so the uncovered part of your list is testable before anything changes.

One note before any move. Apify sells a per-request fetch of its own: the Web Fetch Actor at $1.50 per 1,000 fetches on Free and Starter, falling to $1.00 on Business (Apify Web Fetch pricing, as of November 9, 2026), and the raw Unblocker proxy at the same rates. If your reason for leaving is "I want a per-request unblocker," you can buy one from Apify without leaving. That is the path the benchmark measured, so test it against your own targets beside String rather than taking either company's word for it. Note also that using Apify's proxies from outside the platform requires a paid plan.

FAQ

Is String better than Apify?

For fetching arbitrary pages from protected sites, yes on the measured numbers: in the October 30, 2026 benchmark String returned verified content on 98.6% of 500 requests across 100 sites, and Apify's Web Fetch Actor returned 79.4%. On the 50 hardest sites the gap was 98.0% against 62.8%. That measures Apify's general fetch path, not its Store Actors. If a maintained Actor exists for your site and you want parsed rows, Apify is very likely the better buy. If your target list is long or changing, String is.

Is Apify worth it?

For the sites it covers well, yes. An Actor with real usage behind it has already solved parsing, pagination and maintenance for that site, and buying that is cheaper than building it. The cost question is different from the value question: Apify meters compute units at $0.20 each on Starter (Apify pricing, as of November 9, 2026), and its own documentation says pay-per-usage cost is "quite difficult to estimate" beforehand. Run a test job at small scale before committing to a plan.

What are the best Apify alternatives?

That depends on what you were using Apify for. If you were using it for prebuilt site-specific scrapers, the alternatives are other marketplaces, not fetch APIs. If you were using it as a way to get pages back, the October 30, 2026 run had String at 98.6%, Context.dev at 93.0%, Scrapfly at 86.8% and Firecrawl at 81.2%, against Apify's Web Fetch at 79.4%. Our fuller write-up is at Apify alternatives.

Is Apify cheaper than building my own scraper?

For a site with a maintained Actor, usually yes, because you are buying someone else's ongoing maintenance rather than a one-off build. The calculation flips when the site has no Actor, because you are then writing one and learning Apify's platform at the same time. It flips again at high volume on easy pages, where metered compute plus proxy and transfer line items can exceed a flat per-request rate. Apify recommends a test run to find your real number, which is the right advice.

How many sites does a scraper marketplace actually cover?

Fewer than the catalogue size suggests, because coverage is per site and your list is not. A concrete measure from our own data: String publishes 30 Actors on Apify Store, and they are built for 15 of the 100 sites in the October 30, 2026 benchmark suite. The other 85 have no String Actor. For those, a general fetch path returned 5 of 5 on 80 of 85 and averaged 98.4% (public run file, October 30, 2026).

Does String bill for blocked or failed requests?

String does not bill blocked requests or errors on its own side, and unused credit rolls over. A site's own error response, such as a 404, is billed, because String got the site's response back to you. Apify meters platform usage, and its pricing FAQ states that run cost "depends on the number of retries when a request fails," and that unused prepaid usage is "not rolled over to the next billing cycle."

Can Apify handle hard anti-bot sites?

Apify sells an Unblocker that it says "automatically bypasses anti-bot and anti-captcha systems using built-in smart routing," and its Web Fetch Actor routes every request through it. In the October 30, 2026 benchmark that path returned 79.4% of requests overall, 62.8% on the 50 hardest sites, 69.0% on Akamai-protected sites and 100% on the three Kasada sites. It returned nothing on 12 of the 100 sites, including booking.com, indeed.com and skyscanner.net.

How do I verify any of this myself?

Run the benchmark. The harness is public and takes a target list, so you can point it at your own sites rather than ours, and the Apify adapter shows exactly how Apify was called. For the Apify side, start a free plan and run the Actor you care about at small scale; the run detail page shows what it cost. For the String side, the first 20,000 standard fetches are free.

Sources

All checked November 9, 2026.

• Apify pricing
• Apify Web Fetch pricing
• Apify Web Fetch Actor
• Apify Store
• Actors in Apify Store, billing models
• Apify proxy documentation
• Apify Unblocker documentation
• Apify usage and resources
• Apify storage
• Apify request queue
• Apify webhooks
• Apify API reference
• Apify JavaScript SDK
• Apify Python SDK
• Apify CLI
• Apify MCP integration
• Apify Trust Center
• Apify proxy product page
• Apify residential proxy docs
• Apify Google SERP proxy docs
• Apify schedules
• Apify standby mode
• Apify Academy
• Monetizing Actors on Apify
• Apify rental to pay-per-event migration guide
• Crawlee
• Web Data Frontier Benchmark harness
• Apify adapter in the benchmark harness
• October 30, 2026 run, full result JSON
• String pricing
• String Web Access API
• Web Data Frontier Benchmark
• October 30, 2026 benchmark write-up
• String Actors on Apify Store
• Apify alternatives