The case against per-endpoint pricing
Charging differently for each endpoint makes your bill unpredictable and quietly teaches developers to write worse code.
Several providers we talked to this year price per endpoint: a lookup costs one unit, a batch call costs five, a webhook registration costs three. It sounds fair. It causes two problems that are not obvious until you have lived with it.
Your bill becomes unforecastable
To predict next month's spend you have to predict the mix of calls your application will make, which depends on user behaviour you do not control. A feature that shifts traffic from a cheap endpoint to an expensive one can double a bill without changing the request count at all.
Finance teams respond to this by asking engineers to estimate, engineers respond by padding, and the padded number becomes the reason the project is not approved.
It teaches developers to write worse code
If the batch endpoint costs five units and the single-item endpoint costs one, a developer fetching five items will write a loop. The loop is worse for them — five round trips instead of one — and worse for the provider, who now serves five requests. The pricing has taught both sides to do the inefficient thing.
We saw exactly this in an evaluation: a customer had built a per-item loop over an endpoint that accepted a hundred IDs at once, purely because of how the units were counted.
What we do instead
One call is one call. A batch of a hundred is one call. Where a request is genuinely expensive to serve, that belongs in the rate limit, not in the unit price — the limit shapes traffic without making the invoice unpredictable.
The result is a bill you can forecast by multiplying request volume by a single number, and an API where the efficient way to use it is also the cheap way.
There is a real cost to this. It means we absorb variance that a per-endpoint model would push onto the customer. We think a predictable invoice is worth more than the margin.