Where O Where Is My API Key

Finding your API key for an API provider can be a real pain in the ass. Depending on the account it can be buried deep within your settings, or possibly out in the back 40 in another separate developer account. I’m not even talking about OAuth here, I am just talking about obtaining one or more API keys to access the valuable API resources you desire from a free service, or even from a service you are paying for. There is no standard for how to create, define, storage, and access API keys. It has been something that API providers have helped standardize somewhat (I guess?), but ultimately there is no unified way for me to access all the API keys I use across the thousands of API I use — yes, I do use thousands of APIs, because I am the API Evangelist.

Why can’t API keys be easier to find, and exist as a default part of our platform accounts. They shouldn’t be this hard to generate, find, and put to use. I keep coming back to my CloudFlare DNS application experience on this subject. Next to some of the actions I can take in the CloudFlare UI is a link to the API call to make the same action, complete with my API keys to make the calls. I don’t have to do anything else other than use the application to find the keys. Can you imagine if every UI element in every application had the underlying API call available right next to it with API keys? Can you imagine if every API call came back with a link in the response to where I can take the same action in the UI? Maybe I have a different view of the world than others, but this seems like it should be common place in the tech sector. I’m afraid many folks have seen APIs as some technical thing over there for too long, and wrongly feel that the average person shouldn’t worry their head about these things.

The reasons why APIs are often so hidden, and API keys hidden even further is that most applications really don’t want you snooping around under the hood. Most do not want you to understand what is happening or have access to the data behind an application, let alone to all of the actions being taken. When some applications genuinely do want people to use the API, the interfaces and APIs are both are often designed and developed by folks who haven’t put much thought into the bigger picture when it comes to blending the world of web apps and APIs, as well as how to actually incentivize API usage—they are just tasked with a job of building a UI or delivering API, nothing much more than that. It is fascinating to me that we will publish APIs for our applications, intentionally providing an external interface for others to use, but then not put much thought into what it will be like for those people to actually learn about and put our APIs to use.

If you have an API, find a fresh email account and sign up for your service with it. See how long it takes you to go from new signup to finding your key. Now close the account, return to your developer portal, log in and see ho long it takes you to find your key again. See if you can reduce friction in either of these processes, making it dead simple for your API consumers to get the keys they need. Additionally, make sure all the information is present with the key to help them be successful with authentication using their keys. Also consider bundling authentication along with the API call for each UI element, preventing consumers from having to dig around in some far away account to make the API magic happen. Let’s work a little hard to make our APIs the default thought behind every UI action we are taking within our applications, and I’m guessing we’d see our API adoption number shift pretty dramatically in response.