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
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 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.
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.
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.
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.
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.
Who are your customers?
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
- 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.
But offer a very high rate limit.
Don't bill people $5 + $.37 for low traffic.
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 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.
