Spider vs. ScraperAPI: Up to 11x Cheaper with Browser Automation Built In
ScraperAPI has been around for years and does one thing: you send a URL, it rotates proxies and renders JavaScript, you get HTML back. Straightforward, but expensive once you start scraping protected sites at any real volume. And you get nothing beyond raw HTML.
ScraperAPI’s credit multiplier system
Like most proxy-based scraping APIs, ScraperAPI uses credit multipliers. Each API request eats a different number of credits depending on the features you turn on:
| Configuration | Credits per request |
|---|---|
| Basic request, no rendering | 1 |
JS rendering (render=true) | 11 |
| Premium proxy + rendering | 25 |
| Ultra premium + rendering (Cloudflare/DataDome bypass) | 75 |
| Amazon product pages | 5 |
| Google SERP | 25 |
| 30 |
Most production scraping targets sites with bot protection. If you need Cloudflare bypass with rendering, that is 75 credits per request. Here is what that does to each plan:
| Plan | Monthly cost | Credits | Requests at 75 cr/req | Effective cost per 1K pages |
|---|---|---|---|---|
| Hobby | $49 | 100,000 | 1,333 | $36.75 |
| Startup | $149 | 1,000,000 | 13,333 | $11.18 |
| Business | $299 | 3,000,000 | 40,000 | $7.48 |
Spider bills based on bandwidth ($1/GB) and compute time ($0.001/min) — no credit multipliers. There are no 75x surcharges for anti-bot bypass. A typical production workload averages around ~$0.65 per 1,000 pages. See spider.cloud/credits for the full breakdown.
On ScraperAPI’s best-value plan (Business), that is roughly an 11x cost difference. On the Startup plan, the gap widens to 17x.
At 100,000 pages per month scraping protected sites:
- ScraperAPI (Business): ~$748
- Spider: ~$65 (typical workload)
ScraperAPI credits also expire at the end of each billing cycle. Use 600,000 of your 1,000,000 Startup credits, the other 400,000 are gone. Spider is pure pay-as-you-go.
Output: HTML vs. everything else
ScraperAPI gives you HTML. You parse it with BeautifulSoup, Cheerio, or whatever you have lying around.
Spider returns the format you actually need: markdown for LLM pipelines, structured JSON, plain text, XML, CSV, or JSONL. If you are feeding pages into a RAG system or a fine-tuning pipeline, the markdown comes back clean and ready to embed.
# ScraperAPI — you get HTML, you figure out the rest
response = requests.get(
"https://api.scraperapi.com",
params={
"api_key": "YOUR_API_KEY",
"url": "https://example.com",
"render": "true",
},
)
html = response.text # now you need a parser
# Spider — you get clean markdown
response = requests.post(
"https://api.spider.cloud/crawl",
headers={"Authorization": "Bearer YOUR_API_KEY"},
json={
"url": "https://example.com",
"return_format": "markdown",
},
)
markdown = response.json()[0]["content"] # ready for GPT, Claude, etc.
Browser automation
This is where ScraperAPI has a hard ceiling. It is a URL-in, HTML-out pipe. There is no way to:
- Log into a site and scrape behind authentication
- Click through pagination or expand collapsed sections
- Fill forms or run multi-step workflows
- Execute custom JavaScript against the live DOM
- Build an agent that navigates based on what it finds
Spider Browser gives you a remote browser session over WebSocket. You connect with the TypeScript, Python, or Rust SDK and drive the browser directly:
import { SpiderBrowser } from "spider-browser";
const spider = new SpiderBrowser({
apiKey: process.env.SPIDER_API_KEY,
});
await spider.init();
// Log into an app
await spider.page.goto("https://app.example.com/login");
await spider.page.fill("#email", "user@example.com");
await spider.page.fill("#password", "password");
await spider.page.click("#submit");
await spider.page.waitForSelector(".dashboard");
// Pull structured data from the authenticated page
const data = await spider.page.extractFields({
userName: ".user-name",
accountBalance: ".balance",
recentOrders: ".order-list li",
});
await spider.close();
If the data you need sits behind a click, a scroll, or a login, ScraperAPI cannot get there. You would end up running your own Puppeteer setup on top of their proxy — which defeats the point of paying for a managed service.
Throughput and reliability
ScraperAPI response times vary widely in practice. Independent tests report ~80% success rates on search engine results pages with response times sometimes exceeding 40 seconds.
Spider’s API is built on a Rust async runtime. Here are numbers from production:
| Metric | Spider API | Spider Browser |
|---|---|---|
| Throughput | 50,000+ req/min | 100 concurrent sessions |
| Response time (static) | 45ms | 2.5s median end-to-end |
| Success rate | 99.9% | 100% across 999 URLs |
The Browser success rate comes from a public benchmark across 254 domains and 18 categories — including Amazon, Nike, Walmart, Zillow, Booking.com, and Bloomberg, protected by Akamai, PerimeterX, DataDome, and Cloudflare. Every URL returned usable content.
ScraperAPI’s structured data endpoints
ScraperAPI offers pre-built JSON endpoints for Amazon and Google. If those two domains are your only targets and you do not need anything else, those endpoints save you some parsing work.
Spider takes a broader approach. extractFields() pulls structured data from any site via CSS selectors. extract() lets you describe what you want in plain English and returns JSON. Neither is limited to two domains.
When ScraperAPI still makes sense
If your volume fits in the free tier (5,000 requests), you only need HTML from unprotected pages, and the Amazon/Google structured endpoints cover your use case, ScraperAPI works fine.
Beyond that — at scale, on protected sites, or anywhere you need browser interaction — Spider delivers more for significantly less.