Pay-per-result vs subscription API pricing, explained with real numbers

Web data APIs are priced in confusingly different ways. One charges per request, another sells credits where some requests cost 5 or 25 credits, a third bills per successful result, and most wrap it all in a monthly plan with overage rules in the small print. Comparing them honestly takes some arithmetic.

This post explains the common models, the hidden costs to check for, and then works through real break-even examples using the two ways you can buy Siftwright's tools: a monthly subscription to our API, or pay-per-event on the Apify Store. Both are ours, so we have no reason to steer you to one. For many workloads, the cheaper option is not the subscription, and we'll show exactly when.

The four common pricing models

1. Per request

You pay for every call, whatever happens. Simple to understand, but you carry the risk: if the target site times out, or a search returns nothing, you still pay. Look for whether "request" includes failures.

2. Credits with multipliers

You buy a pool of credits and each call consumes some number of them depending on the options you use. JavaScript rendering, premium proxies or certain target sites can multiply the cost of a single call by 5, 10 or more. Credits make the headline price look low; the real price depends entirely on your mix of options. Always convert to "cost per useful result at the options I actually need".

3. Per successful result

You pay only when you get what you asked for: one transcript, one screenshot, one article. Failures, empty searches and timeouts are free. This moves the risk to the provider, which is fair, since the provider controls reliability. The thing to check is the definition of "result": per search (which may return many items) and per item are very different units.

4. Subscription with an included quota

A fixed monthly price includes some number of requests, credits or results. The price per unit falls as plans get bigger. The key questions are what happens at the limit (automatic overage charges, or a hard stop?), whether unused quota rolls over, and how much of the plan you'll really use. A plan you use at 40% costs 2.5 times its advertised per-unit price.

Hidden costs to check before you buy

• Failed requests. Are they counted? Some providers state clearly that they aren't; others are silent.
• Multipliers. Which options multiply cost, and will you need them?
• Overage. Is it automatic? At what rate? Is there a cap?
• Rollover. Unused quota usually expires at the end of the period.
• Minimums. Annual-only small plans, seat fees, setup fees.
• Platform fees. Marketplace pricing may add platform or compute charges on top of the listed price.
• Your own time. A cheaper API that fails 10% of the time costs you engineering hours in retries and monitoring.

Our two options, stated precisely

Siftwright API subscription, billed monthly by Stripe. One unit is one successful result (a transcript, a capture or an article), shared across all three tools. At the limit, requests get HTTP 429 until the next period or an upgrade; there's no automatic overage.

Pay-per-event on the Apify Store, billed by Apify to your Apify account. No subscription with us. You pay per successful result, at different prices per tool:

Two Apify details for completeness: some runs also incur a tiny per-run start charge (currently $0.00005 per run per GB of memory), and your Apify account's plan determines how the usage is paid for. Apify's free plan includes a monthly platform credit; check Apify's pricing page for the current amount.

Break-even points

Because the subscription is a fixed price, it only beats pay-per-event once you use enough of it. The break-even volume is the plan price divided by the per-result price:

Read it like this: on Pro, if you'd use more than 33,000 transcripts a month (and at most 50,000), the subscription is cheaper. For screenshots or news alone, Starter and Pro never beat pay-per-event on price. Business and Enterprise do, once you use most of them.

Mixed workloads sit in between. The general rule: the subscription wins when you use a large share of a plan, especially for transcripts.

Worked examples

1. A side project summarising videos: 2,000 transcripts a month. Pay-per-event: 2,000 × $0.003 = $6.00. Starter: $29. Pay-per-event wins easily.

2. An agency capturing client sites: 40,000 screenshots a month. Pay-per-event: 40,000 × $0.0015 = $60.00. Pro: $99. Pay-per-event wins.

3. A research tool: 20,000 transcripts and 20,000 articles a month. Pay-per-event: $60 + $30 = $90.00. Pro ($99, 50,000 results) covers the 40,000 results with 10,000 to spare. Almost identical; Pro costs $9 more and buys headroom, one key and one invoice.

4. A learning platform: 45,000 transcripts a month. Pay-per-event: 45,000 × $0.003 = $135.00. Pro: $99. The subscription saves $36 a month.

5. A media monitoring product: 220,000 articles a month. Pay-per-event: 220,000 × $0.0015 = $330.00. Business: $299. The subscription saves $31 a month, with 30,000 results of headroom.

6. Spiky usage: 5,000 results most months, 60,000 in one busy month. A subscription sized for the peak (Business) wastes money eleven months a year. Pay-per-event absorbs spikes naturally. Alternatively, stay on a small plan and upgrade in the billing portal for the busy month; Stripe prorates the change.

You can plug in your own numbers with the calculator on our pricing page.

It's not only about price

Even when the numbers are close, the models behave differently:

• Predictability. A subscription with a hard limit is a fixed, known bill. Pay-per-event scales with usage, which is great for small volumes and needs a usage limit for safety at large ones.
• Accounts and integration. The subscription is one REST API and one key, no Apify account needed. Pay-per-event runs in your Apify account, which is convenient if you already use Apify for other Actors, schedules and storage.
• Agents. Apify's hosted MCP server makes the pay-per-event tools available to AI clients like Claude and Cursor with a single config block. With the subscription, agents call our REST API as tools. We covered both in feeding web data to AI agents.
• Failures. Both options bill only successful results.

Comparing across providers

When you compare us, or anyone, with another provider, normalise to the same unit:

1. Decide what one useful result is for you: one transcript, one screenshot, one article.
2. Convert every plan to "price per 1,000 useful results at the options I need", including multipliers.
3. Adjust for how much of the plan you'll really use.
4. Check the overage and failure rules.

Units matter. A SERP API that charges per search can be much cheaper than a per-article API if you want 50 articles from each query, and much more expensive if you want 3. We try to spell this out on our comparison pages, including the cases where a competitor is the better deal.

Summary

• Convert every price to cost per useful result at your real usage.
• Check how failures, multipliers, overage and rollover work.
• For our tools: pay-per-event is cheaper at low and moderate volumes, especially for screenshots and news; a subscription wins when you use most of a plan, especially for transcripts, and gives you one key, a fixed bill and a hard cap.

If you're unsure, start pay-per-event on the Apify Store or with the free live demo, watch your real volumes for a month, and move to a plan when the numbers say so.