I Rewrote Our Instagram Transcript Actor for Pay-Per-Event Pricing. The Economics Flipped.

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:

1. Setup work — booting the actor, validating input, warming the browser. Happens once per run regardless of how many URLs you pass.
2. Per-item work — fetching the post, extracting media, calling the transcription model. Scales linearly with input.
3. 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 }
  ]
}

Enter fullscreen mode Exit fullscreen mode

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();

Enter fullscreen mode Exit fullscreen mode

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.