Allan Knabe is the co-founder and API product manager at Apiable. He has over 20 years of experience. In this article, he discusses API portals of the past, present, and future and tries to answer whether they will get better.
When I worked for Swisscom about ten years ago, I joined the API program. We had a developer portal, an evangelist with developer documentation, etc. The developer could access snippets of code and API specifications. But, after around 18 months, we found that we didn’t get the engagement on the APIs that we needed. Developers did not use our APIs. They did not read our blogs. We realized that the Enterprise Architect was going out and finding organizations that wanted to use our APIs. This was the past.
At present, we’re at a point where we accept that there is a persona beyond the developer. Developers are important as users of API portals. But we need to accommodate the business manager as well because he is the one who will decide whether or not to use the API. To explain the API to a business manager, you might need to describe it in more non-technical terms. Some companies like Nadia and Mercedes Benz are offering both streams. But we see that, though we are talking to the business managers, we don’t have any flow or process within the API portal for them. API portals are still developer portals when you sign up for them. You get in and must get into API specifications, keys, etc. If a business manager wants to do something with the API, they usually give him an email address to contact, and you have a conversation with them.
As we look into the future, we at Apiable understand that behind every developer is a team, the business manager, architect, etc. managing different integration systems. So, we should move away from just the developer to the development team as a whole. So, instead of a developer portal, we should call it a digital domain.
Monetizing your APIs can be something that you can decide on. In the future, there will be many discussions related to monetization. A monetization case can be developed based on the value of the API. Most often, the value of the API is indirect. Strategically locking down a customer to your platform and ecosystem will make it harder for them to move to your competitor. As they see value, more and more business managers will be willing to pay to use your APIs.
In the future, we must get the API portals more automated so that the business manager can understand it, subscribe to it, and invite their developers to let them self-serve themselves. APIs need to be built for scale, and onboarding should be automated.
To conclude, in the future, API portals need to be digital domains and ecosystems for everyone to understand, access, and use.