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

> Source: <https://dev.to/sian-agency/i-rewrote-our-instagram-transcript-actor-for-pay-per-event-pricing-the-economics-flipped-154d>
> Published: 2026-06-25 03:00:00+00:00

**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.

Pay-per-result conflates three different things into one transaction:

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 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:

``` js
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:

`pushData`

.Three months in:

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](https://apify.com/sian.agency/instagram-ai-transcript-extractor?utm_source=devto&utm_medium=blog&utm_campaign=jonas&utm_content=pay-per-event-pricing-instagram-actor) — 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.*