What ScraperAPI is built for: managed unblocking
ScraperAPI is a web scraping API rather than a proxy vendor, and the distinction matters more than any feature comparison. You pass a target URL to a single endpoint and receive the page back; proxy selection and rotation, retries, header handling, headless-browser rendering and anti-bot negotiation all happen on their infrastructure. Around that sit structured-data endpoints that return parsed JSON for common commerce and search targets, an asynchronous API for large batches, DataPipeline for scheduled jobs without code, SDKs for the usual languages, and integrations aimed at LLM tooling. The company also acquired Traject Data, which broadened its coverage of SERP and marketplace data APIs.
It is genuinely strong at the difficult part. Keeping a scraper alive against Cloudflare, DataDome or PerimeterX is continuous engineering work with no end state, and a service that absorbs that work is worth paying for. Their credit model is an honest map of that difficulty: a plain HTML fetch is the cheapest unit, while JavaScript rendering, the premium and ultra-premium proxy tiers, and known-hard domains such as major search engines, large marketplaces and professional networks each cost a multiple of it. Geotargeting, device selection and session parameters add nothing, and requests that fail are not charged against your balance.
ScraperAPI does expose a proxy port, at proxy-server.scraperapi.com on port 8001, with a fixed username, your API key as the password, and request parameters encoded into the username using dot notation. That is a convenience wrapper over the same product rather than a separate one: it is still per-request, still routed through the unblocking layer, and it normally requires you to disable SSL verification or trust their proxy CA. If you have been using that port and assumed you were buying raw proxy access, this page is the difference you are looking for.
- Single endpoint that returns rendered HTML for a target URL
- Managed anti-bot handling for Cloudflare, DataDome and PerimeterX
- Headless rendering and screenshots as request parameters
- Structured JSON endpoints for common commerce and search targets
- Scheduled, no-code collection through DataPipeline
- Billing by API credit, weighted by how hard the target is
ScraperAPI credits per request vs Nefo per GB
The two products bill in units that do not convert into each other, and that single fact decides most switching decisions. ScraperAPI's cost is a function of difficulty: which domain you are hitting, whether you need a browser, which proxy tier you selected. The weight of the page is irrelevant. Nefo's cost is a function of bytes moved: prepaid bandwidth from 5GB, priced per gigabyte, with the rate falling from $0.90/GB to $0.53/GB as volume rises. Target difficulty is irrelevant to the meter — a request to a heavily defended site costs the same per byte as one to a static page, but whether it succeeds is entirely your problem.
The practical consequence is that response size, not request count, determines whether Nefo is cheap for you. Workloads made of small responses — JSON APIs, mobile endpoints, price and stock fields, availability checks, localised SERP snippets — fit an enormous number of requests into a gigabyte. Workloads that pull full pages with images, fonts and bundled JavaScript burn bandwidth quickly, and a per-request model may well be the cheaper shape for them. Measuring the average Content-Length of your current responses answers this in an afternoon and is worth doing before you decide anything.
The commitment shape differs too. ScraperAPI is subscription-oriented: a monthly allowance of credits, with concurrency allocated by plan tier. Nefo is prepaid, and its flexible plans are non-expiring — bandwidth stays in the account until it is used, generating credentials costs nothing, and you top up when you need to. For steady, high-volume, always-on collection a subscription is a reasonable fit. For bursty, seasonal or research work that runs hard for two weeks and then stops, a monthly allowance you did not consume is money that simply expired.
City targeting and session control
ScraperAPI expresses location as a country code on the request, and it does not charge extra credits for it. Sessions work through a session number: requests sharing an integer keep the same proxy, and a session lapses after a short idle window rather than being held for hours. You do not select the individual IP, and you generally do not need to — the point of the product is that the IP is an implementation detail managed on your behalf.
Nefo inverts that. You write a username for a targeting profile and then use it like any other proxy: 227 countries and territories, the United States down to state and city, region and city level in selected countries including the United Kingdom, Canada, Germany and France, and ASN or ISP targeting so traffic exits through a specific network operator within a country. Sessions are yours to set — rotating gives a new IP on every request, sticky holds the same IP anywhere from one minute up to twenty-four hours, set in the proxy username. That upper bound is the interesting one: multi-step flows, logged-in paths and checkout sequences that need an IP to persist across a long sequence are awkward under a short session lifetime and straightforward under a long one.
There is also a product shape that has no equivalent inside a scraping API. Nefo rents 4G and 5G mobile ports on real carrier modems by duration rather than by gigabyte, with one live rotating carrier IP per port, US state and carrier targeting, and IP changes on demand. That is a different purchase from bandwidth and it exists because some targets treat mobile carrier IPs differently from residential ones.
- Country selection across 227 countries and territories
- US state- and city-level exit targeting
- Region and city targeting in selected European and North American countries
- ASN or ISP targeting paired with a country
- Rotating IP per request, or sticky IP from 1 minute to 24 hours
- HTTP, HTTPS and SOCKS5, all with username and password authentication
What you take back when you leave ScraperAPI
Being direct about this is the only way the rest of the page is worth reading. Nefo is a network, not an unblocker. It does not solve CAPTCHAs, does not run a headless browser for you, does not retry failed requests, does not manage your TLS or header fingerprint, and does not parse anything. Every problem ScraperAPI was quietly absorbing on your behalf comes back to your side of the wire on the day you switch.
For a large share of teams that is not a real cost, because the machinery already exists. If your stack is Playwright or Scrapy with your own retry policy, your own header rotation and your own parsers, then the unblocking layer you were paying for was partly redundant, and what you actually needed from the vendor was clean exit IPs in the right places. If your stack is a thin wrapper around someone else's endpoint, the gap is substantial and you should size it honestly before committing.
The corollary is a genuine limit on where Nefo is the right answer. Against targets with serious active defences — major search engines, large professional networks, sites behind enterprise-grade bot management — a raw residential network without an unblocking layer will underperform a service built specifically to defeat those defences, and no amount of IP quality closes that gap on its own.
How to switch from ScraperAPI to Nefo
If you were already using ScraperAPI's proxy port, the mechanical part is small. You swap the endpoint for a Nefo credential and authenticate with a normal username and password over HTTP, HTTPS or SOCKS5. Two things change in how you express intent: targeting moves out of the request and into the credential you generate in the dashboard, so a country, city or ASN profile becomes a reusable credential rather than dot-notated parameters on every call; and SSL verification can stay switched on, since there is no interception certificate to trust. If you were using the API endpoint rather than the proxy port, the work is larger, because you are reimplementing the fetch logic that endpoint was performing.
Size the move with measurement rather than estimation. Multiply your average response size by your monthly request count to get a bandwidth figure, then buy the smallest plan that covers a representative sample and run the two side by side on the same targets. The entry plan is 5GB, credentials cost nothing to generate, and because flexible plans do not expire, an over-cautious pilot purchase is not wasted — it simply sits in the account until the traffic arrives.
There is no reason to treat this as a single cutover. The pattern that works is splitting by target difficulty: move the JSON endpoints, regional price and availability checks, localisation testing and lightly defended pages to raw proxies where per-byte billing is favourable, and leave the genuinely hostile targets on a managed unblocker for as long as they are worth the credits. Two vendors covering two different classes of work is a legitimate architecture, not an unfinished migration.
- Measure average response size across your live targets before sizing bandwidth
- Rebuild retry, backoff and header handling if the API was providing them
- Regenerate targeting as credentials rather than per-request parameters
- Re-enable SSL verification once the interception proxy is gone
- Pilot on one workload with a small non-expiring plan before moving volume
- Keep a managed unblocker for the small number of targets that need one
When to stay with ScraperAPI and when to switch
Stay with ScraperAPI if the value you are buying is a finished result rather than a network. That covers teams scraping search engines, large marketplaces or sites behind serious bot management; teams that want parsed JSON out of a structured endpoint instead of writing and maintaining selectors; teams running scheduled collection without engineering time to allocate; and anyone whose volume is steady enough that a monthly allowance is consumed rather than wasted. It also covers the situation nobody likes to say out loud: if the person maintaining the scraper leaves and nobody replaces them, a managed API keeps working and a raw proxy pipeline decays.
Nefo makes sense when the abstraction has become the thing you are fighting. That is usually one of a few specific situations: you need SOCKS5 or a protocol shape a scraping API does not offer; you need targeting below country level, whether that is a US city or a named ISP; you need an IP held steady for hours across a multi-step flow; your responses are small enough that per-byte billing is dramatically cheaper than per-request credits; your volume is irregular and a subscription idles for weeks at a time; or you need mobile carrier IPs on a time-rented port, which is a different product entirely.
The honest summary is that these are not competing implementations of the same thing. ScraperAPI sells the outcome and prices the difficulty. Nefo sells the network and prices the traffic. Which is cheaper for you is arithmetic on your own response sizes; which is correct for you depends on whether your team wants to own the fetch layer or be free of it.
- You already own your scraping stack and only need clean exit IPs
- You need SOCKS5, or protocols beyond an HTTP scraping endpoint
- You need city, state or ASN targeting rather than country codes
- You need sticky sessions measured in hours, not minutes
- Your responses are small, so per-gigabyte billing wins on arithmetic
- Your volume is irregular and non-expiring prepaid bandwidth suits it better
- You need 4G or 5G mobile ports on real carrier modems alongside residential IPs
Frequently asked questions
Largely, if you used the proxy port rather than the API endpoint. The transport is the same: a proxy host with username and password. Targeting moves into username tokens such as -country-us, -city-losangeles and -session-<id>. Anything the unblocking layer did, like retries and rendering, now has to run in your client.
There is no conversion table, because credits price the difficulty of a fetch while gigabytes price bytes returned. Log Content-Length across a sample of your live targets, take the mean, and multiply by monthly request count. Small JSON responses fit many requests per gigabyte; full pages with assets do not.
No. Nefo provides the proxy network and nothing above it: no CAPTCHA solving, headless browser, automatic retries or parsing. You would supply those yourself with something like Playwright, Scrapy or a fingerprint-aware HTTP client. Weigh that before the per-unit price.
Yes. Residential proxies can be targeted by country, state, city or ISP/ASN, from 227 countries and territories, 22,417 cities and 14,252 ISPs/ASNs. ScraperAPI expresses location as a country code on the request. You can run several targeting profiles in parallel from one account.
No. Nefo is prepaid: the smallest package is 5 GB for $4.50, credentials are free, and only traffic consumes bandwidth. Bandwidth never expires, so seasonal price monitoring or short research projects do not leave an unused monthly allowance behind. See pricing.
Yes, and it is the normal outcome. Send lightly defended pages, JSON endpoints and regional price checks through raw proxies where per-byte billing is favorable, and keep a managed unblocker for the few targets that need one. Neither billing model penalizes using it for part of a workload.