docs / pricing model · updated 2026-07-20
What is a pay-per-result data API?
A pay-per-result data API bills per delivered record instead of per request, per credit, or per month. One transcript, one comment, one review — each delivered row fires one charge. An input that can't deliver returns a typed success: false row instead, is not billed, and does not stop the batch. The price of a run is therefore the size of the usable dataset it produced, not the number of attempts it took.
How the billing actually works
The mechanism matters, because it is what makes the failure contract enforceable rather than a marketing promise. On Apify, apihq's actors bill through an explicit per-result charge event: code fires the event only at the moment a usable record lands in your dataset. Billing is not attached to dataset writes, so a failure row can sit in the same dataset — with its stable code and request_id — at exactly $0.0000 (the full error-code registry). Platform compute is included in the per-result price, and a hard spend cap can be set per run from Apify's Run Limits panel.
Against the other two models
| pay-per-result | pay-per-request | subscription / quota | |
|---|---|---|---|
| You pay for | delivered records | attempts, successful or not | capacity, used or not |
| A failed item costs | $0.0000 | the same as a success | quota units either way |
| An idle month costs | $0 | $0 | the full subscription |
| Spend maps to | dataset size | input quality × retries | the calendar |
The practical difference shows up on dirty inputs. Real batches contain dead IDs, captionless videos, and apps with no reviews. On a typical per-request meter, that garbage is billed at full price; on a per-result meter, a batch of 5,000 inputs where 400 can't deliver bills exactly 4,600 rows and returns 400 typed, free failure rows.
Where the model fits — and where it doesn't
Pay-per-result fits unattended pipelines with variable volume and imperfect inputs: the bill tracks the data, failures are free, and nobody operates proxies or retry loops. It is the wrong tool when a free library from a residential IP covers your volume (use the library — our Python guide says exactly when), or when your volume is so high and steady that fully-utilized flat infrastructure beats any per-unit price.
apihq's eight actors all price this way: $3.00 per 1,000 transcripts, $0.50 per 1,000 videos, $0.40 per 1,000 shorts, $0.40 per 1,000 comments, $0.20 per 1,000 results, $0.08 per 1,000 reviews, $0.08 per 1,000 reviews, and $0.40 per 1,000 reviews. The catalog with per-API details is at /actors.
Frequently asked questions
- What does pay-per-result mean?
- You are billed per delivered record — a transcript, a comment, a review — not per API call, per credit, or per month. A request that delivers nothing costs nothing.
- How is pay-per-result different from pay-per-request?
- Most per-request APIs bill the attempt whether or not usable data comes back, so errors and empty responses cost the same as successes. A pay-per-result API bills only when a record is delivered; failures return as typed, unbilled rows.
- What stops a pay-per-result run from overspending?
- The spend is proportional to delivered data by construction, and on Apify you can additionally set a hard cap in the Run Limits panel — the actor stops cleanly at the cap and keeps the results already delivered.
- Is pay-per-result always cheaper?
- No. At very high, steady volumes a flat subscription you fully utilize can cost less per record, and a free library run from a residential IP costs nothing but your time. Pay-per-result wins when volume is variable, when failures are common in your inputs, or when you don't want to operate scraping infrastructure.