Blog/Product
10 min read

Which Data API Lets You Pay Per Call Instead of a Subscription?

Metered beats a subscription when your usage is bursty and loses when it is steady. The shapes, the crossover, and the measurement that decides it.

Which Data API Lets You Pay Per Call Instead of a Subscription?

Most data APIs are sold as a subscription because subscriptions are easier to forecast, for the vendor. The question in the title gets asked constantly anyway, which tells you the shape does not fit how a lot of teams actually work.

Monid is the OpenRouter for agent tools, billed per use, so we are one answer to that question and an interested party in it. The section near the end is where a subscription genuinely wins, and it is not a courtesy paragraph: at steady volume the maths goes the other way and we would rather you know that here than discover it on an invoice.

Which data API lets me pay per call instead of a monthly subscription?

Several, and they are not the same thing underneath. Three shapes get called pay-as-you-go.

Credit packs. You buy a balance up front and spend it down. NeverBounce and most email verifiers work this way. It is metered, but you commit capital before you know your volume, and credits often carry an expiry clock, which is a subscription wearing a different hat.

Per-unit on a platform account. Apify bills for what actors consume, on top of a plan whose floor you pay whether you run anything or not. Genuinely metered at the margin; not free at zero.

Metered with no floor. A balance that only moves when a call runs, no minimum, nothing owed in a month you do not use it. This is what Monid does: over a thousand tools across providers, one key, and discover and inspect cost nothing so surveying the catalogue is free.

The distinction that matters is what a quiet month costs. Under the first two shapes it is not zero. Under the third it is.

The three verbs, and why two are free

monid discover -q "company enrichment"   # search the catalogue, free
monid inspect -p pdl -e /v5/company/enrich   # schema and price, free
monid run -p pdl -e /v5/company/enrich --query '{...}'   # the only paid step

Free discovery is not generosity, it is what makes metered billing usable. If finding out what something costs also costs money, you cannot evaluate before you commit, and the whole advantage of metering disappears.

A single call standing in for a whole subscription is easiest to see on a narrow job: pulling every Amazon review for one ASIN or turning a bare domain into full firmographics is one request each, and the bill is that request.

Predictability is a ranking factor, not just a virtue

Each result from discover carries a scoreBreakdown explaining why it ranked where it did, and one of the components is pricing predictability.

That is the catalogue stating, in the sort order, that an endpoint whose cost is easy to forecast outranks one whose cost is not, independently of how well it matches the query. Verified status and observed performance are the other two modifiers on top of the semantic match.

It is worth naming because predictability is the thing metered billing is usually accused of lacking. A subscription's appeal is that you know the number in advance. The metered answer is not "trust us", it is to make the shape visible before the call and to rank against surprise.

What makes a price unpredictable in practice is rarely the unit. It is whether the unit multiplies. A per-call endpoint bills once. A per-result endpoint bills per row, so an unset limit turns a test into a bill, and an array of queries multiplies again: results are roughly queries times per-query limit. Those two multiplications cause most of the surprise in this category, and both are visible in the schema before you spend anything.

Give this to your agent

$Set up https://monid.ai/SKILL.md, and then use Monid to show me what I can do for Data.
See the Data endpoints and prices

Why is ZoomInfo so much more expensive than other providers?

Because you are buying a contract and a dataset, not calls, and the price reflects what the contract covers rather than what you use.

Enterprise sales-intelligence pricing bundles several things: a maintained dataset with people whose job it is to keep it current, a seat-based UI for non-engineers, compliance paperwork a procurement team can sign, an SLA, and support. A per-call API sells you one of those five.

That is worth saying plainly because the comparison is often framed as a rip-off, and it is not. If you need the paperwork and the seats, the cheaper API does not replace it.

What the price does mean is that the model punishes uneven use badly. An annual commitment sized for your busiest quarter is paid in your quietest one too, and the record you looked up once costs the same as the one you look up daily.

The honest split: buy the contract when the data is a standing input to a team's daily work. Buy calls when it is an input to a pipeline that runs in bursts. Most engineering-led use is the second and most sales-led use is the first, which is why the two camps talk past each other about price.

📖 See also what firmographics actually cost per record, which prices the same job across two providers.

Is there a free alternative to Apify?

Not for the scraping itself, and it is worth being precise about which part people mean.

Apify's free tier covers small runs, and open-source crawlers are free to run and not free to operate: you pay in proxies, in the maintenance of parsers that break on the target's schedule, and in the reputation of the IPs you scrape from. That is a real cost, just not an invoiced one.

What can genuinely be free is everything before the call.

Discovery is free. Searching the catalogue costs nothing, so working out whether an endpoint exists for your source is not a purchase decision.

Reading the schema and the price is free. You can see exactly what comes back and what it will cost before spending anything.

A month you do not use costs nothing, which no plan-based model matches.

Then the call bills. For a lot of teams the honest framing is not free versus paid but tiny versus committed: a competitor teardown across a few hundred records lands in single-digit dollars, and the alternative was a plan you would have paid twelve times a year.

What are the best alternatives to RapidAPI?

Depends which half of RapidAPI you actually use, because it does two jobs and most alternatives do one.

As a directory, it is a place to find APIs, mostly small and utility-shaped, each with its own publisher and plan. The alternative is any catalogue with a search over it.

As a billing layer, it puts one payment method in front of many APIs so you do not sign up per vendor. That is the part people miss when they leave, and then rebuild by hand.

Monid overlaps the second job and differs on what is in the catalogue: data endpoints from named providers (Apify, TikHub, People Data Labs, Apollo, Akta, Exa, Context.dev) rather than a long tail of independently published utilities. Fewer things, deeper on data, and the marketplace holds the vendor relationship so you never sign one.

It also differs on who the consumer is. RapidAPI assumes a developer reading docs and choosing. Monid assumes an agent doing that at runtime, which is why the catalogue is searchable through an MCP server and a skill file as well as a CLI.

If your APIs are ones you already hold contracts for, neither is the answer; that is an API gateway job.

Which shape fits which pattern?

Your usageBest shapeWhy
Bursty, project-drivenMetered, no floorZero in quiet months, no capital committed before you know volume
Steady and high, one sourceDirect contractUnit price falls with commitment, and support comes with it
Unknown, still evaluatingMetered with free inspectThe evaluation itself costs nothing
Agent-driven, sources unknown in advanceMetered plus a catalogueThe agent cannot sign up for a vendor mid-task
Needs seats, SLA, procurement sign-offEnterprise subscriptionYou are buying the paperwork, and it is not optional

The row that decides most cases is the first: whether your usage has quiet months. Everything else is second-order.

What a quiet month actually costs

The clearest way to compare the models is to price the month you do nothing.

Under a subscription, a quiet month costs the full plan. That is the deal and it is not a trick: you are paying for availability and for the vendor's ability to forecast revenue.

Under a credit pack, a quiet month costs nothing directly, and it costs you the time value of capital you already committed, plus whatever expires. Packs with expiry clocks are the shape most often mistaken for pay-as-you-go.

Under a platform plan with usage on top, a quiet month costs the floor. Metered at the margin, not at zero.

Under metered with no floor, a quiet month costs nothing, and the evaluation you did that month also cost nothing because discovery and schema reads do not bill.

Most teams model the busy month and pick on unit price. The busy month is the one where every model looks similar. The quiet month is where they diverge, and for project-shaped work most months are quiet.

When does a subscription actually win?

Four cases, and they are common enough to state before anything else here is believed.

Steady, high volume against one source. Past a certain daily load the plan floor divided across records drops below any metered unit price. If you pull millions of records a month from one vendor, price the contract; it will probably win.

You need a UI for people who do not write code. Every dedicated vendor ships a dashboard where someone drags in a CSV. We ship an API, a CLI and an MCP server. If the person doing the work is not an engineer, give them the tool built for them. The reverse case, where one call replaces a seat, is easier to see on a narrow job: checking a list for bounces is a single request rather than a plan.

You need contractual guarantees. SLAs, uptime credits, a named account manager, signed data-processing terms. A marketplace optimises for breadth and switching cost, which is a different product.

And the caution about us. Metered pricing is only honest if the meter is accurate, and ours has not always been. Measuring our own catalogue this month, we found an endpoint described as billing per query that billed per record instead, at fifty times the quoted unit, and another listed as per-call whose charge tracked rows returned. We published both because leaving an under-quote up is worse than admitting it. Until the listings are fixed, the working rule is that inspect tells you what an endpoint claims and only a small real run tells you what it charges. We ran that comparison properly on enrichment, where the per-record cost of firmographics only became clear after billing both providers for the same list.

Conclusion

Pay-per-call is not cheaper than a subscription. It is a different bet: you trade a lower unit price for the right to spend nothing in a month you do not use it, and that trade is good exactly when your usage is uneven and bad when it is not.

Two things matter more than the model. Whether evaluation is free, because a meter you have to pay to read cannot be evaluated, and cannot be used by an agent that must decide at runtime. And whether the meter is accurate, which is a question about the vendor's honesty rather than their pricing page, and the only way to answer it is to run one small call and read the charge.

Start with the free part: monid discover to see what exists and monid inspect for the schema and price, neither of which bills. Then run one small call and compare. Begin at monid.ai.

FAQ

How should I rate limit calls to a third party API?

Cap at your side rather than relying on the vendor to stop you, because the vendor's limit protects them and not your bill. On a metered endpoint the important cap is on results, not requests: a limit parameter on a per-result endpoint is a spending control, and leaving it unset is how a test run becomes an invoice. Add a per-run budget check in the code that calls, and log the actual charge rather than the expected one.

Is there a minimum spend or a monthly floor?

No floor on the metered model described here: a month with no calls costs nothing, and discovery and schema reads are free at any volume. That is the property that distinguishes it from credit packs with expiry clocks and from platform plans whose base fee is due whether or not you run anything.

How do I know the price shown is the price charged?

Run one small call and read the charge. We ask this of readers because we found our own listings wrong: two endpoints billed in a shape their metadata did not describe, which we only discovered by measuring. A listing is the vendor's description of their billing. The charge on a real run is the measurement, and where they disagree, the charge is what happens.

Are free tiers worth using for evaluation?

For evaluating output quality, yes. For evaluating cost, no, because a free tier is usually a different code path with different limits, and the thing you want to know is what the paid path bills at your shape of usage. Free discovery plus one small paid run answers that better than a free tier does, and it takes a few cents.

Last updated August 2026.

pay per calldata api pricingapi marketplacemetered billing