We Should All Be API Consumers

I have long advocated that API producers should spend more time being an API consumer, so that they can feel the pain. I feel 100x this since I have been working at Postman. When you operate at the line between API producers and consumers, but also the automation of the API lifecycle, you really begin to see that the balance between producer and consumer is what matters the most. Even with my perspective I am heavily indoctrinated into the API producer side of the conversation. After over a decade of working with API service providers who mostly are serving the API producer I just end up with a bias in that direction. Working at Postman has changed that, and since I hired Deepa Goyal on my team, I am regularly being schooled about why the consumer view needs more prioritization.

Seeing, empathizing, and gathering feedback from the consumers of your APIs is essential to achieving the velocity you desire. Being a consumer of the APIs behind the infrastructure you use to produce your APIs across the API lifecycle is how you are going to achieve the forward motion you and your consumers need. Being a consumer of the APIs behind the SaaS solutions you use daily to operate your business is how you are going to connect all the dots across your operation, and obtain the control over your business. As an API producer you should be hyper focused on the consumer of those APIs, but you need to embrace your position as an API consumer yourself to automate the operations around your APIs, and scale and automate the business around those operations. Not seeing APIs is the number one mistake I see enterprise leadership making today, but I’d say a close second is purely seeing yourself as an API producer. Without the ability to automate your API operations, as well as your wider business operations using APIs, you will never be able to keep up with the pace of change occurring right now.

I really feel like this is the big mind shift that has to happen to shift things into the next gear. There are just too many APIs now. We have to automate the API lifecycle. We have to automate governance. APIs are how we’ll do that. As I have been pondering the past and future of the API gateway lately, I am realizing that no stage of the API lifecycle is greater than the other, and that they all work in concert as a single workflow for bringing an API to life, iterating upon each version of an API, and then eventually beginning to deprecate our legacy. We still see the gateway as infrastructure. We still see documentation as an application. These are all just digital capabilities we possess. They just happen to be capabilities that help us deliver and support our own APIs. It has taken the last ten years for APIs to become visible behind our applications, integrations, and automation. The next wave needs to be about emphasis on the APIs behind our API infrastructure, helping us get more organized and deliberate when it comes to how we automate the API lifecycle across hundreds or thousands of APIs—-something we’ll never do if we can’t channel our inner API consumer.