It’s the number one question for many CDOs, CTOs, and CEOs: how do I drive adoption and revenue through my API initiatives that will justify the investments I have made or am planning to make?
In many cases, this revenue goal gets directly translated to “pay per use” as part of a loosely defined monetization strategy around the available API products. But as with any product strategy, the pricing itself is just one aspect of the product definition.
“Just slapping a price on an API is not enough to ensure adoption in the market. The key to driving revenue in an API marketplace is to offer value to developers and give them a reason to use your API over others.”
Let’s take a step back and start with some of the fundamentals.
What is an API product or digital product?
Much like the definition of a product in general – an article or substance that is manufactured or refined for sale – an API product is a combination of one or more API resources, representing business value that aligns with the needs of your target audience(s), in a way that makes the discovery and usage of said artifacts attractive and easy.
I shared a framework for understanding API products and how they need to be packaged in a way that makes sense for your target audience during a recent webinar on organizing APIs for business value.
Dive deeper with this blog to help distinguish API product, product API, and “API as a product.”
In the drive towards revenue, having a product mindset as part of the revenue strategy for your APIs is key as it helps to (re)orient on a few essential aspects:
Purpose, value, and experience
In order to drive adoption and revenue, a product must solve a problem that is worth solving.
This requires a shift from an application to a business-oriented mindset around the development of products and product plans. Think for example of an integrated payment solution versus an API to request an invoice status.
Maximize exposure and connect with your audience
Make it easy to find/discover content. Curate the content you offer, tag, and categorize. Provide extensive documentation, and not only technical documentation.
Reduce friction when it comes to onboarding and consumption
Offer entry/trial plans to get your users “hooked.” More generally, make it easy to subscribe to, pay for, and use the content. Offer the ability to use and share subscriptions.
Minimize cost and effort for both the provider and the consumer.
What this comes down to is reducing the time to first API call. Self-service is an essential part of delivering at scale and providing the agility your customers are looking for. Make sure you can serve your enterprise customers by allowing an easy integration in their development and delivery processes.
One example of this was when a leading pharmaceutical company made the shift from standalone APIs to easy-to-adopt digital products — bundles of well-documented API assets that address specific business needs.
“One of the biggest impediments to delivering quickly on new use cases was our centralized approach to digital service development,” explains a spokesperson. “All requests passed through the enterprise data team and the standard methodology was to build custom data interfaces for each use case. This created a significant bottleneck, which led to delays in delivering digital products to the business.”
Moving to centralized governance with an API marketplace helped transform the experience for consumers, giving developers more time to work on building, validating, and deploying new digital products.
Read the full case study here.
Example of an API product
To make the product concept a bit more tangible, let’s take a financial institution as an example.
Over the years, the teams of this organization have built a large swath of APIs, all geared towards direct integration with various systems and financial functions, such as:
- Account information
- Account aggregation
- Account balance
- Account statements
- Account validation
From a customer perspective, you probably would like to get access to all these account services together, so it makes sense to package all of these into a single product named “Account services.” You could even further integrate it as part of a more comprehensive bundle of APIs for a particular audience, e.g., Small Business Banking, with appropriate consumption plans.
Apart from the logical bundling/grouping, you want to make sure the created product speaks to your target personas, from initial search and discovery to buying and usage.
To be able to do so, you need to package them up as a product, with documentation and tailored access plans, allowing your users to get access to the content they need through a single subscription. This also simplifies management of access to the various underlying resources in a single place for the provider.
API monetization strategies
Many organizations see API monetization as the ultimate goal they are working towards and a validation of the success or maturity of their API program.
This is not surprising as many (analyst) API models refer to this as the most mature stage – phrased in different ways, but all referring to ways in which APIs have become an essential part of the business strategy and a representation or manifestation of “how we do business.”
When monetization is being considered or discussed, many API teams gravitate towards the implementation of a direct (i.e. pay-per-use) API monetization model as a first reaction. The reality is that this might not be the right fit for their business, or it may not be a practical reality given the audience or nature of the provided service.
Before we dive deeper into this, a quick recap on monetization strategies. How to monetize APIs can be roughly divided in four categories, based on the audience and the monetization approach.
This initial categorization will provide a first guidance on what model is most suitable given the audience and provided service. Although all combinations are possible, direct monetization is most often applicable in a setting with external consumers and less likely in internal scenarios.
See also: 3 steps for API monetization
The role of API products
Aside from the audience, the role of the offered digital product is an important factor in the decision around the right monetization strategy. Let’s have a look at a few scenarios:
API is the product
When the API is the product, direct monetization is a viable and likely option. Examples in the market are Stripe, Twilio, and Mailchimp. These products do provide extensive capabilities to integrate with other services through APIs and access to these capabilities is metered and limited through consumption plans.
Suggested API monetization approach: direct
API is a product feature
In this situation, the APIs enrich the functionality or experience of a product, e.g., allowing the product to be integrated into other applications or services. An illustrative example here is the ability to integrate your music subscription service into the application that controls your wireless speaker setup.
The typical nature of this application is that the APIs are not directly monetized, although there are situations in which access to these APIs is reserved to specific (more expensive) consumption plans.
Suggested API monetization approach: indirect or direct (situational)
API is an adoption channel
This is a very common pattern for various large enterprises and e-commerce platforms, like eBay and Etsy, allowing the integration of its services into existing customer journeys. In these cases, the API is not the product, but APIs are a path to the service to drive sales.
Most consumers have experienced this pattern in various ways, e.g. allowing them to get insurance or financing for the product they are about to purchase, completely integrated in the experience of the e-commerce platform they are interacting with.
Suggested API monetization approach: indirect
For more API monetization use cases, see also “5 ways enterprises are monetizing APIs.”
How do I monetize APIs and digital products?
Assuming the product definition, target audience, and monetization model have been defined, we can start to focus on the right subscription model(s) to offer. This is a whole subject by itself, and we will be publishing a separate blog with more details on the various options soon, but the most common options we see are the following:
- Pay as you go (unit-based)
- Standard usage plan (plans with a single usage limitation)
- Fixed fee (single subscription fee, no usage fees)
- Tiered plan (different usage rates within a single subscription plan, based on usage)
Each option comes with a number of base characteristics and pros & cons, depending on the application. Some of the factors that play into the offered options are: the maturity of the specific market, the cost structure, competitive factors, consumer profiles, uniformity of the user base, and the predictability of usage.
Imagine for example a brand-new service, for which you are trying to drive initial adoption. A pay-as-you-go plan might be attractive, but if the expected usage is unknown and could be volatile, a fixed fee option might be preferable to help with initial adoption to mitigate the customer’s uncertainty.
Join us for a webinar on adding an API digital products tier for faster development and greater revenue.
How does a marketplace help grow digital product revenue?
While moving from an internal collaboration focus to an external business orientation, the requirements and involved stakeholders change, both on the producer and the consumer side.
The traditional approach with one or more developer portals does not typically provide an adequate answer to the growing needs in this area, including but not limited to:
- API as a product
- Lifecycle management
- API monetization
- Subscription management
- Credential management
- Quota management
Most API developer portals have been designed around the developer as the primary or only persona, and that is reflected in the overall experience: with a primary focus on facilitating technical access and collaboration.
By design, portals primarily cater to the exposure of individual application APIs, not digital products, with an inability to curate/bundle APIs. This makes it hard to accommodate the inclusion of other artifacts – including non-technical documentation and providing monetization options as an afterthought – often constrained by the generic CMS plugins the portal has been built on top of.
The result is a sub-optimal experience, for both your internal and external users.
As with any product, the moment a digital product has been published for consumers to subscribe to, you need to manage the lifecycle of this product properly, including the underlying resources, consumption plans, subscriptions (including quota enforcement and invoicing), and issued credentials.
This requires a different, elevated approach, allowing you to cater to all involved stakeholders and address additional requirements.
This is where an API marketplace will make the difference: it has been developed with these personas, capabilities, and usage patterns in mind, not as an afterthought in a single persona-oriented developer portal.
As David Geiger, Head of API Management at Bosch Digital, puts it: “With Amplify Marketplace, there’s no need for developers to traverse the whole organization trying to find the right API; it’s going to save a huge amount of time.”
In the following video, William McKinney, Senior Director Platform and Solution Marketing at Axway, describes how an API marketplace can be more developer-friendly and cater to its customers’ needs.
Read also: 5 reasons companies are adding API marketplaces to their API portals
How does Axway’s Amplify Enterprise Marketplace help?
Most organizations do not have a single API platform, but rather multiple platforms, and they’re leveraging more than one API pattern, including REST, events, streams and integration flows. These API platforms typically span multiple clouds and originate from multiple vendors.
With this being the reality, you don’t just need a marketplace, you need a federated API management platform, that allows you to create a unified experience for both your consumers and producers over this divergent API landscape.
That’s where Amplify Enterprise Marketplace comes in. One unified experience for both your producers and consumers. All your APIs in one place. Agents automate the discovery and updating process for each of your data planes. Monetization just requires configuration. Easy customized branding capabilities make it yours.
Learn more about how an API marketplace can drive value for your business in our eBook.