When planning to launch monetized API products, clients often consider opening up their developer portal to create a marketplace, allowing the owner of the marketplace as well as third-party developers to publish APIs that can be consumed by the public (sometimes referred to as a multi-sided marketplace).
The most common B2C examples of multi-sided marketplaces are the Apple App Store or Google Play Store. A B2B example was/is the Epic App Orchard (now Connection Hub), which allows third-party developers to write applications and utilize APIs to interact with Epic’s Electronic Medical Record Software that is used by thousands of hospitals and contains data on ~80% of U.S. patients.
Creating a marketplace is initially attractive because it multiplies revenue generation and market participation potential. Apple’s model of capturing ~30% of all revenue that flows through its App Store certainly seems like an attractive business model to replicate. Still, building this experience is challenging and expensive, especially as a first step into the market of monetized APIs.
Epic’s experience with its app store serves as a cautionary tale for companies considering this path today. To summarize their experience, they first launched the store and were flooded with interested third parties who wanted to develop on the platform. Epic executives interviewed at the time likened the store to an Apple iTunes or Google Play experience for healthcare. ~2 years following the launch, they were forced to halt all enrollment to the platform over privacy and security concerns. After some delay and refactoring, they relaunched the marketplace with significantly revamped privacy policies, governance, and commercial terms.
If your company is considering launching an API marketplace, let’s explore some lessons learned from companies like Epic that have walked this path before.
⚠️ The goal is not to dissuade anyone from launching a multi-sided marketplace but to encourage you to sequence your planning so that you can walk (i.e., manage a monetized API commerce portal) before you run (operate a multi-sided API marketplace or App store).
Successfully launching & managing a traditional API storefront & developer portal is challenging enough to get right, and ensuring you can maintain a healthy & active relationship with a group of interested third-party developers is a required first step. Launching your developer portal will test your teams’ ability to write quality documentation, respond to developer questions, manage API version control and new releases smoothly, and maintain the stability of the back-end systems supporting the APIs (among many others).
Adding an API storefront (commerce functionality for monetized API products) to your development portal will bring new challenges.
💡 Operating an API storefront will require your team to be able to build products and the associated rate plans, manage feature entitlements, collect credit card details for payment, integrate with back-end systems for manual billing for large customers, build a metering and rating system, implement an online contract management process, invoice customers, and establish a customer support process to deal with billing-related questions and refund requests.
Once you have built or procured mature systems & processes to manage the tasks above, the complexities will multiply significantly as you move to a multi-sided marketplace. However, by first establishing the basic capabilities of an API commerce portal, you’ll be able to solve them incrementally instead of all at once. The additional requirements for an API marketplace are discussed below.
As the owner of an API marketplace, your responsibility is not only for your code but for the code & applications written by third-party developers. This will require you to extend your operational security practices & code reviews to teams who do not report to you. You also take on liability for the privacy practices of these developers, which creates a hefty burden on your internal teams responsible for these areas. Based on Epic’s experience, you should not underestimate the costs of establishing the processes necessary to monitor third-party security & privacy.
In a traditional API storefront, money moves between buyer and seller only. When you evolve into a multi-sided application marketplace, money transfers between the app owner, the marketplace owner, and the app consumer, generally with a percentage of the transaction going to both market and app owners. Establishing the amount you charge application developers to participate in the marketplace is a new challenge and something you should expect to have to defend over time (as Apple had to do during litigation with Epic Games) as your marketplace grows in popularity.
This new wrinkle in money flow may seem simple to accommodate initially. Still, the devil is in the details here, as the application owners will rely on the marketplace owner to set up a payment management system. This will require you to allow third parties to configure varied & complex subscription models that run through your billing engine to collect money from the end user.
Finally, once that is accomplished, the marketplace owner will arbitrate application consumers' refund requests. This will require you to develop refund policies that extend across all marketplace participants and to staff the teams who will process these requests.
Given the other sections covered above, this final point is likely no surprise. Your company will be expected to promise a safe & positive experience for customers using the 3rd party applications in your marketplace based on the power of your brand. If and when something goes wrong with an application written by a 3rd party developer, the potential for legal exposure to the marketplace owner is significant, particularly if operating in regulated industries.
Because of this, the amount of legal support required from your team to initially launch the marketplace, approve individual applications, and re-certify them regularly over time will be considerable. While some smaller developers may be willing to accept click-through terms governing application resale on your marketplace, your larger customers likely will not. This will mean individual legal redlines for every new significant third-party service published in your marketplace.
There are a few critical factors required to increase the chances of success for a new API marketplace/app store:
Once you have number one above in place, and if your company profile matches the suggestions in points 2-4, the financial rewards from operating a multi-sided API/application marketplace can be significant. Still, as you can see, they do not come without a fairly significant investment in systems & processes to manage the associated complexities.
As a result, for most companies, the multi-sided marketplace and app store are tremendous medium-term goals but not the starting point.
If your company profile doesn’t match most items above, we recommend a more straightforward first step into API commerce.
💡 If your digital product business model is new or still maturing, 2-sided API storefronts in which you control all applications & APIs published are the recommended starting point. This choice involves less commercial & legal risk, less complexity, and a much shorter path to market and rapid profitability.
Now that you understand whether an API marketplace or storefront is right for you, if you need ideas on identifying the first opportunity for API monetization, this article provides several practical suggestions.
