I Appreciate The Request To Jump On Phone But I Have Other APIs To Test Drive

February 5, 2018

Streamdata.io is investing in my API Stack work as we build out their API Gallery of valuable data streaming APIs. I’m powering through hundreds of APIs and using my approach to profiling APIs that I have been developing over the last eight years of operating API Evangelist. I have a large number of APIs to get through, so I don’t have a lot of time to spend on each API. I am quickly profiling and ranking them to quickly identify which one’s are worth my time. While there are many elements that get in the way of me actually being able to obtain an API key and begin using an API, one of the more frustrating elements when API providers require me to jump on the phone with them before I can test drive any APIs.

I’ve encountered numerous APIs that require me talk to a sales person before I can do anything. I know that y’all think this is savvy. This is how business is done these days, but it just isn’t the way you start conversations with API consumers. Sure, there should be support channels available when I need them, but it SHOULD NOT be the way you begin a conversation with us API consumers. I’ve heard all the reasons possible for why companies feel like they need to do this, and I guarantee that all of them are based upon out of date perspectives around what APIs are all about. Often times they are a bi-product of not having a modern API management solution in place, and a team that lacks a wider awareness of the API sector and how API operations works.

In 2018, I shouldn’t have to talk to you on the phone to understand what your API does, and how it fits into what I’m working on. Most of the time I do not even know what I’m working on. I’m just kicking the tires, seeing what is possible, and considering how it fits into my bigger picture. What good does it do for me to jump on the phone if I don’t even know what I’m working on? I can’t tell you much. You can’t share API responses with me. You will able to do less than if you just give me access to APIs, and allow me to make API calls. You don’t have to allow me to make too many calls, just a handful to get going. You don’t even have to give me access to ALL the APIs, just enough of them to wet my appetite and help me understand what it is that you do. This is done using modern API management solutions, and service composition. Giving you the control over exactly how mcuh of your resources I will have access to, until I prove myself worthy.

The APIs I come across that require me to jump on sales call will have to wait until later. I just won’t have the time to evaluate their value, and understand where they fit into my work. Which means they probably won’t ever make it into my project, or any of my storytelling around the work. Which means many of these APIs will not get the free exposure to my readers, helping them understand what is possible. It is just one of many self-inflicted wounds API providers make along the way when they leave their enterprise blinders on, and are too restrictive around their API resources. Sales still has a place in the API game, but the overall API strategy has significantly evolved in the last five years, and is something that is pretty easy to see if you spend time playing with other leading APIs on the market. Demonstrating that these providers probably haven’t done much due diligence about what is out there, which often is just yet another symptom of a poorly run API program, making passing on it probably a good idea.

Read more...

Previous Article
Learning About The Headers Used for gRPC over HTTP/2
Learning About The Headers Used for gRPC over HTTP/2

I am learning more about gRPC and HTTP/2, as part of the recent expansion of my API toolbox. I’m not a hug...

Next Article
API Is Not Just REST
API Is Not Just REST

This is one of my talks from APIDays Paris 2018. Here is the abstract: The modern API toolbox includes a v...