Bruno Pedro on API monetization models in action
/
Bruno Pedro has been building open source and commercial applications for more than 20 years, with more than a decade as a Web and cloud computing technologist. His newest startup Hitch is a platform dedicated to API owners enriching their developer community.
Let’s be serious, this is called The API Economist because we look at the application programming interface or API as a way to make money. But time and again, particularly in the business software space, we’ve seen companies just creating an API, without making it a part of their overall business strategy. Because, when it comes down to it—whether you’re charging by call or subscription, creating stickiness or working toward an upsell—your API, like anything you do, should support an overall business strategy. We snagged API integration expert and startup cofounder Bruno Pedro to help explain the different ways you can monetize your API and, thus, your business model as a whole.
Editorial Note: When Bruno refers to “app” throughout the piece, he is talking about it in the more general sense, meaning for both mobile and the Web.
API Economist: How about we start by you telling us a little bit about your background in the API economy.
Bruno Pedro: I've been working in the API space for about ten years now. I started with SOAP and Web services and quickly ended up doing a lot of integration work for different sized businesses.
I created and then sold one of the first startups to deal with complex integration between APIs in a user-friendly approach. Tarpipe, a predecessor to IFTTT and Zapier, was created in 2008 and sold in 2012. I also created APIUX for API User Experience, including drafting the API Hierarchy of Needs and the API Automation Value Map.
Now I’m the co-founder of Hitch, a single platform to help API owners engage with and grow their API community.
How do you define API monetization and how does it fit into your world?
API monetization is the process of finding a suitable business model for your API. Like any other product or service, monetizing an API is all about understanding who should pay for using your API, why they should pay and under what terms.
And then sometimes you can monetize your API indirectly, like by excluding API access from certain payment plans.
Tell us about the main models of API monetization.
There are other options and multiple variations but inclusion, independence and incorporation are probably the best models for you to consider.
The Inclusion Model is when you offer unlimited API access with all your app’s payment plans. API access is considered free but to access it you must subscribe to one of the paid plans. This is probably the easiest to understand model and can offer a direct, easy-to-measure metric: increased MRR [monthly recurring revenue, usually in Software as a Service or SaaS market].
The Independence Model is all about making the API a second product, independent from your app paid plans. With this model you offer paid API access, either using a pay-as-you-go strategy or associated to certain usage limitations. With this model you’ll gain a secondary revenue stream that will be easy to measure and improve.
The Incorporation Model is a way of extracting specific value from your API and making that available in certain app paid plans. It can be as simple as making the whole API available just for users that subscribe to higher priced plans or as sophisticated as making specific API resources available on specific plans.
For the Inclusion Model, attribution can be tricky with general MRR metrics, can’t they?
The point here is not about attribution. If the API is unlimited and included in all payment plans, then the easiest metric is MRR.
How best can you monetize an API?
It depends on your app or product. At the end of the day, what you’re looking for is an increment on your revenue. You’ll need to measure how you obtain and produce value and how you can make the API part of that value chain.
If your product is free to use and you obtain value from user-generated content, you’ll probably want to open your API as a way to get more users pushing information into your app. If you’re primarily selling information, you’ll probably want to charge for API access. There’s no clear formula—you should treat your API as a product from a business point of view.
How are API-based business models different?
It’s a model where the API is the product. The easiest example is the telephony industry. Companies that sell voice call infrastructure usually do it by opening an API that lets developers configure how they want the service to operate. End users don’t use or care about this—they’re the customers of the final apps, while the API consumers are your customers.
How do you measure the success of an API program? How do you set key performance indicators [KPI]? What sort of tooling do you use for it?
I’d say the success depends on your business model. If you follow the Independence model then the best KPI would be MRR—monthly recurring revenue. Other models have their own KPIs but I’d recommend paying close attention to Expansion MRR coming from customers with API access—the inclusion model—and also from specific paid plans—the incorporation model.
If you’re not monetizing your API, you can measure success by seeing how your product revenue is behaving and relating that behavior to your API usage over time. If API usage increases and you see an increase in your product MRR then it means that your API program is doing well.
Reporting can be done using any tool that lets you extract subscription information and calculate MRR and churn. A good example is ChartMogul a service that connects to Stripe and other payment gateways and automatically generate the reports for you.
But couldn’t this be the other way around? Correlation is not causation.
Absolutely, and that would also mean success for your API program. The goal here is to identify growth in both your API usage and your MRR.
What about an API-based customer acquisition channel (CAC)? How much do you usually recommend charging per API call? Is there an average?
APIs can be used as acquisition channels pretty much the same as a referral channel operates. I don’t recommend charging per API call if you plan on following this strategy unless the value you provide through the API is much higher than the value you provide through your app.
You can see an API customer acquisition channel as a way to indirectly obtain more users to your app—and more customers. Users won’t be joining your service directly through the API. Instead they’ll probably find another app that uses your API and start using it for some specific reason. If that app is good enough, they’ll stick around for your service and will eventually end up paying.
Is the stickiness created by an API enough to increase retention rates? Do you have any numbers to prove it?
I don’t have any numbers but I’d say that the more your app is integrated with other apps the harder it will be for users to quit. The idea is that your “whole product” will be a combination of features developed by yourself plus a number of integrations with other APIs.
How does API monetization fit with your company Hitch?
At Hitch, we look at dozens of APIs every day and we can see how sometimes they change their approach to monetization. From the feedback we’ve been getting while designing our own product we now understand that our own API will probably be monetized using the “Incorporation” approach as described earlier.
What will the API economy look like in five years?
I’m not a fan of predictions but I’d say that five years from now APIs will be ubiquitous. Everything you see and use will somehow be connected using APIs. It’s not hard to imagine that APIs will be somehow like electricity is today: always present but invisible.
What should a developer be doing to prepare for the future of the API economy?
Automate as much as possible—API client and server development, documentation, testing... Or work as little as possible. [winking]
What are your three favorite apps? (Not the ones you like the most, the ones you really use the most.)
If I had to choose one I'd go for Postman. I spend almost all day using, testing and documenting APIs and Postman clearly solves my problems.
Most of my time is then spent inside a Terminal, going back and forth between testing APIs and actually writing code using the vi editor [visual editor].
Other than that, I spend a lot of time inside Gmail and I do use a lot of plugins to automate and control a bunch of things.
Who is the must-follow, undercover API expert on Twitter?
Not so much undercover but @apihandyman is definitely a must-follow.
Do YOU have more API monetization tricks? Or perhaps a follow-up question for Bruno? Keep the conversation going in the Comments Section below and on Twitter @APIEconomist and @BPedro!
