The Credit-Multiplier Trap: Why a 1M-Credit Scraping Plan Is 100,000 Requests
Scraper APIs bill in credits and charge 10x for residential IPs — the exact IPs Instagram needs. Here is the arithmetic, with named vendors.
8 min read · 20 Aug 2026
You are comparing scraper APIs. One plan says 1,000,000 credits, $134/month. You have 400,000 Instagram profiles to fetch this month. The arithmetic looks comfortable.
It is not 1,000,000 requests. It is 100,000, and you are 300,000 short.
The gap is a multiplier, it is published on the vendor's own pricing page, and almost nobody reads it before signing up — because it is a table two scrolls below the number in the plan name.
This is a short post about one specific piece of arithmetic. Everything in it is checkable on public vendor pages in about ten minutes, and the last section tells you how. It is one input into the only number that actually matters when you are budgeting a scraping project — cost per successful request — but it is the input most often gotten wrong by an order of magnitude.
What a credit actually is
A "credit" is not a request. It is a billing unit, and the number of credits a request consumes depends on how the request was fulfilled. Every scraper API that bills this way applies a multiplier, and the multipliers are not small.
Here is Shifter's, published on their pricing page and verified on 2026-08-20:
| Request type | Credits consumed |
|---|---|
| Datacenter | 1 |
| Datacenter + JavaScript rendering | 5 |
| Residential | 10 |
| Residential + JavaScript rendering | 25 |
Now read the plan names again. "1M credits" is a true statement about credits and a wildly misleading one about work performed. Divide by the multiplier that applies to your workload and you get the real number.
The reason this matters — rather than being a mildly annoying unit conversion — is that the multiplier tracks difficulty, and difficulty is not optional. Instagram, TikTok, and most logged-out social endpoints require residential IPs. Datacenter IPs get rate-limited on the first or second request. So the 10x row is not an upgrade you might choose. For the workload most people are buying a scraper API to do, it is the only row that exists.
You are shopping in the 1x column and living in the 10x one.
Worth checking before you accept that, though: a meaningful share of workloads land entirely in the 1x column, and there are whole platforms where a residential IP buys you nothing. If yours is one of them, the rest of this post is a bullet you have already dodged.
The real cost per 1,000 residential requests
Multipliers applied, across Shifter's published tiers (2026-08-20):
| Plan | $/mo | Credits | Multiplier | Real residential requests | Real $/1k |
|---|---|---|---|---|---|
| Enterprise | $719 | 10M | 10 | 1,000,000 | $0.72 |
| Business | $269 | 3M | 10 | 300,000 | $0.90 |
| Growth | $134 | 1M | 10 | 100,000 | $1.34 |
| Starter | $44 | 100K | 10 | — | no residential on this tier |
Three things fall out of that table.
The headline price is inverted relative to unit cost. The cheapest plan has the worst per-request economics by a factor of nearly two. That is normal for volume pricing, but the credit framing hides how steep the curve is: $134 and $719 look like a 5x difference in spend, and they are a 10x difference in delivered requests.
The Starter tier cannot do the job at all. $44/month buys 100,000 credits and no residential access on that tier at any price. If you signed up for Starter to test an Instagram integration, the integration cannot work — not slowly, not expensively, not at all. That is the single most expensive thing on this page to discover on day three of an evaluation.
"Unlimited requests" and "1M credits" are answers to different questions. Some vendors sell threads or concurrency with unlimited requests; some sell credit buckets. They are not comparable until you convert both to dollars per thousand successful requests for the specific difficulty class you need.
The no-multiplier alternative, and what it actually means
Some vendors price without multipliers. Geonode's pay-as-you-go tiers, for instance, bill per request regardless of IP type — their marketing line is "never per credit, never with hidden multipliers," and against this workload that turns out to be a real differentiator rather than a slogan:
| Plan | $/mo | Multiplier | Real requests | Real $/1k |
|---|---|---|---|---|
| Geonode PAYG 1M | $126 | 1 | 1,000,000 | $0.13 |
| Geonode PAYG 250k | $43 | 1 | 250,000 | $0.17 |
| Geonode PAYG 50k | $13 | 1 | 50,000 | $0.26 |
Five to ten times cheaper than Shifter for the same residential workload.
But here is the part a comparison written by a vendor would leave out. When we probed vendor API hostnames directly on 2026-08-20, api.geonode.com returned a connection timeout, and Shifter's documented scrape.shifter.io returned a TLS certificate mismatch. The two vendors with the most interesting pricing were the two whose public endpoints we could not confirm from outside. The most likely explanations are dull — authenticated-only ingress, or stale public docs — but we could not distinguish them without a key, and we are not going to pretend we could. The full probe set, including the ones that answered, is in the buyer-side proxy comparison.
Cheapest on paper is not the same as cheapest in production. Which is, in a sense, this entire post.
Five questions to ask before you buy
Ask these in writing, before the card goes in. Any vendor worth using will answer all five in a sentence each.
- What is the credit multiplier for every request type you support? Get the full table, not the one for the tier you are looking at. If the answer is "it depends on the target," that is a real answer and it means you cannot forecast your bill.
- Which tiers can use residential IPs at all? Not "which tiers include residential credits" — which tiers can issue the request. These differ.
- Are failed requests charged? Geonode and Shifter both state they are not. Get it in writing anyway, and define "failed": a 403 from the target is obviously a failure, but is a 200 with an empty body? Plenty of platforms answer exactly that way, and whether your vendor's success detector notices is a question with a direct line to your invoice.
- Are empty results charged? Different question, and the answer is more often yes. A search endpoint that legitimately returns zero matches has done the work — most vendors bill it. Decide whether you are willing to pay for zero rows.
- What is the price per 1,000 successful requests for my specific targets? Make them do the multiplier arithmetic on your workload. If they will not, do it yourself from their published table and send them the number to confirm.
Question 5 is the only one that produces a comparable figure. The others exist because you cannot answer it without them.
How to verify all of this in ten minutes
Nothing here requires an account.
- Open each vendor's pricing page and find the credit or unit-consumption table. It is usually below the plan cards, sometimes behind a "see how credits work" link, occasionally only in the docs.
- Write down the multiplier for the IP type your targets need. If you do not know, assume residential for anything social and datacenter for anything that renders without JavaScript from a cloud IP.
- For each plan:
real requests = credits ÷ multiplier, then$/1k = (price ÷ real requests) × 1000. - Sort by that number, not by the plan price.
- Archive the pricing pages you used. They change, and the version you priced against is the one you should be arguing from in three months.
Step 5 is not paranoia. Pricing pages in this category are edited frequently and quietly, and the multiplier table is the part most likely to move.
Why this is worth writing down
There is nothing sophisticated here. It is one division. The reason it is worth a post is that the framing does the damage: a credit sounds like a unit of work and behaves like a unit of currency, and the exchange rate is printed somewhere you are not looking at the moment you are comparing two numbers.
Nobody is being defrauded. Every number in this post came off a public page. But a pricing model where the headline figure is off by 10x for the most common workload is a model that survives on its readers not reaching for a calculator, and it is worth being the person who reaches for the calculator.
For what it is worth, we took the other side of this: every endpoint we run publishes its price as an x-credit-cost field in our OpenAPI spec, so the cost of a call is machine-readable rather than something you derive from a table. That is a design choice with obvious self-interest behind it, and you should still do the arithmetic on us.
Sources. Vendor pricing tables and endpoint probes are recorded in research/11-proxy-and-scraper-providers.md, gathered 2026-08-20. Vendor pages change; archive anything you plan to rely on.