Pay-per-event pricing looks like a billing decision. It is really a constraint on what you are allowed to ship: once the user is charged per row, every defect in your output is a line on an invoice, and the argument about whether a row was worth paying for is one you will always lose.
How the model works
Instead of charging for compute time, the Actor declares named events with prices, and charges one each time it produces the corresponding result. The Nextdoor Actor charges per business, per city, per recommendation and per post; the coches.net Actor charges per listing and per dealer profile.
| Event | Price | What the user is buying |
|---|---|---|
actor-start | $0.00001 | The platform minimum. Effectively free. |
business | $0.008 | One business with 34 fields. |
recommendation | $0.002 | One neighbor recommendation, classified by kind. |
listing | $0.002 | One car listing with 55 fields. |
dealer | $0.004 | One dealer profile with business contact details. |
The immediate consequence for the user is that cost scales with value received rather than with how inefficient the Actor happens to be. A run that finds nothing costs nothing, and a slow implementation is the developer's problem instead of the customer's.
Why error rows have to be free
Consider the alternative honestly. A target site rate-limits you mid-run, forty rows fail, and each one is charged. The user paid for forty rows containing an error message. That is not a pricing edge case, it is a refund request — and it will arrive every single time anything transient goes wrong, which on the public web is weekly.
So failures go to a separate errors dataset, with the reason attached, and they are never charged. Two benefits fall out of one decision: the billing question disappears, and the main dataset stays clean because failures were never in it.
Charging incrementally, not at the end
Charging as each row is produced rather than accumulating and billing at completion matters for one specific case: the run that does not complete. A user who aborts at 30%, or whose run hits a spend limit, has received 30% of the rows — and under incremental charging that is exactly what they pay for.
It also means a spend limit works the way people assume it does. The Actor stops cleanly at the limit instead of continuing to produce rows it cannot charge for, or producing half a row.
The $0.00001 start event
Apify does not permit an event priced at literally zero, so the minimum is $0.00001 — a hundred-thousandth of a dollar. It exists purely to satisfy that constraint, and it is documented rather than hidden, because an unexplained charge on a run that returned nothing is the kind of detail that costs trust out of proportion to its size.
Ten thousand empty runs would cost ten cents. It is as close to free as the platform allows, and saying so plainly is cheaper than being asked.
Choosing what counts as an event
The interesting design work. An event should correspond to a unit the user would recognise as a thing they wanted — a business, a listing, a dealer — and its price should reflect roughly what it cost to produce.
Which is why a Nextdoor business is $0.008 and a recommendation is $0.002: the business row requires discovery plus extraction across 34 fields, while a recommendation is additional content on a page already fetched. Pricing them identically would either overcharge for recommendations or subsidise them from the business price, and both distort what users ask for.
There is a discipline in this that has nothing to do with money: a field nobody uses is still being paid for. Per-row pricing makes you notice.
What this means if you are buying
- Check whether error rows are charged. If the documentation does not say, assume they are.
- Check when charges apply. Per row as produced, or in a lump at the end? It only matters when a run fails, which is when it matters most.
- Run the smallest possible first job. Under per-event pricing that costs cents and tells you the real fill rates for your specific target, not the documented average.
- Set a spend limit anyway. A distance-ordered directory or an unbounded facet expansion can produce more rows than you expected — as measured here.
