---
title: "Dynamic pricing: every API call costs what the work actually costs"
url: https://apyhub.com/blog/dynamic-pricing-every-api-call-costs-what-the-work-actually-costs
author: ApyHub
published: 2026-08-20T12:12:52.674823Z
tags: [platform, engineering, consumption]
---

# Dynamic pricing: every API call costs what the work actually costs

# Dynamic pricing: every API call costs what the work actually costs

## Introduction

APIs on ApyHub can price each request individually, based on the work that request actually involved. A two-page document and a two-hundred-page document go through the same endpoint and cost different amounts, because they are different amounts of work.

Almost no other API marketplace or API catalog works this way, and the reason is structural rather than a missing feature. Per-call pricing forces a decision nobody wins: price for the average request and lose money on the heavy ones, or price for the worst case and overcharge everyone else. Averages and ceilings are both guesses. This post is about removing the guess, and about why the usual API subscription model has nowhere to put the answer.

## Where this started: media, then AI

We built this for video and image processing.

That is where flat per-call pricing falls apart in the most obvious way. A thumbnail resize and a 4K transcode are not comparable operations. Neither are a single-page scan through an OCR API and a five-hundred-page archive. Any one number covering both is wrong twice over, and providers were being asked to pick it anyway.

So we moved the price off the endpoint and onto the request. The provider calculates what a request cost once the work is done, and reports it. The consumer is charged that.

Then AI caught up, and the same shape appeared across the whole category. Model selection, input length, output length, reasoning depth, image resolution. A large share of the catalog suddenly had costs varying by an order of magnitude inside a single endpoint. The mechanism we built for video files turned out to be the correct answer for LLM inference too, without modification.

The market moved in the same direction. \<cite index\="20-1">In Orb's 2026 study of 80 AI-agent companies, 91.3% used usage-based pricing, up from 83.3% in the previous year's study\</cite>. Consumption-based billing is now the default architecture wherever the cost of serving a request is variable.

## The innovation: two-phase settlement on a shared unit

The hard part of per-request pricing is a sequencing problem. The real price of a request is only knowable after the work is done. The consumer's ability to pay has to be confirmed before the work starts. Those two facts point in opposite directions.

Card payments solved this decades ago with authorization and capture. Authorize an estimated amount, do the work, capture the real amount. ApyHub applies the same pattern to API billing.

The gateway deducts the endpoint's base price before forwarding the request, which is what the balance check runs against. Your API does the work and reports the real cost. The gateway settles the difference in either direction. Charge more, refund the excess, or charge nothing at all.

That pattern only works on top of a billing unit with four properties at once. It has to be **fungible** across the entire catalog, so headroom is not trapped inside one API. It has to be **finer than a request**, so a call can be expressed as four times heavier than another call. It has to be **prepaid**, so the pre-authorization is a real check rather than a promise. And it has to be **reconcilable**, so a settlement can move in both directions after the fact.

That unit is atoms. Two-phase settlement is the mechanism. Neither works without the other, and that pairing is the actual invention here. The response header providers set is the small, visible part of a foundation that had to exist first.

## What it takes to use it

One header on your response.

http

```
HTTP/1.1 200 OK
X-Apy-Atoms: 120
```

That is the price of the request. Whatever the endpoint's base price was, this value replaces it and the gateway settles the difference. There is no pricing dashboard to configure, no plan ladder to build, and no approval cycle. If you can compute a number in your handler, you can price with it.

A few of the ways providers actually use it:

**By what was processed.** A document conversion API charges a base price plus a small amount per page. Ten pages costs one thing, two hundred pages costs another, and both are honest.

**By what was asked for.** A text-to-speech API offers a standard voice, a premium voice, and a high-fidelity voice from one endpoint. Each carries its real cost, with no need to split them into three separate catalog listings so the pricing makes sense.

**By both.** An AI endpoint prices the model, the input, and the output together. A short prompt to a small model and a long document to a large one are billed for what they are.

**By outcome.** A request that fails on the provider's side can be priced at zero. Nobody pays for work that did not happen.

## Why other API marketplaces don't do this

RapidAPI, APILayer, and the other established API marketplaces are not failing to implement a header. They are operating a different billing foundation, and per-request dynamic pricing has nowhere to land inside it.

Credit where it is genuinely due first. RapidAPI built this category. Its catalog and discovery surface remain the largest in the market, it introduced a generation of developers to third-party APIs, and it has added MCP support across its catalog. APILayer runs a tightly curated, mostly first-party set of APIs with unusually consistent documentation and predictable behavior, precisely because it operates what it sells.

The constraint is the model underneath, and it comes down to four things.

**The billing primitive is the call.** On a per-request-count marketplace, one call is one unit. There is no unit smaller than a call, so there is no way to express that this particular call was four times heavier than the last one. The vocabulary does not exist.

**Entitlement is scoped to one API.** A monthly plan buys a quota on a single API. A variable price has nothing meaningful to draw against, and a refund of a partial call into a per-API quota does not mean anything. Headroom bought on one API cannot cover another.

**Overage is postpaid.** When a call can cost a variable amount and billing settles after the fact, the consumer has no ceiling. This is not hypothetical: \<cite index\="28-1">Zylo's 2026 SaaS Management Index found that 78% of IT leaders had encountered unexpected charges tied to AI features or consumption-based pricing, and 61% had cut projects because of unplanned software cost increases\</cite>. A marketplace layering variable pricing onto postpaid overages would be building that problem deliberately.

**Providers set plans, not price functions.** The provider-facing model is a set of tiers with quotas attached. There is no point in the request lifecycle where a provider reports a number and the platform acts on it.

None of this is fixable with a feature. Supporting per-request pricing means replacing per-API plan quotas with a fungible prepaid unit shared across the whole catalog, which is a change to the foundation of how the business bills. It is a rebuild, not a roadmap item.

What providers do instead on those platforms is push the variance into the catalog structure. One API becomes three listings, or a plan ladder of basic, pro, and ultra tiers sized around expected usage. It works. It also means the consumer picks a bucket in advance and pays for the bucket, which is the averaging problem moved rather than solved.

|                         | ApyHub                                  | Per-API subscription marketplaces       |
| ----------------------- | --------------------------------------- | --------------------------------------- |
| Billing unit            | Atoms, finer than a single call         | Request count, one call is one unit     |
| Entitlement scope       | Whole catalog, headroom is pooled       | One API, quota per plan                 |
| Who sets the price      | Provider, per request, at response time | Provider, per plan, in advance          |
| Cost of a heavy request | Priced at its real cost                 | Same as a light request                 |
| Payment timing          | Prepaid, settled per request            | Postpaid overage on a monthly plan      |
| Spend ceiling           | Bounded by the prepaid balance          | Bounded by whatever the calls add up to |
| Handling cost variance  | Priced per request                      | Split into tiers or separate listings   |

## What this gives providers

Pricing stops being a compromise. You charge what a request cost you, so heavy requests are no longer subsidized by light ones, and light requests are no longer priced out of existence.

One endpoint can carry a whole product. Models, quality levels, and processing options live behind one URL instead of a fragmented listing per variant. Consumers pick what they need and the price follows the choice. Your catalog page stays clean and your API monetization stays honest.

Pricing logic lives in your own code. Change the formula, ship it, and the new pricing is live. There is no platform ticket, no plan migration, and no renegotiation with existing consumers.

The model scales with your service. As you add capability, you price the capability. You never have to raise a flat rate across your entire consumer base to cover a feature only some of them use.

And you get paid for work that a request-count model quietly gives away. Every large document, every long transcription, every high-resolution render.

[**Publish your API on ApyHub →**](https://apyhub.com/api-provider)

## What this gives the teams calling those APIs

The bill tracks the work. Small requests cost less, large requests cost more, and nothing is averaged or padded against a worst case that never occurs on your workload. This is consumption-based pricing in the literal sense, measured on the individual call.

Overcharges come back automatically. When a request turns out cheaper than the endpoint's base price, the difference is refunded at settlement. Nothing to claim, nothing to reconcile at month end.

Everything stays comparable. Every API in the [ApyHub catalog](https://apyhub.com/catalog) is priced in atoms, so a document conversion, a data enrichment lookup, and an inference call sit in the same unit on the same bill under one subscription. Comparing the cost of two very different services becomes arithmetic.

The ceiling does not move. Atoms on [ApyHub](https://apyhub.com/) are prepaid, so a consumer cannot be charged past the balance they have authorized, regardless of how any individual provider prices a request. Dynamic pricing changes what a call costs. It does not change what a subscription can cost.

That last pairing deserves attention, because variable pricing normally arrives with spend risk attached. Here it does not. Price variance and spend exposure are handled by two separate mechanisms, so gaining the first does not require accepting the second.

## AI agents are the consumer this was built for

Every endpoint in the catalog is reachable through the ApyHub MCP server. An agent can search the catalog, understand what an endpoint does, compare endpoints solving the same problem, and call the one it selects, with no hand-written wrapper and no bespoke tool definition per service.

Agent traffic behaves nothing like a human-written integration. A developer writes one integration that sends one shape of payload forever. An agent explores. It tries several options, runs calls in parallel, escalates to a larger model when a smaller one fails, and shapes its payloads based on what it discovers partway through a task. Request weight stops being uniform in a way no plan tier can anticipate.

Three consequences follow.

**Plan tiers cannot be selected by an agent.** Choosing a subscription bucket in advance is a procurement decision made by a human weeks before the traffic exists. An agent that decides at runtime to use a higher-fidelity model has no way to buy the right plan first. Per-request pricing is the only structure where a runtime decision can carry its own price.

**Cost becomes a variable the agent can reason about.** When quality and price move together, an agent can weigh them. Use the cheap model for a first pass and the expensive one for the cases that need it. Under flat pricing that tradeoff is invisible, because everything costs the same no matter what it does.

**Spend containment has to be structural.** An agentic workflow can fan out to thousands of calls faster than any human can notice. Alerting on that is a monitoring problem and arrives too late. Prepaid atoms make it an arithmetic problem instead: an agent cannot spend authorization it does not have. That property comes free from the same billing unit that makes dynamic pricing work.

The last one is the point most often missed. The industry conversation about agent spend control tends to reach for budgets, alerts, and kill switches bolted on after the fact. A prepaid, fungible, catalog-wide unit gives you the ceiling as a property of the model rather than as a feature that has to be watched.

## Conclusion

Flat per-call pricing was a reasonable simplification while API calls did roughly comparable amounts of work. Video processing broke that assumption. AI finished the job.

Dynamic pricing puts the number where the information is. The provider knows what a request cost. The consumer pays that amount and no more. Nobody estimates on anybody else's behalf, and no average stands in for a measurement.

The mechanism providers touch is a single response header. What makes it possible is the unit underneath, and that is the part a per-API subscription marketplace cannot retrofit.

[**Explore the catalog →**](https://apyhub.com/catalog)

## FAQ

**What is dynamic API pricing?** It is pricing where the cost of an API call is calculated per request, based on the work that specific request involved, rather than a fixed rate per call. On ApyHub the provider reports the real cost in the response and that value becomes the charge.

**How is this different from usage-based API pricing?** Most usage-based API pricing meters the number of calls, which still treats every call as equal. This meters the work inside each call, so payload size, model choice, and processing depth all affect the price.

**Why can't RapidAPI or APILayer do this?** Their billing primitive is the request count and their entitlements are per-API plan quotas, so there is no unit finer than a call and nothing for a variable price to draw against. Supporting it would require replacing that foundation rather than adding a feature.

**Do all ApyHub APIs use dynamic pricing?** No. Endpoints where every request does roughly the same work keep a fixed price, which is simpler and appropriate. Dynamic pricing exists for endpoints where the work genuinely varies.

**Can a request end up cheaper than the listed price?** Yes. If the real cost lands below the endpoint's base price, the difference is refunded automatically at settlement.

**Can dynamic pricing cause a surprise bill?** No. Atoms are prepaid, so total spend is capped by the balance you have authorized regardless of how individual requests are priced.

**How hard is dynamic pricing to implement as an API provider?** It is one response header. If your code can calculate a number, it can set the price, and no additional platform configuration is required.

**How does this work for AI agents calling APIs?** Agents reach every endpoint through the ApyHub MCP server and pay per request, so a runtime decision to use a more expensive model carries its own price without any plan being selected in advance. The prepaid balance caps total agent spend structurally.

**Why is everything priced in atoms?** Atoms are the single billing unit across the whole catalog. That is what makes a document conversion and an inference call comparable on the same bill, and what allows headroom to be spent against any API rather than trapped in one.

## About ApyHub

[ApyHub](https://apyhub.com/) is a curated API catalog and trusted operational layer for teams and agents that consume APIs in production. The catalog covers 400+ services and 1,400+ endpoints, with new APIs and providers onboarded continuously, all available under a single subscription billed in atoms. Every service carries machine-readable certification covering GDPR, SOC 2, and ISO 27001 alignment, and every endpoint is MCP-ready by default. ApyHub is headquartered in Amsterdam, with offices in the Netherlands, Greece, and India, and serves 65,000+ developer workspaces every month. The free tier requires no card. If you build APIs, you can [publish yours on ApyHub](https://apyhub.com/api-provider).