Zombie API Portals

I learned a new phrase a couple of months ago, and it is a phrase I have been hearing more and more amongst the conversations I am having on my Breaking Changes podcast, and with Postman customers as part of my regular engagements. The phrase is “Zombie API Portals”. Referring to an internal or external API portal that isn’t up to date and you really can’t tell if there is anyone home. We’ve all been at an API portal where nothing has time stamps, the documentation is static, and even when you ask a question or email them, you learn that indeed, there is nobody home. I really like the phrase Zombie Portal because as an API storyteller it is a phrase that captures your attention and evokes a shared pain we all face in a very pop culture way that also leaves you smiling. For me, this is API storytelling gold, and helps me do some heavy lifting to both get people’s attention, but also convey an important concept along the way.

I have long joked about Mashery API portals always being a ghost town. Go check it out, almost every company who bought a Mashery API management solution back in the day is a ghost town, with the last blog post being 2011, and the last Tweet being around the same time. The "build it and they will come" vision for API providers didn’t always pencil out, and it didn’t help to be shelling out six figures on a 3-5 year contract with a major API management provider. However, this Zombie virus isn’t exclusive to Mashery, and is something you will see regularly across the API Landscape, where someone got a bee in their bonnet about doing an API, published a portal, documentation, and code libraries, then wrote a blog post and didn’t do much else after that. In the end, it is a lot of work to publish and API, but it is also a lot of work to maintain one, and attract the attention of busy developers. This is why you see some API providers prefer to use solutions like RapidAPI, and other marketplaces to help them attract developers, and minimize the overhead of launching your own portal.

Another reason why Zombie API portal as a phrase resonates so well is that it also exists inside the enterprise. Almost everyone I talk to about their internal API discovery reality state that their internal API catalog, directory, and portal is out of date. I regularly hear that nobody keeps the meta data for their API up to date in the catalog, making the internal portal a place that nobody goes anymore. I agree, we need a central place to find everything API within an organization or domain, but I am not convinced that the API portal plus documentation formula is going to be able to keep up with the pace of operations within the average enterprise. It is a nice thought to think that all developers will do the work to keep their API portal, catalog, or directory listing up to date, and we even can believe that we can govern and enforce our way there, but it is more likely that we are going to have to come up with more automated and intelligent solutions to help do this for us. Understanding what APIs are in developing, staging, or production, and automating how not just API portals and documentation get updated, but also how consumers are automatically made aware of any changes and have a chance to provide feedback.

I think Zombie Portals are an environmental side effect of API management bundling of services that were more than what most people needed, but it is also a concept that I think will only work in certain environments. Moving forward we will still need portals, we just need another round of innovation in meet developers where they are and augmenting and automating forward the older notion of API portals and documentation. Making not just APIs, but also API operations more discoverable and accessible to not just developers, but business stakeholders too. We still need to be able to find APIs via the internal or external API portal, but we also need them to be available as part of the blog posts, social media posts, videos, workshops, and everywhere we are needing to work with private, partner, and public APIs. We need APIs to keep up with us, and we as humans need to be able to easily keep up with each version of an API across the hundreds or thousands of APIs we are needing to do business each day. We can’t depend on teams to always keep our portals up to date, and like other areas of the API lifecycle we need to be enabling our teams to do the right thing, and in the case of API portals and documentation, there is a whole suite of enablement we can provide.