APIs undergo various stages in their lifecycle as they are created, used, and eventually retired. Different definitions of the API Lifecycle define these stages differently, but generally, they correspond to four high-level stages: design, development, deployment, and distribution. These stages are applicable to API implementations regardless of internal or external deployment.
Given the increasing focus on external API implementations, particularly in operationalizing machine learning, HLS, and financial services data, certain considerations should be made at each stage. We’ve seen that APIs aimed at external users also present a new set of concerns – ranging from protection from reputational damage to managing the demands of a wildly successful monetization initiative – that require product management expertise not required for APIs tailored for internal use.
In light of our experience productizing APIs, we'd like to share some reflections on how they inform the larger stages of the API lifecycle.
The design stage of the API lifecycle is the initial phase, where the developers plan and create the API. During this stage, developers traditionally determine the purpose and functionality of the API, including what data it will provide, what actions it will perform, and how it will interact with other software systems.
💡 In contrast, externally Productized APIs should often involve business disciplines that might not have been involved in the early API design and implementation phases.
Here are some examples of how product-level API decisions can impact an API design and should be considered earlier in the Productized API lifecycle:
API implementation occurs during the development phase of the API Lifecycle. This phase includes several activities that are essential to create an effective and functional API. An API's development phase is crucial to ensuring that it is reliable, secure, and functional.
Because productized APIs are intended to be exposed externally, they require additional development in several key areas.
**Security**: Productized APIs must be properly secured against threats due to their external nature. This is particularly acute as Productized APIs almost always have value attached to them, which may or may not be directly monetized but are still critical to the business. APIs also may need to be restricted to certain organizations or users. For example, highly specialized HLS or financial services APIs may only be exposed to consumers from a particular geography or email domain vs. the general public. A request to a Productized API request may also contain details about the contractual arrangement of the consumer, so that API implementations can tailor the API response according to a licensing entitlement or association with an organization.
**Billing**: Productized APIs must be capable of charging consumers for their usage in order to be monetized. From a development perspective, ensure that you have accounted for the following:
- The ability to correlate an API credential from your API gateway to a customer (company) and an end user (developer)
- The ability to consolidate API usage across multiple users (and generally multiple credentials) from the same company into a single invoice. If you are offering volume-based discounts, ensure that the combination of usage from multiple users is appropriately discounted based on total usage from all users in a single company.
- The ability to correlate a company who uses your API to a record in your CRM & ERP so that usage and costs related to an API user once invoiced are tracked appropriately in the company ERP.
- The ability to correlate revenue from a given product or API and track it to the appropriate profit center in your ERP.
- The ability to offer refunds for various reasons
- The ability to generate and send invoicing PDFs automatically at the end of every billing period
- The ability to invoice & collect payments via credit card automatically for smaller customers who prefer to pay this way
- The ability to automatically disable accounts with past-due invoices (most important in high-volume, self-service API sales models), and to re-enable them automatically once payment is made.
💡 The complexity of this task is often underestimated as there is much more to invoicing a customer than simply multiplying the number of API calls by a unit price.
We hope that this summary of how Productized APIs impact the first two API lifecycle stages is helpful to you as you plan your own API product roadmap. In a future post, we will explain the key changes that productized APIs require in the final stages of the API Lifecycle, Deployment, and Distribution.