Ask HN: How much to charge for an API 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.

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.

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.

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.

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.

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.

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.

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?

Without more detail I would respond as a customer and builder:

It is my data - if I am paying for a service already the idea of paying more to access my data differently is unattractive.

If you're using the API yourself it means the cost of building is complete so there is no additional cost.

How often are the users, power users, abusers going to access the API?

I am thinking either charge more for your service and include it and add rate limiting, authentication, 2FA, etc to add some friction.

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).

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.

This shouldn't be charged per API call, you should look at an average of API calls per person - and create a figure 20% above that of what you want to earn.

Alternatively, charge x per month - with a cap of a certain amount of API calls.

The problem with charging per API call is that what do you class as an API call? What happens if a network degrades and the response hangs? Should the end user pay for this? What if they get a 404, or a 401/403? Should they be charged for these?

As your application stores customer data that they own, I could price based on how many records they are storing - not how often they want to access their own data.

I have done pricing for multiple AWS services and while many people may be against the per-call pricing model of AWS, I would recommend you do a detailed costing of your service first.

Start with initial assumptions, like amount of customer data eat and then base your calculations on how much data is being requested. You will also get a deep understanding of how your system scales and where the cost really lies. For example, even for a simple crud app running in AWS, you can pretty detailed on your costing. Like how much IO you will consume from RDS per million queries etc.

That will tell you what your margins can be.

Meter based pricing works well if that is your main stream pricing model. If you are charging a subscription fee, then you should consider including a certain number of API calls in the subscription bundle. for API gateway products like AWS API gateway, tyk and otehrs, the API request based pricing is main stream. If you think API call on your platform is part of the core value, then you should consider including it in the subscription fee. If you think API call is a value added service, then you should consider charging it separately.

It depends on a lot of things:

a) Your business model Is the API your primary source of revenue? Something you'd be willing to lose money on in order to drive revenue somewhere else? You need to think about how it fits into the overall strategy of your business.

b) Your costs How much will this API cost you to setup, operate, and maintain? You need to think about how much you'll make/lose at different price structures and different volumes.

c) How the customer will use it Will they be looking to make 1 query a year? A million an hour? Probably somewhere inbetween of course, but that will make a big difference in terms of how to price it.

d) How much value does the customer get If using this API saves the customer $1 million in costs, you should make sure they are paying you at least $100k. If it saves them $10 in costs, make sure you aren't charging them more than $10. And again, you need to think about how much they are going to pay in total, thinking about how many calls they are making of the course of a day/month/year/etc.

... I'm sure I'm missing some. But the point really is, there is no right answer unless you think carefully about your product, customers, and strategy.

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.

What an entitled question. I think it's worth going back and questioning the priors that even lead you to ask it in the first place.

How much do you charge when people perform the same action in your UI? (I'm going to go out on a limb and guess $0.)

Is the data you're trying to hold hostage yours? (No.)

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.

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.

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.

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.

$.30 per API call, but throw in free nights and weekend calls.

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.

On a related note, is it a good idea to sell access to the same API your app is using under the hood? Why or why not?

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

Depends on the value of the product. Is your API doing the work of a full time employee?

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

But offer a very high rate limit.

Your base price should include calls.

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

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.

Your cost plus 20%

$1 per call.