Pay-Per-Event Pricing and Billing Explained

Every Devil Scrapes Actor is priced Pay-Per-Event (PPE): a small flat fee to start the run, plus a price per result actually delivered. No data lands, you pay only the start fee. This page explains exactly how that billing works, how to cap it, and why it’s a better deal for you than the compute-based pricing most scraping tools still use.

The two charges

1. Actor-start fee — a flat charge (commonly $0.20 across our fleet) fired once when the run boots, regardless of outcome. It covers the container warm-up, the proxy handshake, the initial request — the fixed cost of standing the scraper up, whether or not it finds anything.
2. Result price — charged per item that actually lands in your dataset, typically $1–$5 per 1,000 results depending on the Actor. This is the variable cost: the more we deliver, the more it costs, in direct proportion.

Concretely, for google-ads-transparency (start fee $0.20, $3.00 / 1,000 results): a run that returns 1,000 ad rows costs $0.20 + (1,000 / 1,000 × $3.00) = $3.20. A run on the same input that happens to match zero ads costs $0.20 — nothing more.

That “no data, no charge beyond the warm-up” behavior isn’t a courtesy discount — it’s the whole point of PPE. You’re not paying for compute time spent looking; you’re paying for rows that showed up.

Where to find the exact price

Every Actor’s Store page and README carries a Pricing table with the exact per-event prices for that specific Actor — don’t assume the fleet-typical $1–$5/1,000 range applies uniformly; some Actors cost more per row because the underlying extraction is heavier (rendering a page vs. hitting a lightweight endpoint), and some cost less. The number on the listing is the number you’ll be billed, before you click Run.

Capping what a single run can cost

If you’re calling an Actor from an automated pipeline against an input whose match count you don’t fully control — a broad search term, a domain with an unknown number of ads — cap the spend up front:

• maxTotalChargeUsd — stop the run once total PPE charges for that run reach this dollar figure.
• maxItems — stop the run once it’s returned this many result rows.

Both are accepted as query parameters (or SDK-equivalent options) on the run-start endpoints covered in Run any DevilScrapes Actor via the API:

curl -X POST "https://api.apify.com/v2/acts/DevilScrapes~google-ads-transparency/runs?maxTotalChargeUsd=10&maxItems=2000" \
  -H "Authorization: Bearer $APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"searchDomains": ["nike.com"]}'

This run stops itself once either ceiling is hit, whichever comes first, and you keep whatever rows already landed — a capped run still delivers a usable partial dataset, not nothing.

How this interacts with your Apify plan and credits

PPE charges draw against your Apify account’s usage balance — the same balance funded by your monthly plan allowance or by any credits on the account (new accounts get free trial credit to cover early runs). You don’t need a specific plan tier to use PPE Actors; it works identically on the free tier and on paid plans. What changes between plans is mostly account-level ceilings (concurrent runs, memory limits, storage retention) — not how any individual Actor is priced.

Why PPE beats compute-unit billing, for you

Before Pay-Per-Event, most Apify Actors billed on raw compute time — CPU-seconds and memory-seconds consumed, independent of what the scrape actually returned. That model quietly punishes the buyer in a specific way: a target that’s slow to respond, or that makes us retry through backoff and proxy rotation to get past a block, burns compute time whether or not you end up with usable data. You’d pay more for us fighting harder against the same target, with no guarantee of a better outcome.

PPE flips the incentive the right way. We absorb the retries, the backoff, the fingerprint rotation, the proxy switches — all the mechanics of getting past a block — as our own cost, not yours. You pay for the outcome: rows that landed in your dataset, plus one small fixed fee to stand the run up. If a target has a rough day and forces five retries per page, that’s on us, not on your invoice.

FAQ

What exactly is the actor-start fee for?

It covers the fixed cost of booting the run — spinning up the container, resolving a proxy session, making the first request — regardless of how many results come back. It’s charged once per run, not once per result.

Do I pay for a run that fails outright?

A run that fails because we couldn’t complete the scrape at all (a hard block, an unrecoverable error) is a bug on our side, not intended behavior — our monitoring (see Maintenance and support) exists to catch that quickly. A run that succeeds but legitimately finds zero matching results is different: that’s a correct SUCCEEDED outcome, and you’re charged only the actor-start fee.

Can I set a hard ceiling so a run never overspends?

Yes — pass maxTotalChargeUsd (dollar ceiling) or maxItems (row-count ceiling) when starting the run. The run stops itself once either limit is reached and you keep the partial results already delivered.

Does Pay-Per-Event cost more than the old compute-based pricing?

It shifts the risk, not necessarily the average price. Under compute billing you pay for effort regardless of outcome; under PPE you pay for delivered rows plus one small fixed fee. For a target that behaves normally, the two land in a similar place; for a target that fights back, PPE protects you from paying more for our retries.

Where do I see exact historical charges for my runs?

Your Apify account’s Billing / Usage section in the Console breaks down charges by Actor and by event type (actor-start vs. result), so you can audit exactly what a given run cost and why.