Pricing API Access for Machine Buyers

Choosing the unit

The unit is the pricing decision. Everything else is a number attached to it.

Three properties make a unit work. It tracks your marginal cost, so volume does not invert your margin. It is legible to the buyer before they commit, so they can decide whether the call is worth making. And it is countable without dispute, so neither side needs to reconcile.

Per request is the simplest and works when requests cost roughly the same. It breaks when one request can be cheap or expensive depending on parameters, because buyers will discover the expensive shape and you will be serving it at the cheap price.

Per unit of output works when the response size varies: records returned, rows, pages, seconds of audio. It aligns cost and price directly and it requires the buyer to accept a price they cannot fully predict before the call, which is a real friction for a client deciding automatically.

Per unit of input is predictable for the buyer and only tracks your cost if input size drives your cost.

Per successful result is the strongest position and the hardest to operate. The buyer pays for outcomes, not attempts, which is what they actually want. It requires you to define success unambiguously and absorb the cost of failures, which is only viable when your failure rate is low and stable.

When a request can vary by orders of magnitude in cost, quote per request with a cap on the expensive dimension rather than pricing the average. Pricing the average is how a small number of heavy buyers turn a profitable endpoint into a loss.

The floor and the ceiling

The floor. Every paid request costs you the settlement itself plus verification plus the compute to serve it. On a low cost network the settlement component is small, and small is not zero, and it is fixed per transaction rather than proportional to price. That fixed component sets a minimum viable price below which each call loses money regardless of volume.

This is the specific reason very small per call prices need batching or a prepaid balance rather than settlement per request. If you want a price point below your per transaction floor, the answer is to change the settlement pattern, not to accept the loss and hope volume fixes it. It does not.

The ceiling. Set by what the buyer's alternative costs, and machine buyers evaluate alternatives more consistently than humans do. A person might stay on a familiar API out of inertia. A client comparing two endpoints on price and latency has no inertia, and will move the moment the comparison changes.

That cuts both ways and it is not purely bad news. It means a genuinely better price wins business immediately rather than after a sales cycle. It also means you should assume your price is being compared continuously rather than at renewal.

Between the two, price against the value of the specific work rather than against a monthly plan. Seat and tier pricing has no meaning to a buyer that is one process making one call, and attempting to translate a subscription model onto machine access produces packages nobody selects.

Making the price machine readable

A human buyer reads a pricing page once and integrates. A machine buyer decides per call, which means the price has to arrive in the payment challenge itself, in a form a client can parse and evaluate against its own budget.

That implies several things most pricing pages get to ignore.

Quote before commitment. The challenge should state the amount, the asset, the destination, and how long the quote is valid. A client that cannot determine the cost before paying has to either pay blind or give up.

Stable enough to reason about. Prices that move per request, by demand, or by buyer identity are difficult for an automated client to plan against, and the usual response is to route to whichever provider is predictable. Surge pricing is a human pattern that does not transfer well.

A published schedule alongside the challenge. Clients frequently want to evaluate before making a request. A machine readable price list lets them, and the alternative is that they discover your pricing by probing.

An explicit quote expiry. Without one, a client can present a stale quote and you have to decide whether to honour it under time pressure.

The rules you must state before launch

These are the cases that generate every billing dispute, and with machine buyers at volume they occur constantly rather than occasionally.

Errors on your side. A request that fails because of your service should not be charged. State it, because a buyer whose agent is charged for your outages will notice quickly and their remedy is to leave.

Errors on their side. A malformed request that you rejected without doing work is normally free. One that consumed resources before failing is a judgement call, and the answer needs to be written down rather than decided per incident.

Retries. Agents retry aggressively and a timeout does not tell the client whether the work was done. Bind each paid request to an identifier so a retry of the same intent is served from the original result rather than charged again. Without this, retry storms bill buyers repeatedly for one unit of work, which is the fastest way to lose an integration.

Cache hits. If you serve a cached response at near zero cost, charging full price is defensible only if you say so. Many providers discount cache hits and it is a genuine differentiator for buyers that poll.

Empty and unsatisfying results. A search returning zero rows consumed the work. Charging for it is reasonable. Failing to state it is not, since the buyer experiences it as being billed for nothing.

Write these into the terms served alongside your price schedule. An agent cannot ask a question, and every ambiguity you leave becomes either a support ticket from its operator or a silent departure.