APIOps® Cycles

API Business Models

APIs provide our company possibilities to improve, change or add to our current business models. APIs can provide a way to create an internal and/or external platform and promote re-using, sharing and network business models.

Business model describes how our company (or a specific business unit) creates, delivers and captures value.

Our IT as internal API platform provider, our business units as the API value proposition developers

We improve our internal efficiency with APIs. Goal is to use APIs in our internal applications, analytics applications or home grown mobile apps. 

By using APIs internally, we aim to support our current and future business models with faster delivery time and new techonology.

While APIs get their data and some of they functionality from existing business applications, we aim to create an independent API layer (“platform”) on top of those systems for

  • improved consistency between data models and functions
  • to enable transition of existing systems to new systems without disrupting API consumers and
  • to leverage using cloud and modern implemantation technologies

Business units or those IT teams more in closest contact with business are responsible for defining the value propositions for each API and endpoint.

Our company as API provider

By creating APIs (being an API provider), our company is able to deliver value to our customers and partners. Because of this APIs need to be thought of as products and they need to be designed and split according to what value propositions they offer.

Each API and each endpoint should be evaluated and designed base on:

  • what data or functionality is our customer willing to pay for and what will make them more committed to engage with us and co-create with us
  • what data or functionality should we expose to our partners, so they will engage with us more efficiently and be able to support us and our customers in a better way
  • what is the data or functionality which is most needed by our customers and partners or our own service development? Which of those needs are easiest to implement and contains lowest amount of risk but highest amount of potential

In broadest sense value proposition can be described as a formula where Value = Benefits - Cost (cost includes economic risk). Developing a value proposition is based on a review and analysis of the benefits, costs and value that our company can deliver to its customers, prospective customers and other members of our company’s network and within our company. 

As we are treating our APIs as digital products which can be bought, sold and shared we use this product management opportunity assesment list as a tool when making decisions on which APIs to launch, to whom and with which data/functionality and which business model.

Assessing API opportunities:

  1. Exactly what problem will this API or endpoint solve? (value proposition)
  2. For whom do we solve that problem? (target market)
  3. How big is the opportunity? (market size)
  4. What alternatives are out there? (competitive landscape)
  5. Why are we best suited to pursue this? (our differentiator)
  6. Why now? (market window)
  7. How will we get this API product to market? (go-to-market strategy)
  8. How will we measure success/make money from this product? (metrics/revenue strategy)
  9. What factors are critical to success? (solution requirements)
  10. Given the above, what’s the recommendation? (go or no-go)

_By Marty Cagan, Silicon Valley and MindTheProduct -network guru of product management — Taken from: http://svpg.com/assessing-product-opportunities/

APIs as business development and innovation enabler

It’s possible that APIs even allow our API consumers to create new innovations using your APIs. It’s important to think and prepare on who, how and under what conditions is allowed to do so and how is the value measured and distributed between you and the external innovators. It’s also critical to understand that it’s not just a relationship based on exchange of money, but also experience, customers and possibly physical and data assets. So it needs to be managed, but not too managed to attract interest.

Creating customer value and reducing costs by being an API consumer

Our company may also act as an API consumer.

Typical API business models we use for opportunity assessment

  Internal cost optimization Indirect value Additional sales API consumer pays API consumer is paid
Revenue model

Market share


Restricted free use "Freemium" model or for specific partner uses APIs are included in the premium product/service packages or offered free for key customers Pay-per-use or according to added value Revenue sharing, %-based partnership
  • Reacting faster to market changes
  • Faster technology adoption
  • Shorter development time: distributed simultaneous development, promoting reuse
  • As part of cloud adoption strategy: microservices, SaaS adoption, IoT, AI, BigData etc.
  • Brand knowledge, marketing
  • Developer commitment
  • New channel, leads
  • Alternative to customer-specific customized integrations
  • Increasing customer commitment and engagement
  • APIs add value of traditional products and services for customers
  • APIs as "Commodity"
  • Traditional customer relationship, not a partnership
  • Payments received are used to cover costs of capacity and API and platform product development
  • Growth in customer volumes, getting in to partners' customer networks
  • Additional value to existing customers
  • Sharing data and functionality with partners
Typical API consumers = Developer community Internal consumers: Analytics platforms, CRM/ERP and other business applications, Digital services

Marketing partners

For example startups or educational organizations can belong to this category before becoming actual reselling or innovation partners

Innovation partners, customers, partners

Customers to whom we offer APIs as our main products

Innovation partners, resellers, supply chain partners

APIs can be divided to public, private and partner APIs based on their usage.

  • Private APIs are allowed to be used only by own applications. They contain attributes and data which is business critical and confidential.
  • Partner APIs are available for third party organizations upon approval of partnership terms and conditions. Partner APIs may contain partner specific or customer data which is not available for general public. Partner is liable for the use of the data according to terms and conditions. Partner maybe required to restrict the access of their end-users to the data. F.eg. Partner may access detailed price and purchase data of all stores, but each retailer using partner’s application can only access data of their own store.
  • Public APIs can be used by anyone without specific approval. APIs can still be authenticated with client id and secret to enforce rate limits and some general terms of use may apply.