Ask HN: How much to charge for an API call?

As far as I've seen, for APIs that don't "consume" any resources, the usual schema is to charge a fixed fee.

Either that or it's just included part of a higher pricing tier. Of course, there can be a quota restricting how many API calls are allowed per period.

Charging per call feels weird when the cost of a call is essentially zero. You only really see that in things that are computationally expensive like LLMs, image optimization, etc.

Your cost plus 20%

How much is it costing you? Charge a markup on that you're happy with rather than picking a number out of thin air?

Also set a healthy free limit, if people are already paying for one product, they're not going to want to pay for an API separately if they just want to make a few calls.

Depends on your business model, how useful/unique the API is and many other things.

I would suggest making it free to get an API key and run a small number of queries (or a low rate limit). That allows devs to build against your API without needing to take out their credit card. Beyond that, I'd suggest something like $1 per thousand calls and add a bulk discount if your larger users are providing extra value to you.

At a previous B2B SaaS company I worked at there was no per-call pricing but rather a larger yearly cost around API usage. If you anticipate the calls not to be too burdensome on your system that may be the route to go and add some rate limiting so your servers don't get too hammered.

How much value are you providing to your customers? Thats how you figure out what you are worth.

To give you a reference point, at https://scrapingfish.com/ we charge $0.002 per API call but in our case, the API call gives you the value by itself: access to mobile proxies and cluster of browsers. For you, I would recommend to either give the API access for free as I assume users already pay for the product. Another option would be to include API access only to higher plan users who pay more and this could be an incentive for some users to upgrade their plan.

"Im looking for a number that’s affordable for those that want to make a few calls as well as those looking to make thousands of calls without costing them too much."

I've been in this exact scenario before. What we decided on was a generous amount of free API calls included in the standard sales agreement/tier, with anything above 5000 reqs/monthly a bolstered on package.

Of course it will depend on the nature of your calls (are they really going to cost you much, even for many?), the nature of the relationship with your customer, etc. But it was smooth sailing for us.

You missed providing enough data to come up with something that would actually make revenue for you. Abstracting from a business model you have, there are SaaS businesses that don't charge for API call but a license fee that compensates the costs. Valuing an API call is hard, first you need to discover your costs related to handling that call at all, those fall into 2 groups:

1. direct costs - this one is relatively easy, you just keep track of all your spending that you need to cover to handle that API calls, this will be mostly: compute, storage, network costs, software licences, 3rd party software licences. You should have a good idea how much you need to spend on infra to handle 1kk API calls. There is a caveat here (!) increasing storage costs that grow every month. Lets say you save a transaction in DB for every API call made and you charged a customer for that. The thing is that (depending on your agreement with the customer) you have to keep that transaction in DB for lets say next 36 month. If you're handling millions of transactions... these numbers add up and you set set yourself in a very uncomfortable position after some time when you realize that even though you charge per API call, it's not enough to cover the costs of keeping data in DB that grows every month.

2. indirect costs - Depending you your business setup, you may need to incur office costs, backoffice staff, sales commission, SWE team compensation, on-calls... payment gateway commission, taxes and FX rates fluctuations if you're charging globally in different currencies. The bigger the org the harder it will be to know all of these indirect costs. Btw. these costs are usually flat and there is not much linear dependency on the number of API calls you do (but there is to the number of customer you have).

Where it gets interesting, is when you enter economies of scale... which means that you can keep your indirect costs relatively flat and your direct costs in a non-linear relation to the number of API calls made. To put into an example:

- tiny scale, 1kk API calls will have 100USD of direct costs + 10k USD of indirect costs = price per 1k calls is (10100 USD / 1 000) = 10,1USD

- a bit bigger scale, 100kk API calls will have 15000USD of direct costs + 10k USD of indirect costs = price per 1k calls is (25k USD / 100k ) = 0,025USD

see? You've handled 100x more traffic but your direct costs increased only by 15x and indirect stayed the same - this is what you should focus on in the end when building API SaaS product - how do I get into economy of scale the fastest.

Do you have any extra costs for this? Otherwise I would either include it in the normal pricing or just have a fixed price for api access.

I'd create a higher tier, like double the price, with API access.

But offer a very high rate limit.

Pricing is a core concept you may want to get some consultation on with trusted advisors and mentors.

You can adjust your pricing but it's a big ship, so it's good to get close to right.

What sorts of cliffs do your internal applications face? Any block pricing, where it is cheaper or more expensive after a certain amount of compute? You'll want to build these into pricing in some way, either in the assumptions or directly as a passthrough.

There are really only two important considerations here:

a) What does it cost to provide an api call? (Don't forget to consider both fixed cost to develop the API and ongoing costs to provide the compute.)

b) What's the api worth to your customers? Make some calls and do some research.

If b > a, then charge b.

The other folks commenting that it depends on your costs are spot-on. The following are important data points for getting your economics right:

0) Advertised SLA. What uptime and response time are you guaranteeing your customers?

1) Minimum cost of the platform (i.e., no traffic). From here, also determine what full utilization looks like in terms of max number of API calls within your advertised SLA.

2) Cost of platform at scaled utilization based on load projections. This is where you can figure out how to make money when negotiating committed or volume-based pricing for specific customers.

3) The overall human cost of building and maintaining the platform. Don't forget that you're not just covering the price of running the platform, but the time that you and possibly others have put into it. The last thing you want is for success to force you to make your platform more expensive because it's grown past the available sacrifices a single person bootstrapping an application can make. You'll be able to retain and delight customers better if your pricing model accommodates a mature business that supports actually paying someone a salary from the get-go.

One thought is, generally - either make real money out of it, or win a competitive battle out of it. Don't do something in between. So, charge a lot (make money) or charge zero (win competitive battle).

Who are your customers?

[flagged]

Your base price should include calls.

Don't bill people $5 + $.37 for low traffic.

If you have low to mid volume and usage in general, just charge a flat fee if you do want to charge for API. I would probably add a higher plan that includes API access and make it simple.

[flagged]

You should not charge people just to access their own data. That's abusive.

Charge only for extreme usage, like poorly written sync programs, maybe, maybe for realtime synchronization.

Let them access their data so they are comfortable using your product more, and charge them for the value your product gives them.

So there's two factors:

- What does it cost you to provide?

- What is it worth to your customers?

You need to understand both, before setting a price or even opening up the API.

This feels like systems engineering 101.

$1 per call.

Please don’t charge per call. It’s irritating. Charge for a block of calls or better still a block of calls in a moving time window. This way prospective clients don’t have to go ahead and estimate their entire design before using your product. A block (eg 100k calls every 24 hrs) gives them an easy way of balloarking their costs as well.

Depends on who your customers are. If their customers are strictly other businesses, you should set a base rate limit which is already included in the base fee and only pass the technical costs when the limit is exceeded. In other cases, charging per API call won't work because no business owner likes such unpredictable cost centers anyway (i wouldn't permit my engineers using such a service).

Ignore the people saying "don't do this" and instead read "Monetizing Innovation" (https://www.amazon.co.uk/Monetizing-Innovation-Companies-Des...) to get some guidance.

It's difficult to summarise the key lessons but you need to consider things like:

* What does having an API allow your customers to do?

* How valuable is that?

* Are they willing to pay for it?

* How do you align payment to the value?

* Is an API considered "table stakes?"

The book I linked goes into more detail so I really encourage you to read it. You can skip over the organisational changes it recommends, just the principles of pricing are good enough for your use case.