An API Portal allows your organization to join the API Economy by exposing your APIs as Products, allowing your customers to browse and consume API Products, and onboarding developers to get secure access to your APIs, along with instructions on how to use them. The API Portal is essentially a two-sided marketplace, with API Providers on one side, and API Consumers on the other, whereby you are the primary API provider. In many cases, the customer of the API Product is also a Developer, but this is not always the case. A customer may also be a non-technical person, in this case, they are responsible for the decision to use the API, however, a developer is always needed to work with the API on behalf of the customer. API Portals often appear on the developer. or developers. subdomain, for example, https://developer.mercedes-benz.com/, although there is a trend toward using digital., as this is more inclusive of all user roles e.g. https://digital.swisscom.com/. API Portals are also known as API Developer Portals or Developer Portals.
Example API Providers:
- Other teams in your organization
- External Developers
Example API Consumers:
- Existing Customers
- New Customers
- Other teams within your organization
- External Developers
Example: API Consumer - User Journey
An organization, acme inc., has many digital API products with a clear value proposition for each. These are exposed in a product catalogue on an API portal. Since these are keyword rich, they rank highly with search engines. A prospect customer organization has a pain point and they are trying to find a way to solve their problem. They find the API Product in a search and navigate to the API portal. After browsing through the acme inc. digital catalogue, the customer finds that the API Product satisfies their use case, and they decide to purchase a subscription. After choosing their preferred plan, they enter their credit card details and are subscribed to the digital product. At the end of the subscription process, the customer is prompted to either continue as a developer or to invite a developer to continue the process. In this case, the customer invites their lead developer to handle the technical integration. Upon receiving the invitation from the customer, the developer registers onto the API portal with the link they received. Upon login, they can see that the customer has already subscribed to a product. They can see which version of the API Product they need to develop against, all API documentation is tailored to this product version. The lead developer tries out the API and quickly understands the functionality, including how this fits into the use case outlined by the customer. In the next sprint, the integration is implemented, and the customer’s pain is alleviated.
With any API Portal, the developer experience is critical; if a developer has a bad experience, then your reputation may be damaged. Generally speaking, the developer does not want to see too much marketing material. They prefer to quickly get access to the APIs, try them out, and if necessary, read the documentation. An API Sandbox environment is required for the developer to try out and develop against. If a developer cannot get the API to work, then they will require prompt support, either via an existing developer community like Stackoverflow, or via a community support forum from within your API Portal. The use of SDKs are strongly encouraged; these allow developers to quickly consume your APIs and reduce the risk of anything going wrong.