Enterprise Marketplace API Design

Art of the possible: curate API assets with Amplify Enterprise Marketplace

Art of the possible: curate API assets with Amplify Enterprise Marketplace

We designed Amplify Enterprise Marketplace to help unlock the hidden value in your API Management solution. What you do with the rich dataset provided is up to you. In this Art of the possible series, I’ve been illustrating how to use the information the marketplace collects about your APIs in new ways.

Last time, I offered one way to reduce duplicate APIs, using an AI tool to compare API specs and generate heat maps that highlight duplicate APIs. Today, let’s look at how you can make more data-driven decisions around curating API assets.

For a strong developer experience, make what you have to offer as clear as possible

As a publisher and curator of APIs, your job is to make the life of the application developer – the API consumer – as easy as possible. You want to give them everything they need to be able to consume your APIs and reduce that friction in the adoption process.

When it comes to APIs, offering a spreadsheet of the APIs you have available is hardly an appealing experience. Even dev-focused API developer portals often end up looking like a junk drawer full of cables, with no real organization or guidance as to how or why to use a given API.

This is where we realize the beauty of an API marketplace, which offers a comprehensive set of tools and resources to support developers throughout the entire API lifecycle. One of the things Amplify Marketplace does very well is allow you to create assets out of your APIs, and ultimately true digital products.

But when we start to help organizations build out their pricing model based on the number of transactions, assets, and/or subscriptions, we run into a common problem: this concept of assets is very new to people coming from an API portal.

So, for example, a lot of enterprises aren’t sure how many assets they have – it’s not something they are used to thinking about – and I get asked a lot of questions about how to form these assets.

A definition may be useful here: simply put, an API asset is a logical grouping of APIs.

An API consumer will come to your API marketplace to consume API products, but assets are that intermediary step on your backend to forming products. An asset can contain one or many APIs, and a product might contain one or many assets.

However, there are no real rules around how you define this logical grouping.

This is where API practitioners get to define for themselves – and for the business – how they want to think about their API assets. It’s at the heart of the curation process, which elevates APIs from a technical widget to a valuable, easy-to-consume digital product. Here are a few suggestions to get that conversation started.

Grouping APIs into assets based on the data they contain

One way to make this decision is to simply group APIs based on the kind of data they deal with. Because Amplify Marketplace consolidates all your APIs across platforms, gateways, and repositories into one enterprise API registry, it’s easier to track that data programmatically.

An enterprise might have a number of APIs that all deal with the customer, for example, meaning that together they represent a rich customer data model. A retail company might have an Accounts API, which contains customer information, and an Onboarding API which will also have customer information when adding new ones. The two APIs clearly have different functions, but they deal with the same data, and they may make a logical pairing.

For a developer looking through your API catalog, that relationship isn’t necessarily clear to them right away just by looking at the APIs. Instead of forcing them to dig through API documentation to arrive at this model, that enterprise can do some backend analysis and group together APIs that do something similar.

How to group APIs based on similar data

The process for doing this is quite similar to the one I described last time for identifying possible duplicate APIs: I looked at all the endpoints to compare not just names but also the data within the APIs.

In this case, you’d want to look for overlap but not exact matches, which may be a strong indicator that APIs are dealing with the same data in different ways.

I’ve added my example code here to the original github repository and updated the readme to describe how to use both examples (Search for Similar APIs + Suggest API Asset groupings).

Grouping APIs into assets by origin

Rather than analyzing the data contained within, another possibility is to look at where the APIs come from. Perhaps several APIs are coming from a specific line of business, or a set of APIs are from the same business domain.

One unit might be responsible for five APIs and another domain in the business manages four different ones. Those first five might make up one asset, and the other four may make sense as a separate API asset.

For example, a bank might have built a set of APIs for institutional lending, and another domain that does personal lending has designed some other APIs.

It might make sense to bundle the institutional lending APIs together as they’re likely to be used for a specific action, whereas the personal lending APIs would combine to make a separate asset.

Grouping API assets based on usage data

Brian Otten, who is VP of Axway’s Digital Transformation Catalysts, often evangelizes the importance of API metrics in making better enterprise API strategy decisions. In part, this means going beyond a “build it and they will come” attitude to actively monitor API metrics and understand which APIs are being used and how they’re being used.

This type of data can also help guide how you group APIs into assets. Because Amplify Marketplace gives you full visibility into all API adoption, usage, performance, and other metrics, making it easier to draw out key insights and make better API investment decisions.

“Digital products like APIs offer a seamless connection in the feedback loop,” Brian points out. “When a consumer subscribes to an API, you can obtain immediate and continuous feedback from their interactions with the product.”

From there, looking at which APIs are frequently used together by any single user is a hint that they might form a logical grouping.

Brian Otten writes more about how API product intelligence helps you measure impact here.


At the end of the day, the move from an API developer portal to an API marketplace is about shifting our view of APIs from a technical building block to a true product, with all the marketing and support that involves. In this shift, whatever you can do to reduce friction in the developer experience will pay dividends in the long run as your APIs become easier to adopt and monetize.

Learn more about how Amplify Enterprise Marketplace helps you extend and draw value from the APIs you already have.

Key Takeaways

  • Make API offerings transparent and organized, avoiding the more ad hoc approach of traditional API portals, to ensure a smooth developer experience.
  • Design API assets as logical groupings of APIs, enabling the formation of valuable, easy-to-consume digital products, which will foster the transition from technical widgets to marketable products.
  • Curate API assets based on data relationships, origin, and usage metrics, employing tools like Amplify Marketplace for comprehensive analysis and informed decision-making in building effective API products.
  • Use API metrics to gain insights into usage patterns, understand user behavior, and optimize assets accordingly, fostering continuous improvement and user engagement.