Previously, we discussed how an API intended for external consumption impacts the design and development phases of the API lifecycle. We covered how externalized APIs should be treated as digital products to maximize adoption, minimize business risks, and generate revenue. As externalized APIs are prepared for deployment and distribution, later phases of the API lifecycle are also affected.
The following reflections are based on our experiences productizing APIs and how they inform later stages of the API lifecycle.
Deployment
The API Lifecycle's deployment stage refers to making the API available for consumption by its consumers. As part of the deployment process, an API undergoes rigorous testing to ensure its functionality, security, and performance.
When deploying a Productized API, attention should also be paid to the following tasks in addition to those that are normal for this part of the API Lifecycle:
* **Developer Portal / API Marketplace Integration**: Unfortunately, you cannot rely on your customers finding your Productized API in an internal directory like you can with internal APIs. Developer portals and dedicated API Marketplaces are discovery and self-service points for Productized APIs. Developers must ensure the API being developed is properly presented on a developer portal, ensuring that a potential consumer / customer is aware of:
- If monetized, the API or API bundle's pricing tiers, etc
- Terms and conditions / licensing acceptance
- SLAs associated with the API or group of APIs
* **API Gateway / Service Mesh Integration**: It's important that Productized APIs managed by an API Gateway or Service Mesh have the appropriate set of policies applied to them. Policies for security and governance, as well as policies that collect metadata to measure the usage of Productized APIs, fall into this category.
* **Unmanaged APIs**: APIs that are not being managed behind an API Gateway or Service Mesh will likely still need to present metering data and report on whether or not they are meeting any SLAs associated with a consumer.
* **Heterogeneous Analytics**: A portfolio of Productized APIs may not all be managed by a single API Gateway or Service Mesh (or managed at all!) Regardless of how APIs are exposed, your analytics solution must provide insight across different API deployment models.
* **Consumer Metadata Enrichment**: API requests usually have an associated authentication token that contains some metadata about the consumer. In general, this metadata doesn't contain enough authorization information to determine what entitlements or licenses are present for a particular transaction. The amount of latency introduced to obtain this metadata in realtime for an API implementation (or gateway) to determine what kind of data to return to a consumer further complicates matters. Consumers with paid API access, for example, might receive a different response than those with free API access and backend systems will need to receive enough information from the API request to make the determination as to which dataset to return
* **Automated Testing / CICD Integration**: In modern environments, the API is generally deployed through an automated continuous integration and deployment process. Part of this process should automate testing the non-functional aspects of the API, such as security and availability. Productized APIs with SLAs (either implicitly or explicitly) are particularly important targets for comprehensive functional and non-functional testing. Additionally, monetized APIs introduce new vectors for testing, such as changing volume tiers appropriately, enforcing quotas properly, and handling credit card transactions properly.
Distributing
In the API Lifecycle, the distribution stage refers to making the API discoverable to the intended audience. Traditionally, when an API is distributed, it is essential to monitor its usage and manage any issues that arise. Monitoring usage analytics, responding to support requests, and updating API documentation and infrastructure are all part of this process.
💡 In an enterprise scenario, productized APIs should support two potential customer purchase models: Enterprise Sales & Self-Service Sales.
- Enterprise Sales: The model most enterprises are familiar with is enterprise sales, where partnerships are agreed in traditional contracts during a (traditionally) long sales cycle. Once these partnerships are agreed, private access to API endpoints is granted to the new partner.
- Self-Service API Access: This model is less familiar to enterprises, but when competing with API-first companies, it is important to offer a self-service version of your API product. This requires your API storefront to allow self-service user registration as well as a self-service sales and credential creation process.
Oftentimes, Enterprises will still govern registration to the marketplace through a pre-approved email domain list (i.e., google.com and yahoo.com addresses are automatically denied, but the 500 domains of likely partners and customers are automatically approved). However, once access to the developer portal is granted automatically or manually for productized APIs, offering a self-service purchase and provisioning model to interested developers is important. This allows a low-friction sales model that is less familiar to Enterprise but that can be highly-beneficial with productized APIs.
As you plan your own API product roadmap, we hope this summary helps you understand how Productized APIs affect the later stages of the API lifecycle. At Revenium, our focus is on building and launching Productized APIs with our clients. Get started today using the link below.
