TL;DR — Moved an Instagram transcript actor from pay-per-result to pay-per-event billing. Three events, not one number. Margin held, retries stopped silently bleeding cash, and the actor is now honest about what it's actually charging for. If your scraper has a "credits" tab in the README, this is for you.
For a year I shipped scrapers the same way everyone does: one big knob — pay-per-result, $X per item, computed at the end of the run. It looked clean from the README. It was a mess underneath.
The actor would start, spin up a browser, hit Instagram, run into a transient block, retry, succeed on three out of ten URLs, and spit back a number. The user paid for three. We absorbed the cost of the seven retries, the cold start, and the GPU minutes the transcription model burned on partial audio. On a good week the unit economics worked. On a bad week — when Instagram changed something and our success rate dropped to 60% — we paid Apify and OpenAI for the privilege of running a free service.
That's the trap pay-per-result puts you in. Your price is fixed. Your cost isn't.
The teardown
Pay-per-result conflates three different things into one transaction:
- Setup work — booting the actor, validating input, warming the browser. Happens once per run regardless of how many URLs you pass.
- Per-item work — fetching the post, extracting media, calling the transcription model. Scales linearly with input.
- Optional premium work — the fast-processing path that costs us more per item but the user explicitly asked for.
Charging one rate for "a result" forces you to subsidise items #1 and #3 out of the margin on item #2. When users bulk-submit URLs, item #1 amortises and you're fine. When they submit one URL at a time, you eat the setup cost on every run. When they enable fast processing on every call, you eat the premium delta on every call.
Apify's pay-per-event model lets you charge for each of these separately. So we did.
The replacement pattern
The new actor declares three events in actor.json:
"monetization": {
"events": [
{ "name": "ActorRunStarted", "price": 0.005 },
{ "name": "InstagramContentProcessed", "price": 0.018 },
{ "name": "FastProcessingUpgrade", "price": 0.002 }
]
}
Then in the actor body, you charge against those events at the moment the work is actually done:
import { Actor } from 'apify';
await Actor.init();
await Actor.charge({ eventName: 'ActorRunStarted' });
for (const url of input.bulkUrls) {
try {
const result = await processInstagramPost(url, input.fastProcessing);
await Dataset.pushData(result);
// Only charge per item on success.
await Actor.charge({ eventName: 'InstagramContentProcessed' });
if (input.fastProcessing) {
await Actor.charge({ eventName: 'FastProcessingUpgrade' });
}
} catch (err) {
// Failed items don't bill the user. They also don't bleed margin
// because the run-started fee already covered the setup.
log.warning(`Skipping ${url}: ${err.message}`);
}
}
await Actor.exit();
Three lines of policy:
- Run starts always bill. $0.005 covers boot. Doesn't matter if zero items succeed.
-
Per-item billing only fires after
pushData. Failures are free for the user — and free of margin loss for us, because we already covered fixed cost. - Premium path bills on top. If the user opted into fast processing, that delta is charged separately and visibly.
Result
Three months in:
- Margin per run stopped going negative on small-batch / high-failure runs. The run-started fee acts as a floor.
- Failed-URL ratio dropped from 12% to 4% — not because we got better, but because we stopped hiding failures behind a flat result fee. Users started reporting bad URLs in support, instead of opening refund tickets.
- Average revenue per user went up, not down, even though our headline price ($0.018/item) was lower than the previous flat $0.025. Setup fee + opt-in premium fee made up the difference.
Cleaner pricing, cleaner margin, cleaner conversation with users about what they're actually paying for.
If you're running an Apify actor on flat pay-per-result and your retry rate is anything above noise, you're subsidising the unreliable part of your stack. Move the line. Charge for what you do, not for what survives. The Instagram actor I rewrote with this model is live at Instagram AI Transcript Extractor — same shape applied across the rest of our actor portfolio over the last quarter.
What event are you not charging for that you should be? Drop the actor in the comments — I'll look at the schema.
Written by **Jonas Keller, Senior Automation Architect at SIÁN Agency. Find more from Jonas on dev.to. For custom scraping or automation work, hire SIÁN Agency.
Top comments (3)
This lines up exactly with what I went through migrating my own actors to pay-per-event. The thing nobody warns you about is the platform-usage toggle - if you absorb the compute cost on a scraper that hits a lot of pages, your margin can quietly go negative even at a "fair" per-result price. Passing usage through to the user fixed it. Did the flip change your run volume much, or mostly just revenue per run?
Yeah, that toggle is exactly it. For us it was mostly revenue per run — volume stayed pretty flat since it's the same callers hitting the actor, but the
margin per run stopped being a coin flip once compute got passed through instead of absorbed. The pages-per-run variance was the real killer: a flat
per-result price looks fair until one input fans out into 50 pages and eats the whole margin. Pay-per-event tracks the actual work, so the bad-case runs
stopped being loss-makers.
That fan-out variance is where it bit me too, and the ratio was bigger than I expected. Same marketplace, two regions: the Brazilian OLX resolves everything from one embedded payload and platform cost lands around $0.09 per 1k results. The European one has no embedded data and needs a paginated REST walk - about $0.26 per 1k. Same brand, same actor shape, roughly 3x the compute.
On a flat per-result price I'd have been quietly subsidising every EU run while the BR runs looked healthy and buried it in the average. What made it visible was breaking the usage cost out per target instead of per actor - the actor-level number was meaningless.
Did you end up pricing the fan-out as its own event, or just pass the usage through and let it float with page count?