Pricing for API Access
July 30, 2019 8:24 AM Subscribe
What are some typical pricing structures for granting access to an API that serves up a customer's data?
I work for a SaaS that that stores records for our customers. Based on customer demand, we're building out a REST API to allow them direct access to this data outside of the application.
That part is pretty straightforward. As a business, we're struggling to figure out what (if anything) we should charge for use of the API. I'm trying to do some research to find how other companies handle this, but I'm not finding much.
Some ideas that have been discussed:
1. Flat yearly fee
2. $/seat structure (not necessarily different from #1, just structured differently)
3. $/unique token structure.
4. Tiered access based on # of queries/rows returned
Any stories of how others have handled this, or links to pricing structures other companies have in place would be greatly appreciated!
I work for a SaaS that that stores records for our customers. Based on customer demand, we're building out a REST API to allow them direct access to this data outside of the application.
That part is pretty straightforward. As a business, we're struggling to figure out what (if anything) we should charge for use of the API. I'm trying to do some research to find how other companies handle this, but I'm not finding much.
Some ideas that have been discussed:
1. Flat yearly fee
2. $/seat structure (not necessarily different from #1, just structured differently)
3. $/unique token structure.
4. Tiered access based on # of queries/rows returned
Any stories of how others have handled this, or links to pricing structures other companies have in place would be greatly appreciated!
Best answer: Twitter's API is pretty widely used and worth checking out. They have a free sandbox tier, have recently introduced a dev API tier with a few different options depending on calls you make monthly, and then they have an enterprise tier which will run your org at least 100k/year (they're not transparent about pricing on their website for enterprise).
posted by shaademaan at 8:53 AM on July 30, 2019
posted by shaademaan at 8:53 AM on July 30, 2019
Don't forget option 5 - free. Several of the SaaS products I use at work just consider offering an API as part of the cost of doing business. What we're paying for is what they do on the backend. Whether we access it through their website or API doesn't affect them very much. There's a little overhead of offering a public API as far as developers but not enough for them to try to do cost recovery on just the customers that use it. They do, however, have professional services fees for helping you with the API if there's something we're having trouble with that's not a bug.
The big thing I'd do is look at your competition and see what their pricing model is.
posted by Candleman at 9:18 AM on July 30, 2019 [6 favorites]
The big thing I'd do is look at your competition and see what their pricing model is.
posted by Candleman at 9:18 AM on July 30, 2019 [6 favorites]
You should be asking this on hacker news or somewhere like that, not here, but oh well.
The fundamental thing you should be thinking about if you're providing a service to people is what problem you're solving and how much it's worth to them. Assuming you have that answer for your regular product, you should be able to see how providing an API fits into this model - is it a fundamental part of your offering? Is it a nice-to-have? Is it important for heavy enterprise users but not for casual users? Once you know that you should be able to work it into your existing pricing structure.
In turn, once you know that you can decide whether or not it's worth doing. Just because customers are asking for it doesn't mean it's a good idea - are you going to have to staff more oncall to handle it? Is it going to increase load on your system dramatically if they hit the API once a second? Are they going to automate away the value they're getting from your service?
posted by inkyz at 10:30 AM on July 30, 2019 [1 favorite]
The fundamental thing you should be thinking about if you're providing a service to people is what problem you're solving and how much it's worth to them. Assuming you have that answer for your regular product, you should be able to see how providing an API fits into this model - is it a fundamental part of your offering? Is it a nice-to-have? Is it important for heavy enterprise users but not for casual users? Once you know that you should be able to work it into your existing pricing structure.
In turn, once you know that you can decide whether or not it's worth doing. Just because customers are asking for it doesn't mean it's a good idea - are you going to have to staff more oncall to handle it? Is it going to increase load on your system dramatically if they hit the API once a second? Are they going to automate away the value they're getting from your service?
posted by inkyz at 10:30 AM on July 30, 2019 [1 favorite]
Best answer: Keep in mind that free means more people will use it and therefore you'll have more demands for support and development. I am a librarian who uses API's in various ways and any fee, no matter how small, means a lot more paperwork and justification in order for me to use it. Not saying you should or shouldn't charge for your API, just that the decision to charge is going to depend largely on the amount of staff time you want to throw at it (and whether or not the costs will recoup that time).
posted by rabbitrabbit at 11:11 AM on July 30, 2019 [2 favorites]
posted by rabbitrabbit at 11:11 AM on July 30, 2019 [2 favorites]
If pricing is not based on usage, or if the service is not strictly rate-limited, it is guaranteed somebody will write a busy loop that polls your service as rapidly as possible. Even if it doesn't make any sense for them to do this, they will.
posted by qxntpqbbbqxl at 2:01 PM on July 30, 2019 [4 favorites]
posted by qxntpqbbbqxl at 2:01 PM on July 30, 2019 [4 favorites]
If you're already selling a service that you believe is priced right, then I recommend that you either make it part of the offering at no extra charge, or consider charging the "power users" who want access via the API an small extra bump on top of what they already pay.
Also, always be rigorous about the basics before you release. Rate limit both by volume and by rolling per-second rate, use secure API tokens using a well-documented encryption routine, as well as an industry-standard auth protocol such as OAuth2 or SAML, etc...
In my own work, I've never worked for a company that charged separately for web vs. API access. But, YMMV - you know your customers and situation best.
posted by Citrus at 6:37 PM on July 30, 2019
Also, always be rigorous about the basics before you release. Rate limit both by volume and by rolling per-second rate, use secure API tokens using a well-documented encryption routine, as well as an industry-standard auth protocol such as OAuth2 or SAML, etc...
In my own work, I've never worked for a company that charged separately for web vs. API access. But, YMMV - you know your customers and situation best.
posted by Citrus at 6:37 PM on July 30, 2019
My feeling tends to be that if it's our data and I'm already paying you to handle it, and you aren't making it accessible yet in a convenient way, you better treat that as a long requested feature you've finally added and not as a new product line I should be excited to pay a lot for.
So practically speaking I love free, don't mind a per-developer seat license, could conceivably live with a flat fee that's a small increase on my current payment (say 10% or less, for the sake of discussion.)
I hate per-query charges because of their unpredictability for the types of projects we do, and the weird incentive that if we do a good job rectifying the deficiencies in your current interface and everyone migrates to our internal solution, we pay a lot more than if you were a good fit in the first place. Tokens aren't as bad, but there are classes projects where they'd be a bad fit.
Any significant charge, regardless of the structure, will make me expect up-to-date documentation, customer support, appropriate feature sets and other things I've found vendors often under-resource when trying to sell their new API collection to me.
(For context, I'm generally doing things that in the old days we might handle by moving around big files or doing a nightly or even weekly ETL from your system. I'd adjust expectations if you are providing more than that, like actual computational power or super-real-time-"big"-data-from-multiple-collection-points or something.)
posted by mark k at 8:34 PM on July 30, 2019 [2 favorites]
So practically speaking I love free, don't mind a per-developer seat license, could conceivably live with a flat fee that's a small increase on my current payment (say 10% or less, for the sake of discussion.)
I hate per-query charges because of their unpredictability for the types of projects we do, and the weird incentive that if we do a good job rectifying the deficiencies in your current interface and everyone migrates to our internal solution, we pay a lot more than if you were a good fit in the first place. Tokens aren't as bad, but there are classes projects where they'd be a bad fit.
Any significant charge, regardless of the structure, will make me expect up-to-date documentation, customer support, appropriate feature sets and other things I've found vendors often under-resource when trying to sell their new API collection to me.
(For context, I'm generally doing things that in the old days we might handle by moving around big files or doing a nightly or even weekly ETL from your system. I'd adjust expectations if you are providing more than that, like actual computational power or super-real-time-"big"-data-from-multiple-collection-points or something.)
posted by mark k at 8:34 PM on July 30, 2019 [2 favorites]
I've worked for a enterprise software company that provided data access APIs. Like Candleman mentions, we provided these for free, as part of the web application itself. I think any user that the client designated as an admin could generate an API token.
I'd say less than a dozen of our customers, mostly the biggest and most technically competent ones, used the APIs. The biggest problem we had was accidental abuse. We were fine with "reasonable" usage scenarios, and were committed to supporting those. But sometimes clients would constantly pull data without caching, or try to pull years of records at once, and it would affect overall system performance. In those cases we'd check our metrics to see who was doing it, temporarily lock them out if needed, and one of our Professional Services folks would give the client a call. In our industry, customer relations were cordial enough that we usually got an apology or at least some questions about what they should do differently.
I think we looked at it as a required feature for retaining and satisfying large, sophisticated clients, and keeping their data stored with us. In some cases we may have charged a client to add API features they needed, as a custom development project.
posted by serathen at 10:38 AM on July 31, 2019 [2 favorites]
I'd say less than a dozen of our customers, mostly the biggest and most technically competent ones, used the APIs. The biggest problem we had was accidental abuse. We were fine with "reasonable" usage scenarios, and were committed to supporting those. But sometimes clients would constantly pull data without caching, or try to pull years of records at once, and it would affect overall system performance. In those cases we'd check our metrics to see who was doing it, temporarily lock them out if needed, and one of our Professional Services folks would give the client a call. In our industry, customer relations were cordial enough that we usually got an apology or at least some questions about what they should do differently.
I think we looked at it as a required feature for retaining and satisfying large, sophisticated clients, and keeping their data stored with us. In some cases we may have charged a client to add API features they needed, as a custom development project.
posted by serathen at 10:38 AM on July 31, 2019 [2 favorites]
« Older After the colonoscopy: transit & food | Am I saying more than I want to with this flag? Newer »
This thread is closed to new comments.
posted by jquinby at 8:35 AM on July 30, 2019