Why a failed scrape should cost you nothing

Every data API bills one of two ways. Per request: you pay when you ask. Per result: you pay for what comes back. On a pricing page that looks like a detail. On an invoice it is often the largest single factor.

Same advertised rate of $1.00 per thousand in both columns. Per request you pay $10.00 for ten thousand asks and receive seven thousand profiles. Per result you pay $7.00 and receive the same seven thousand. The real rate differs by 43%, and the gap is entirely your fill rate.

Fill rate is not a constant. It drops when you chase harder targets, when a platform tightens something, when your list ages, and when you expand into a region where more accounts are restricted. Under per-request billing, every one of those raises your cost per useful row while your usage graph looks unchanged. Request count flat, bill flat, cost per delivered row quietly up by a third.

On a paged endpoint with a high fill rate — comments on posts you already know are busy, followers of large accounts — one request returns hundreds of rows and per-request billing makes that page nearly free. If your workload is overwhelmingly that shape and your targets are hand-picked rather than exported from something, per-request can come out ahead. The question is which model matches the distribution of what you actually ask for.

The words are used loosely. "Pay per success" usually means per request that returned a 200 — and a 200 with an empty array is a success by that definition, at full price. The question that settles it: if I ask for a hundred and forty come back, what do I pay? If the answer is "a hundred", you are on per-request billing whatever it is called.

One rate, whatever the endpoint returns. A run that comes back with nothing costing nothing is not a goodwill gesture — it falls out of the unit being the row rather than the attempt.