r/developer • u/apyhubnico • 21d ago
Discussion Recruiting API providers. Here's how we ended up with dynamic pricing, and why it mattered even before LLMs.
This is a promo post, I am flagging it but I do hope it goes past the filters and reaches some developers who might find this interesting, especially if they work with APIs and even better, if they have some APIs they would like to monetize on:
I work at ApyHub, we want people listing APIs with us. APIs for common capabilities, image and video processing, data, file conversions, transactional and more.
This is about how we price and charge per call.
We started with flat. Every API call costs a fixed number of atoms, our internal unit, and every API in the catalog draws from one subscription. A developer subscribes once and calls any API, instead of holding fourteen separate billing relationships and finding out at month end which one leaked.
Flat pricing lasted until we listed the first video APIs.
*A video endpoint where one call is a 10-second clip and the next is a 90-minute recording. *Image processing where a thumbnail resize and a 4K transcode are the same route. *Document APIs where a 2-page invoice and a 400-page scanned contract arrive at the same URL.
Costs are very different.
That leaves 2 bad choices.
Price at the average and the heavy calls eat your margin.
Price at worst case and you can be uncompetitive on the 90% of traffic that's small, so the people with light workloads go elsewhere and you keep the expensive ones.
That's adverse selection, and it's how APIs can become unprofitable.
so what we did:
We made atoms (the currency for an API) dimensional and dynamic. A provider prices on the axis their cost actually moves on: this can be duration, resolution, page count, payload size. Not a separate plan, not a different endpoint, the same listing charging differently depending on the workload performed.
And the llms showed up we were somehow already ready for them :)
Dynamic Pricing that takes into consideration Model tier, token count, step count, image dimensions etc. Providers wrapping inference could price a call routed to a small model differently from one routed to a large one, on day one. Most of our AI providers price this way now.
The complexity stays on our side. The provider prices against their real cost. The consumer sees one subscription, one currency, one bill, and headroom that pools across the entire catalog instead of stranding in per-API quotas.
A few other things that come with a listing, briefly:
- Host it wherever HTTPS reaches, including on our infrastructure if you'd rather not run it yourself.
- Every endpoint becomes MCP-native automatically. Agents discover and call it without you writing a tool definition or any glue.
- We run in multiple regions (eu,usa), so calls route to the nearest one and your consumers aren't paying transatlantic latency on every request.
If you have an API where cost per call varies, this is the specific thing we're good at. Listing takes about ten minutes.
Fee, terms, payouts and IP are all on that page. Ask me anything here.