Shifting How API Providers Define What An Application Is When Onboarding and Integrating With Their APIs
28 Oct 2020
When you sign up to access most APIs you will have to sign up for an account, create an application, and retrieve a set of keys and / or tokens before you will be able to use the API. This is standard practice that is baked into the home grown as well as Commercial API management solutions available across the landscape. This is a concept that was introduced back in 2005 by Mashery, and is something that hasn’t changed much over the years, despite what we build on top of APIs, and use APIs for having changed significantly over the last decade. In 2020, this relic of API management past needs to evolve if API providers and consumers are going to use APIs to their fullest potential—something API management service providers are going to have to take the lead on, and get back to work innovating and not just being a commodity.
When I sign up for Twitter’s API I have to create an application before I can get the tokens I need to begin using the application. I have to provide a name, purpose, and other details about what that application is—even if I do not fully understand what that is. Most API provider’s notion of an application means web or mobile application, but in reality it can be the “application” of the data, content, and algorithms being made available via an API in a variety of ways from just pulling data to integrating in real-time with other systems. As an API analyst and storyteller I rarely am building an application, but just looking to kick the tires and understand what is going on—being forced to define an application is nothing but a road block for me. I may be a small group of API consumers, but there are many other edge cases which are similar to my situation in that we represent the long tail of API consumption in the unknown unknown API usage quadrant—meaning we are still figuring out why we need an API.
The most significant breakdown in the concept of defining an application is that it is designed for use by developers. In an iPaaS, BPM, and API automated business world, the legacy API management application definition doesn’t work. It is bad enough that an application stands in between a regular user of a platform and getting access to their data, content, and the useful algorithms that exist, but we often also hide all of this in some other completely separate developer area, excluding them from the conversation—instead of just making the API, and access to the API a natural part of the platform account management and settings. This separation between business and integration interfaces reflect decades of division between business and IT groups that needs to be done away with as we move forward in an API-driven business landscape. There is no reason that as a user of an “application”, that I need to venture to another separate section of a platform and create another “application”, just so that I can access the same data, content, and algorithms I am already putting to use via the platform. It just doesn’t pencil out anymore.
This portal and management infrastructure that is serving API consumers who are building web or mobile applications. This usually doesn’t include the other types of applications consumers will be developing like integrations, automation, orchestrations etc., but more importantly it doesn’t serve other complimentary API providers, or API service providers. Meaning, Twilio and Stripe are optimized for their consumers to build applications on each of their respective APIs, but there is very little done to address when SMS and payments are made in a single application across both providers. There is a huge opportunity for API providers to share consumers, and optimize for bundled onboarding, integration, reporting, and other key areas. Additionally, there is very little considerations for how API service providers will be putting APIs to work across many different API providers. Which brings me to why I am writing this. As an API consumer using Postman across many different APIs, the burden is on me to setup applications and obtain keys for all of the APIs I am using, and there are very few API management affordances for me as Postman to help bridge these gaps. Can I go setup a single application and service all of my customers via the Twitter API? Yes, I guess I could argue that Postman is the application, but really developers are just using us as a vehicle to get them to their application or integration. Lots of conversations to be had here, and very few ways these discussions are being facilitated via existing API providers or service providers.
I am in a good place in the industry to move this conversation forward. Both by being at Postman, but also with my relationships to API providers, and specifically the API management service providers. This is a ball I think I will move forward in the next five years, helping push forward this critical construct in the API factory floor which seems to be slowing us down. Sometimes we just have to identify these legacy constraints that exist and encourage a handful of API providers and API service providers to take the lead—then we can help move things forward in a more meaningful way. If we are going to scale all of this API stuff to the levels we envision in our heads, and blow smoke about in our API economy storytelling, then we are going to have to trim a lot more friction off the API onboarding and integration dimensions of our operations. This will help us move from using ten or twenty APIs, to being able to use hundreds or thousands of APIs seamlessly across tens or hundreds of API providers with the same amount of effort. We just have to do the hard work to shift our views of what an application is, moving beyond these legacy web and mobile constructs, realizing that each potential API integration can have a wide range of applications in our digital and physical worlds.