Ask HN: How much to charge for an API call?
62 コメント
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.
And segmenting the users: no API access needed no extra cost, low API calls needed (still free tier but with limited quota - useful for you to know and to talk to them) and the big users with said block of prepaid calls (pass them through the free API tier first with a grace period).
If OP takes this approach, please please please make this usage data easily accessible, ideally both as a (free?) API endpoint and as a timechart/table in the web UI if applicable.
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.
How is scraping fish different from a million other services?
When there's a million other services, they don't have to be different. It's like VPNs or burgers. It just has to work and not be too expensive.
Two main differentiators. 1. Pricing. We charge for requests and the cost of each successful request is the same as opposed to misleading API credits system used by others. Also, we sell request pack which are valid up to 1 year as opposed to monthly plans with expiring unused API credits. 2. We use our own high quality and ethically sourced mobile proxies as opposed to shared pools from large proxy providers (https://scrapingfish.com/how-ips-for-web-scraping-are-source...).
"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.
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.
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.
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.
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.
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.
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.
Agreed. If this is a service I'm already paying for and if it's basically just doing 'CRUD' actions that are (hopefully) low in resource usage I'd be really uncomfortable with a pay-per-use model. Rate limiting sure, but I don't want another thing I need to price in my head as I'm writing code.
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?
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.
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.
> If you're using the API yourself it means the cost of building is complete
Opening up an internal API with a know client that you own to the whole world introduces more complexity around authentication, rate limiting, traffic inspection, etc, that OP probably doesn't need to worry about now.
Opening up an internal API with a know client that you own to the whole world introduces more complexity around authentication, rate limiting, traffic inspection, etc, that OP probably doesn't need to worry about now.
cost of building is definitely not the cost of operation
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).
Do you block your engineers from using S3 or other cloud services?
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.
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.
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.
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.
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.)
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.
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.
Abusive? I know that HN has a very pro FOSS culture, which, with some users, seems to extend to the expectation that companies and products should exist out of the goodness of developers’ hearts. But charging willing users for an API that costs money to maintain is “abusive”?
> I know that HN has a very pro FOSS culture,
Err, what? I don't think we've read the same thread. It's shock-full of people trying to justify this kind of behaviour, presumably in a vain effort to feel less bad about their own abuses.
> seems to extend to the expectation that companies and products should exist out of the goodness of developers’ hearts.
Corporate shills and bootlickers seem to have this weird misconception that companies and products just naturally deserve to exist and impose themselves on society.
> But charging willing users for an API that costs money to maintain is “abusive”?
The API already exists.
Err, what? I don't think we've read the same thread. It's shock-full of people trying to justify this kind of behaviour, presumably in a vain effort to feel less bad about their own abuses.
> seems to extend to the expectation that companies and products should exist out of the goodness of developers’ hearts.
Corporate shills and bootlickers seem to have this weird misconception that companies and products just naturally deserve to exist and impose themselves on society.
> But charging willing users for an API that costs money to maintain is “abusive”?
The API already exists.
You absolutely should charge people for access to their data. What do you think paying for s3 retrievals or db queries are?
But s3 retrievals cost money regardless of if you use the API or something else. You don't pay extra you use the browser vs uploading through their UI (not that anyone uses their UI).
Charging users to use an API when you don't charge them to use the website is _pretty bad_. If it's B2B, they might just suck it up and pay. But if it's B2C, don't be surprised if someone makes an "unofficial API" that's free.
Charging users to use an API when you don't charge them to use the website is _pretty bad_. If it's B2B, they might just suck it up and pay. But if it's B2C, don't be surprised if someone makes an "unofficial API" that's free.
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.
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.
- 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.
But offer a very high rate limit.
Your base price should include calls.
Don't bill people $5 + $.37 for low traffic.
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.
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%
You are worth more than that!
That's impossible to determine because the units don't match.
Your market worth is your labor and skill, almost totally separate for how much you pay your robots. Low margin x high scale is as good as high margin x low scale. High margin at high scale doesn't exist outside a monopoly.
Your market worth is your labor and skill, almost totally separate for how much you pay your robots. Low margin x high scale is as good as high margin x low scale. High margin at high scale doesn't exist outside a monopoly.
Not always.
$1 per call.
ergonaught(7)
My app users want to pull/edit data of their customers using the app API (which is the same that I use internally).
I wonder how much I could charge for those looking for an API key. Maybe $5 + 0.001 per call?
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.
Thanks