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

Jonas Keller, Senior Automation Architect at SIÁN Agency, rewrote an Instagram transcript actor on Apify to use pay-per-event pricing instead of pay-per-result. The new model charges separately for run start, content processed, and fast processing, which improved margin stability and eliminated hidden costs from retries and setup. The actor is now live as the Instagram AI Transcript Extractor.

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.