As we’ve previously covered, APIs have much productization potential. But how exactly should these services be monetized? There is an emerging art around knowing how to charge for API calls and how to construct a viable, scalable operational process to support the API business model.

At Platform Summit 2023, Matt Tanner will dive deep into strategies for building your API monetization stack.

According to Matt Tanner, Head of Developer Relations at Moesif, many companies are seeking to drive more revenue amid a slimmer economy and are turning to APIs as a new avenue for growth. Monetizing valuable proprietary services and data, for instance, is an exciting frontier, but it requires the right technology stack to get it done.

Ahead of Platform Summit 2023, we’re chatting with key speakers to learn what they’re working on and to get more background on their upcoming sessions.

Matt has worked as a developer, tech lead, and architect for some of Canada’s largest financial institutions and insurers. At Moesif, he’s been helping developers and product managers understand and use API analytics and new monetization tools.

We caught up with Matt to dig into API monetization, the theme of his upcoming deep dive on building an API monetization stack — a presentation built on two years of working heavily within the API monetization space!

Read on for the interview with Matt below, and be sure to attend the Platform Summit 2023 for more discussion on this topic and plenty of others.

Why is API monetization trending?

Many businesses are now realizing that APIs have a default ability to create a new stream of revenue. Especially with the current state of the economy here in the US and Canada, organizations are looking for any place possible to drive revenue. Certain technologies have also recently emerged which allow API monetization to be implemented more easily. This means that businesses considering it on their 3-5-year roadmap can now implement it much more quickly. This is a key driver I’ve seen as well that has led to this uptick in API monetization popularity.

What types of APIs can or should be monetized?

There are two factors to consider: does the API deliver a valuable service, and are people willing to pay for that? A good example I like to use is for a credit score API. Let’s say I’m a fintech company, and I have built an API that can query multiple credit bureaus and aggregate an overall credit score. This API’s value proposition is that it can retrieve a credit score.

The next question is, “Do other businesses also need this?”. In this case, the answer is absolutely! So, this would be a good example of an easily monetizable API (a term I have apparently just made up). Most companies have a really good idea of their most valuable proprietary APIs — they just need to ask who else may be willing to pay to use that service.

What should prospective API providers consider when choosing their monetization model? (Transaction volume, reve share, data volume, user-centric, resource, etc.)

I think offering multiple models is the best, or at least having the capability to do so. It really depends on the overall business model. For instance, it makes sense to monetize a payment processing API based on a revenue share/percentage model, such as charging 2% per transaction. In this case, it would likely not make sense to charge per API call or per user.

So, understanding what the API does and the most efficient way to charge for it helps uncover which model is best. Often, the limitation on monetization comes from the technology side. An example would be if you wanted to charge based on resource usage, but your metering solution only counts per API call. Then, you’ll be limited to that one model. Finding the right tech will be the biggest hurdle to actually supporting different monetization models.

What goes into constructing an API monetization stack? What are the operational processes to consider?

Anytime you build something, you always want to look at what your landscape already includes. Understand the capabilities of your API gateway (if using one), what limitations a billing provider may have, etc. Once you know what you have, you can figure out what you can build with it. That will help you establish the parameters of what’s possible. In an ideal world, though, you’d first come up with your exact business cases, find the tech to facilitate that functionality, and then implement it from a clean slate.

Generally, as we know, that doesn’t tend to happen. Establish what you need a system to do that will monetize your APIs, then figure out the limitations (ones you can change and those that are immovable), and then implement. It sounds pretty straightforward, but you’d be surprised how many people get 90% of the way there and then realize they #1 can’t use the tech they require or #2 don’t realize the limitations of the tech they’ve chosen to build with.

Are there any anti-patterns you’ve witnessed when it comes to monetizing APIs in practice? How about best practices?

The biggest thing I’ve seen is that people tend to think of monetization in two ways. The first would be to use a subscription model, and the second is to just use a “charge per API call approach”. These are two ways to monetize APIs. However, they don’t necessarily mean you’re delivering value to a customer. And most importantly, it also may mean that you are leaving potential revenue on the table.

The issue with defaulting to a subscription-based model is that aligning value is hard. If I charge $5k per month for API access, regardless of how many API calls or resources are used, then those making the most use of the service will likely be getting the highest while those making the least use will see a major value discrepancy. Tiers can help to offset this disparity but still leave a value gap most of the time.

A way around this is to charge based on usage, particularly per API call. With usage-based pricing, you can get closer to equal value by charging for exact use. The issue is that not every API call is equal.

Going back to our payment processing API example, if I process a $2 payment through the API vs a $2000 payment, but I’m paying the same amount per API call/transaction, the API call for the lower amount may have a value issue that pops up. If the price per API call was $1, then they are looking at a 50% fee versus a $1 charge against the $2000 payment, where the fee is substantially lower compared to the amount of money transacted. In this case, you’d want to pick the model that is fair to customers and drives the most revenue internally.

For best practices, putting my software architect hat on, I suggest questioning every single scenario and mapping out edge cases. Most platforms that help with monetization can do the simple stuff well, but the edge cases become infinitely more complex to handle correctly. Since every API monetization initiative will be pretty custom, good planning is the key to success.

Why are you looking forward to the Platform Summit 2023?

I’m very excited to see the different opinions and folks within the API community. I’m also excited on a personal level to visit Sweden for the first time. I think the collective knowledge that will be at this conference will give me some great insights, and I’m also excited to share my knowledge with others as well.

What do you hope attendees will take away from your talk?

I hope attendees will see that API monetization is hard but worth it. Many companies I talk to struggle to figure out where to start. This talk will give them a solid foundation of the business fundamentals and all of the technical considerations. Hopefully, our learnings at Moesif over the last two years will benefit others as they strive to monetize their APIs effectively.