Monetizing an API in large organizations is like vices amongst teenagers: They talk a lot about a given vice, but very few are actually doing it. Put yourself in any large and well-established organization which has published APIs and you’ll find something similar with monetisation. Unless that organization is API-first there is constant talk of how to “sweat” APIs to get some return on their investment, but very little success in making it happen.
The reason for this - in the vast majority of cases - is simple. To be able monetize your APIs you need:
- A product customers want.
- A reason for them to pay for it.
- A way to bill them for it.
In organizations that are not API-first it can be very difficult to make these 3 things stick. There are of course other ways of making APIs pay, often called “indirect” methods. In this case the API is part of an existing product-offering without a “per-call" charge or charging allocated internally. These are all good means of monetization, but lack the commercial “wow” factor that so many business leaders look for when signing up to an API monetization initiative.
Being successful in paid-for APIs (often called “direct” monetization) therefore comes down to a number of factors:
- Creating products that resonate with market needs.
- Having buy-in from the business to get an API to market.
- Have the means to collect payment.
Getting these right gives you the best chance for making money from your APIs. That first point is critical, and one often overlooked.
Get the “Business” Onboard
Let's face facts: APIs are still largely a technical "thing". You as a technical leader in your organization understand their value, but sometimes it is difficult to communicate it in a way that resonates with business leaders.
If you have a good product idea the first step to bringing it to market through APIs is to ensure you have buy-in from the "business" and that they fully support your endeavors. It is very common in large organizations for API-related product ideas to come from the technical community and there is a temptation to charge ahead with developing both the product and the API without clearly presenting the benefits.
You may think that this step is unnecessary but the truth is that your product and API relate to a budget line somewhere in your organization. Unless you are able to clearly articulate the product and its implementation as an API your project is likely to be first against the wall when cost- or scope-cutting happens.
Wedding the API to a budget line therefore may take some creative thinking, but key to success will be selling the idea in terms of financial outcomes. A business plan with clear goals on costs and returns is vital to getting this kind of buy-in. The benefits have to be clear. Remember you will be competing with many other interests and the immediate return on bringing the product to market may be a drop-in-the-ocean compared with other, non-API related initiatives.
Describe the New Market
Key to success is therefore getting the language right and communicating the target market effectively. Many products that are brought to market as an API often address a new customer base that is not understood by the business. Taking the classic example of Twilio and its impact on traditional telecoms equipment manufacturers, if product leads at Cisco could have articulated API-driven communication networks to the business leaders they would not have taken so many years playing catchup in that space.
You must therefore ensure you clarify the audience from the outset, and couple this with your business plan for the product. Teaming these 2 items up will provide a commercial use case that the business can understand in terms of both income and reach.
Avoid Cannibalisation
While a commercial use case will help your cause, so many great ideas (at a technical level) fall flat when presented to business stakeholders simply because technical people do not always have insight on what makes businesses tick.
An example here lies in financial services and access to lending products. The vast majority of large banks offer products that could theoretically be offered via APIs to product aggregators, with a variety of charging profiles for monetising access. However, many banks choose not to do this - or only offer access to select partners - as it undercuts the existing brokerage teams in the bank itself and the channels the bank controls to offer the products. The view of the business stakeholders therefore trumps the product leads for delivering new APIs to the market.
It's avoiding this kind of scenario - and wasting time on product development and prototyping - that will make your efforts a success. Your idea has to stand-up on its own and avoid conflicts-of-interest with existing business functions.
Listen to Business Ideas
However, many products that are manifested as APIs start life in a solution architect's head and are "sold" back to the business. This engagement is a two-way street. You must be ready to accept input from the business that needs "translation" to an API way of thinking.
Key to this is thinking about the audience. Many businesses focus primarily on the needs of their existing customer base. That thinking can be "stretched" to include new customers in scenarios that the current stakeholders have not even considered.
Monetisation can therefore be as much an exercise in stakeholder management as it is product development. The best ideas for new products delivered through APIs may be the ones someone else has already had that are "tweaked" to incorporate the new audience. Taking this approach will ensure you always stay on someone's budget line.
Have a Market-Ready Product
You've got the business interested - or maybe they have got you interested - and the next step is to ensure you have the means to deliver your API as a paid-for solution. You may have taken products to market already but taking one of them to market as a ready-to-roll API to be consumed by a new customer base can be more complicated than it first appears.
Clearly Describe the Product (and API)
Your organization may have many successful products in the market already. However expressing the key selling points of your new API can be a different proposition.
You need to describe it at a number of levels:
- Define the "product headlines" that can easily be rationalized by the reader (whether they are technical or not).
- Make the transition from the headlines to the details as seamless as possible, allowing either a technical person to quickly jump into them or a non-technical person to direct someone else with the right experience to point them in the right direction.
You could do worse in your approach than to follow the style of Stripe in their documentation. They couple simple statements that get straight to the point - "Build a web or mobile integration to accept payments online or in person." - with more detailed information accessible by a button-click.
It is important to take this activity seriously and not simply "leave it to developers" to try their hand at writing product-related documentation. Employing an experienced technical copywriter - ideally with experience in APIs - is critical to success. Ensure they come up with product headlines that give both a general summary of the product that can lead instantly to more detailed information.
Make Your Product Billable
Great documentation obviously goes a long way in attracting people to your product and if it's what the market wants they'll be willing to pay for it. With this in mind you'll need to decide on how you are going to charge customers and work out appropriate price profiles. There's a number of options:
- Charge "per-call" at a flat rate.
- Offer volume discounts on a tiered basis.
- Bundle the product with an existing billing line, with an API usage fee.
However you choose to price your product ensure that it is clearly communicated in your documentation. Leverage your copywriter to clearly articulate what and how your customers are paying for using your API. The choice should obviously be reflected in the business plan mentioned above as it will directly affect forecasted returns on taking the product to market.
Create Terms and Conditions
Alongside your billing approach a set of terms and conditions must be ready for your customers to sign-up to. Delaying this is catastrophic from a go-to-market perspective as new customers simply cannot sign-up with the certainty of what they are signing up to.
Getting terms and conditions written and approved can be very difficult in a large organization. Most teams do not have ready access to legal counsel and often the legal team itself is not geared up for creating the kind of terms and conditions that are common in the technology world, let alone the API economy. They will often subcontract this work to "external council" who have the correct skills to draft the document.
Such activities can take an age in organizations with significant numbers of processes and budgeting arrangements. If you need terms and conditions drafted, start the engagement early and ensure you have enough relevant information to fully brief the legal team so they can work start-to-finish.
Have the Infrastructure Ready
With buy-in from the business and market-readiness the last key component is having your infrastructure ready. This can be (for many organizations) the easiest part of monetisation, but for some well-established organizations it can be challenging. It can require significant uplift in the technology stack and changes to the developer experience.
There's a number of areas here to address.
Linking up APIs and Billing Lines
All large organizations will have an existing billing engine that can be reused to bill for your API. If you are going to bill customers using your existing mechanisms you need to ensure that API usage - through acceptance of terms of conditions - is "flagged" by your billing engine so customers are charged for usage.
You therefore need to ensure you can integrate your API. There are turnkey solutions - for example, Apigee Edge Monetization - but such solutions often work in isolation and may not integrate with an organization's existing billing platform.
The most effective means to implement support is to ensure you have your billing-related events sorted, with your portal and gateway emitting events related to usage and changes in status. Regardless of the charging method you must ensure there is a "connection" between your APIs and the billing engine. Many organizations simply overlook this fact, which can result in a go-to-market position where APIs are available but the customer cannot be billed because the billing engine is not "API-aware".
Having your Portal Payment-ready
Reusing the existing billing engine is however not always the answer. Many large organizations enter the API economy with free-to-use APIs or APIs that are coupled to a product that existing customers already consume. Bringing a new API-first product can mean taking on new customers who are not the "traditional" customer base. It may therefore be more pragmatic to charge them in a different way.
In this scenario you must therefore have the means to take and manage payment details through your developer portal. For products that are billed per-call or on a subscription basis this can mean acting like an e-commerce solution:
- You need the means to collect a payment instrument such as a debit or credit card. If this is the first time you have collected such details you need to be aware of Payment Card Industry (PCI) regulations and how to handle and store the card details.
- If you are billing customers on a subscription basis you then need an engine that will ensure customers are billing at the right time with the right payment instrument.
There are a vast number of solutions in the market that can provide some-or-all of these capabilities and have important benefits such as keeping your existing stack outside PCI scope. If you have a public, free-to-use portal then you need to ensure you can provide the means for a user to login and manage their payments and subscription, with the relevant access control to ensure only dedicated users can do so.
Final Thoughts
Monetising your APIs doesn't just happen by magic. You need something to sell that the market wants. That said, if you have something you can offer to the market you still need buy-in from the business, a high-quality and polished presentation of your API and the infrastructure to make sure API calls end up on an invoice or charged to a payment card.
It's therefore worth being ready for anything. Invest your monetisation framework and when the opportunity arises you'll be good to go.