What 'Pay Per Row' Really Means When You Scale to Millions of Rows

Pay-per-row pricing explains the model, and pay-per-row, vertical by vertical works the actual dollars for runs in the hundreds and low thousands of rows. Neither answers the question that matters once a pipeline is real: what happens at a million rows. The honest answer is that the price doesn't change — what changes is what actually slows you down.

Does the per-row price drop as you scale up?

No. There's no volume tier, no bulk discount, no negotiated rate past some threshold. A row costs the same whether it's the first one you've ever pulled or the ten-millionth. That's a deliberate simplicity: a flat price means you can estimate a million-row job's cost with the same multiplication you'd use for a hundred-row one — rows × price_per_record — and the estimate stays accurate regardless of scale. If you're used to vendors that reward volume with better unit economics, this is worth stating plainly rather than assuming: here, volume buys you nothing on price.

What actually slows you down at a million rows?

Not the row count itself. Requests are rate-limited at 60 per minute per API key — and that's a limit on how many jobs you can start, not on rows returned within a job. A single job with a generous maxResults can return tens of thousands of rows without touching that limit at all.

The limit bites when your workload is shaped as many small jobs instead of few large ones. Company Employees takes one company URL per call — there's no batch mode. Pulling employee data for 10,000 target companies means 10,000 separate job starts, and at 60/minute that's a little under three hours just to enqueue the work, independent of how long each job takes to actually run or what it costs. A vertical with batch input — LinkedIn Companies accepts an array of URLs in one call — doesn't hit this wall the same way. Before estimating how long a large pull will take, check whether the endpoint you need takes one entity per call or a batch, because that shapes your timeline far more than row count does.

How do you avoid running out of balance mid-run?

Check GET /balance before starting anything large — it's a free call, and knowing your ceiling before you commit to a job beats finding out mid-run. If the wallet can't cover a job, the API returns a distinct rejected_balance status rather than failed — the run was refused before it started, not broken partway through, and that distinction matters if you're triaging errors programmatically. If the wallet runs dry while a job is already running, you still get every row collected up to that point, plus a notice explaining the balance ran out. Nothing already fetched is thrown away; you top up and resume from where you actually stopped, not from zero.

How do you pull a million rows without choking on pagination?

The same way you'd pull a hundred: set maxResults to what you actually need and let one job handle it. The response caps inline data at the first 100 rows with truncated: true past that, but every job — regardless of size — has a results endpoint you page through, and a download endpoint that streams the full set as a single CSV or JSON file. For a million-row pull, downloading once beats paging through it in application code; use the file, not a loop of results calls.

What does a real million-row run actually cost?

Take Indeed Jobs at $0.00005 per job — the cheapest endpoint in the catalog. A 2,000,000-row pull, roughly a full national snapshot of postings across a wide search, costs $100. That number holds exactly whether you pull it as one job or spread across a hundred — the price is the same either way, because nothing about pulling more changes the per-row rate.

The 200x spread across this table at the same row count is the same effort gradient the vertical-by-vertical post already covers — it just compounds harder once you're multiplying by millions instead of hundreds. Run the math on your actual endpoint before you commit to a scale, not after.

FAQ