Pay per result is cheaper when your volume is low, irregular or unknown. A subscription is cheaper when your volume is high, steady and predictable, and you use most of what the plan includes. The dividing line is a simple break-even: divide the monthly fee by the price per result. If you need fewer results per month than that number, pay per result wins. If you need more, month after month, the subscription wins.
That is the whole answer in one formula. The rest depends on details that pricing pages tend to hide: what counts as a "result", what happens to unused quota, what overage costs, and whether a free official source already gives you the same data. This article walks through each of those, with examples you can redo with your own numbers.
How the two models work
With a subscription you pay a fixed amount per month or year. In return you get a quota: a number of records, requests, credits or seats. Use less and you still pay the full fee. Use more and you either get blocked, pay overage, or move up a tier.
With pay per result you pay only for the records that are actually delivered. There is no monthly fee. A month in which you fetch nothing costs nothing. A month in which you fetch a lot costs a lot.
On Apify, where our tools run, this model is called pay per event. The developer defines the events that are charged, such as one delivered result, and the user is billed per event. Apify explains the mechanics in its pay-per-event documentation. One feature worth knowing: you can set a maximum charge for a run, so a run stops when it reaches your limit. That removes the main fear people have about usage pricing, which is an open-ended bill.
The break-even formula
Break-even volume per month = monthly subscription fee / price per result.
The numbers below are illustrative. They are not quotes from any vendor. Replace them with the real prices you are comparing.
Assume a subscription that costs $49 per month and includes 10,000 results. Assume a pay-per-result price of $0.01.
Break-even = 49 / 0.01 = 4,900 results per month.
Below 4,900 results a month, pay per result is cheaper. Above it, the subscription is cheaper, as long as you stay inside the included quota. That last condition matters, and so does the word "month". The subscription only wins if you clear the break-even in most months, not just in one.
Worked example 1: a one-off project
You want 2,000 customer reviews for a single competitor analysis. You will not need the data again.
- Pay per result: 2,000 x $0.01 = $20.
- Subscription: one month at $49 = $49, if you remember to cancel.
If you forget to cancel for three months, the subscription has cost 3 x $49 = $147 for the same 2,000 records. For one-off work, pay per result is nearly always the cheaper choice. The risk with a subscription here is not the price. It is the renewal.
Worked example 2: steady daily monitoring
You track new job postings in your sector and pull about 300 new listings every day.
- Monthly volume: 300 x 30 = 9,000 results.
- Pay per result: 9,000 x $0.01 = $90 per month.
- Subscription: $49 per month, and 9,000 fits inside the 10,000 included.
The subscription saves $41 per month, or $492 per year. This is the case subscriptions are built for: a known volume, every month, close to the quota. You use 90 percent of what you pay for.
Worked example 3: spiky demand
You need about 500 results in a normal month. Once a year you run a large study and need 20,000 in a single month.
- Annual volume: 11 x 500 + 20,000 = 25,500 results.
- Pay per result: 25,500 x $0.01 = $255 per year.
- Subscription: 12 x $49 = $588, plus overage in the peak month.
In the peak month you exceed the quota by 10,000 results. Assume overage costs $0.008 per result. That adds $80, for a total of $668 per year. The subscription costs more than twice as much, even though its price per record looks lower on paper. In eleven months out of twelve you pay for 10,000 results and use 500.
The lesson: compare annual totals, not headline unit prices. A low unit price that depends on using the full quota is only real if you use the full quota.
The fine print that changes the math
Before you compare two offers, check these points on both.
What counts as a result. Is a duplicate record charged? An empty search? A record with half its fields missing? A failed request? Under a subscription, a failed request often still burns a credit. Under pay per result, you should only be charged for delivered records, but confirm that in the tool's own description.
Unused quota. Many plans do not carry unused quota into the next month. If yours does not, your effective price per record is the monthly fee divided by what you actually used, not by what was included.
Overage and tier jumps. Some plans bill overage per record. Others force you into the next tier for the whole month. A tier jump for a small excess can be the most expensive records you ever buy.
Minimum terms. Annual contracts give a discount in exchange for commitment. That is a fair trade if your need is stable for a year. It is a bad one if you are still testing whether the data is useful.
Budget control. Usage pricing needs a cap. Set a maximum charge per run and a limit on results per run. Without those, a broad search query can return far more than you planned for.
Fixed costs you carry yourself. A subscription gives a predictable invoice, which some finance teams value more than the lowest total. That is a legitimate reason to pay a bit more.
Check the free options first
Sometimes the cheapest price is zero. Before paying under either model, see if an official source covers your need.
Official filings. The US Securities and Exchange Commission offers free JSON APIs for company submissions and financial data, with no API key required. See the SEC EDGAR API documentation. The SEC asks automated users to identify themselves and stay within its published request limits, as described in its guidance on accessing EDGAR data. If you have a developer and you only need raw filings, this is the better choice. A paid tool earns its price only when it adds something: parsing, filtering, deduplication, or a signal built from several filings.
Job listings. Several applicant tracking systems publish public job board endpoints. Greenhouse, for example, documents a Job Board API where the published jobs of a company can be read without authentication. If you follow a short list of employers that use such a system, reading those feeds directly is free. It stops being practical when you need hundreds of employers across many different systems, each with its own format.
Your own reviews. If you want the reviews of your own business, most platforms let the verified owner read or export them through a business dashboard or an official API. That route is free and the data is complete. Paid collection makes sense for reviews of other businesses, where no owner access exists.
Manual export. For a few dozen records, copy and paste into a spreadsheet is honest work and costs nothing but time. Automation pays off when the task repeats or the volume grows.
What the data can and cannot include
No pricing model fixes gaps in the source. Tools that collect public web data see what a visitor who is not logged in sees, and nothing more.
For job listings, that usually means the title, employer, location, description and posting date. It often does not include a salary, because many employers do not publish one. It does not include applicant counts or recruiter details that sit behind a login. Listings that were removed before a run are gone, and the same job can appear on several boards with small differences.
For reviews, public pages show the text, rating and date. Some platforms show only part of the reviews to visitors who are not signed in, or limit how far back you can page. Reviews that the platform filtered or removed are not visible to anyone outside. Reviewer identity is limited to the public display name.
For official filings, the data is complete in the sense that everything filed is public. But filings arrive with a delay set by law, not by the tool. An insider trade is reported after it happens. An institutional holdings report describes a quarter that has already ended.
This matters for cost. If a result lacks the field you need, you paid for a record you cannot use. Run a small test first, under either model, and count how many records carry the fields you care about. Then compute your price per usable record. That is the number to compare.
A short decision checklist
- Write down your expected volume per month for the next twelve months, month by month.
- Compute the annual cost under each model, including overage and unused quota.
- Check for a free official source that covers the need.
- Run a small paid test and measure the share of usable records.
- If your volume is steady and above break-even in most months, take the subscription. Otherwise pay per result, with a spending cap.
You can also switch later. Starting on pay per result is the low-risk way to measure your real volume. After three months of actual usage you will know your break-even position from data instead of a guess.
Our tools at DataSignals Lab are priced per delivered result, with no monthly fee, so you can run the small test described above before committing to anything. The current price per result for each tool is listed on our pricing page.
Want the signal instead of the raw filings? Get a free report preview. Prefer the tool to the write-up? Browse all data feeds or connect the free MCP server.