Pay-per-event pricing changes more than the checkout line on an Apify Actor. It changes the unit of value the Actor promises, the way users estimate a run, and the way builders protect margins when a task gets expensive.
I checked Apify's current monetization documentation and a public Store/API sample on 13 August 2026. No paid Actor was run. The goal was narrower: compare the pricing patterns a builder can see before publishing or choosing a model, then turn those patterns into a practical worksheet.
Key takeaways
- Pay-per-event pricing makes the billable unit part of the product design.
- The clearest default is usually one primary event that matches a successful user-visible output.
- Add-on events are useful when enrichment has different cost or value, but they must be obvious before the run.
- Builders should model platform costs, user max-charge limits, and partial-output behavior before migrating.
- A public Store/API pricing sample can reveal pricing shape, but it cannot prove demand, retention, or final margins.
What changed with Apify pay-per-event pricing?
Apify pay-per-event pricing lets an Actor charge for specific events triggered by its source code, such as creating a result, processing an item, or calling an external API. That is different from plain pay-per-usage, where the user only pays the underlying platform usage generated by the run.
The official Apify monetization docs describe two monetization models for Store Actors: pay per event and pay per usage. The pay-per-event documentation adds the practical details: builders can use synthetic events, define custom events, choose a primary event, and decide whether to pass platform usage costs on to users.
Two synthetic events matter for most scrapers. apify-actor-start charges for starting a run, and apify-default-dataset-item charges for each item written to the default dataset. Custom events let the builder charge for work that does not map cleanly to a dataset row: contact enrichment, AI analysis, media download, API lookup, or another unit of value.
This also matters for agent workflows. Apify says an Actor must use pay-per-event pricing to be eligible for agentic payments. If an AI agent is going to discover and pay for a tool, it needs a predictable event model it can inspect before execution.
Which pricing patterns showed up in the public Store sample?
The public sample showed five practical pricing patterns: free/platform usage, per-result, start-plus-result, add-on events, and pay-per-event plus platform usage. None is automatically best. Each pattern gives users and builders a different tradeoff between predictability and margin risk.
| Pattern | Public example from 13 Aug 2026 | What the user understands quickly | Builder risk |
|---|---|---|---|
| Free / platform usage | apify/website-content-crawler reported FREE pricing | The Store listing does not add a paid event charge | Platform usage can still matter outside the listing's public price label |
| Per result | apify/instagram-scraper priced a result event by tier | "I pay when I get rows" | Bad rows, duplicates, or expensive rows can hurt trust or margin |
| Start + result | 6sigmag/fast-website-content-crawler had actor-start and result events | A run has a base charge plus output charge | Empty runs need careful handling |
| Add-on events | compass/crawler-google-places priced contacts, leads, reviews, images, and filters separately | Enrichment is optional and priced separately | Users can underestimate cost if add-ons are not explained clearly |
| PPE + usage | Some Store records exposed isPPEPlatformUsagePaidByUser | Builder can pass through platform usage during pricing tests | Apify warns this is less transparent for users |
The sample also showed tiered pricing. For example, the public apify/instagram-scraper sample priced a result at $0.0027 for free-tier users and $0.0005 for diamond-tier users. The data_xplorer/google-news-scraper-fast sample priced a result at $0.004 for free and bronze users, and $0.001 for gold, platinum, and diamond users.
Those tiers are not just discount labels. The Apify pricing and costs docs say higher tiers can also lower the platform unit costs used in the builder's cost computation. That means a mature Actor may need pricing that works for small tests and high-volume buyers without turning one group into a margin problem.
How do event choices change task design?
A billable event should be the smallest reliable unit of value that the user can understand and the Actor can account for. That makes pricing a product-design decision, not just a finance setting.
The Apify SDK pay-per-event guide recommends charging per unit where practical because it gives better control over budget consumption. The same guide warns that if a builder batches charges with a count, the returned charged count may be lower than requested when the budget is insufficient. In other words, the Actor must use the charge result to decide how much work it can actually perform.
That guidance changes how a builder should design loops:
| Actor job | Weak event design | Better event design |
|---|---|---|
| Crawl pages | Charge one large batch before crawling | Charge after each page is successfully processed |
| Return business leads | Charge every place row the same | Separate base place, contact enrichment, lead enrichment, and verification |
| Analyze social posts | Hide AI analysis inside base price | Make AI analysis an optional event if it has separate cost |
| Search profiles | Charge only when full profiles are found | Decide whether a search-page event is fair when zero matches still consume work |
The point is not to split every action into a paid event. Too many events make the listing harder to understand. The point is to separate events when the cost driver, user value, or user choice is materially different.
For agents, this connects directly to metadata-first Actor selection. An agent should inspect pricing events before it runs the Actor. If the user asked for emails, AI labels, transcripts, or full media downloads, the agent should treat those events as explicit cost decisions, not incidental fields.
How much can add-ons change the estimate?
Add-ons can make the base result event a small part of the final bill. The clearest example in the 13 August public sample was compass/crawler-google-places, where the free-tier place event was $0.004, but business lead enrichment was $0.10 per successful lead.
The worksheet below uses the public free-tier event prices from that sample and assumes every requested event succeeds. It excludes platform usage pass-through and account-specific discounts.
| Scenario for 1,000 Google Maps places | Formula | Estimated event charge |
|---|---|---|
| Plain places | 1000 * $0.004 | $4.00 |
| Places with two filters | (1000 * $0.004) + (1000 * $0.001 * 2) | $6.00 |
| Places with contact enrichment | (1000 * $0.004) + (1000 * $0.002) | $6.00 |
| Places with business lead enrichment | (1000 * $0.004) + (1000 * $0.10) | $104.00 |
That does not make the lead event bad. It may be the highest-value part of the Actor. But it changes how the product should be presented. A user asking for "1,000 Google Maps businesses with emails" is not asking for the same cost shape as a user asking for "1,000 places with ratings and websites."
This is where pay-per-event pricing is strong when implemented well. The listing can expose the difference before the run starts. It also creates a clean prompt for an AI agent or workflow UI: "Do you want contact or lead enrichment, and what maximum run cost should be enforced?"
What does this change for output size and limits?
PPE Actors need max-result controls and budget-aware stopping as product behavior. A builder should not treat spending limits as an afterthought, because the platform can stop charging and then abort the run after a user's run limit is reached.
Apify's PPE docs say users can set a maximum cost for a run, and that the platform enforces it. The same docs name ACTOR_MAX_TOTAL_CHARGE_USD and charge-result fields such as eventChargeLimitReached, chargeableWithinLimit, and chargedCount as the signals builders should inspect.
That leads to four implementation rules:
- Charge only after the user-visible work has been completed or saved.
- Stop cleanly when the next event is no longer chargeable.
- Make partial output obvious in the dataset and run log.
- Set default input limits so a first run cannot accidentally become a large production job.
It also changes how pricing evolves. Apify classifies price increases, pricing-model changes, and new paid events as significant monetization changes that require a 14-day notice period. Decreasing prices or removing events can take effect immediately. A builder should therefore avoid publishing a half-thought event model and assuming it can be reshaped freely the next day.
What should builders put in the pricing worksheet?
Builders should fill the worksheet before changing code or publication settings. The goal is to make one line of pricing map cleanly to one line of user value.
| Worksheet field | Decision to make | Why it matters |
|---|---|---|
| Primary event | What is the main value unit: result, profile, page, lead, file, or API product? | This is what users see first on the Actor detail page |
| Start event | Is there a real setup cost that should be charged once per run? | It protects expensive startup work and discourages empty probes |
| Add-on events | Which optional enrichments have separate cost or value? | It keeps base pricing simple while preserving advanced features |
| Minimum max charge | What run budget is too low to complete a useful first result? | It prevents user limits that guarantee a failed or unprofitable run |
| Default result limit | What is the safe first-run size? | It makes experimentation predictable |
| Failure rule | Which failed, duplicate, empty, or partial items are not charged? | It turns fairness into code, not support judgment |
| Tier strategy | Should high-volume users get lower unit prices? | It can improve enterprise fit while keeping test runs accessible |
| README wording | How will users understand the bill before running? | Pricing clarity reduces refunds and failed expectations |
The simple formula is:
estimated event charge =
start events
+ sum(primary event count * primary event price)
+ sum(add-on event count * add-on event price)
+ platform usage when passed through
Builder profit is a different calculation. Apify's PPE docs state the formula as (0.8 * revenue) - platform costs. The 20% platform share means an event that looks profitable at the revenue line can still lose money if browser memory, proxies, external APIs, retries, or media downloads are not priced into the event.
For a builder choosing what to make next, pricing should be inspected alongside demand and output fit. The earlier Apify Store demand snapshot helps identify categories worth studying. The free Apify Actor audit gives a quick metadata pass on one listing before you rewrite README, schema, or pricing copy.
What this test proves, and what it does not
This test proves a narrow thing: public Apify Store/API metadata is enough to identify pricing shape before running an Actor. It can show whether a listing is free, per-result, start-plus-result, add-on-heavy, tiered, or passing platform usage through to the user.
It does not prove that a price is good. Public metadata does not expose private conversion rates, support cost, refunds, retention, actual platform resource usage for a specific run, or the builder's external API bills. It also does not prove data quality. A low per-result price can still be expensive if the Actor returns duplicates, misses fields, or requires many retries.
The sample is also time-sensitive. Store pricing, event names, tiers, and discounts can change after 13 August 2026. Use the worksheet as a way to think, not as a permanent price list.
Final take
Pay-per-event pricing is best when it makes value legible. The user should know what they are paying for, the Actor should charge only when that value is produced, and the builder should know whether the event covers platform costs.
The practical default is simple:
- Pick one primary event that maps to successful output.
- Add separate events only for optional or materially different work.
- Respect max-charge limits in the run loop.
- Publish the pricing logic in the README and input schema.
- Start with a capped test before scaling.
Cosnify is designed around that same guarded path from idea to tested Actor. You can start a guided Actor build, review Cosnify credit packs, or keep reading the Cosnify field notes before you publish a pricing-sensitive workflow.