API Management: A Tale of Two Keys

, Thursday, 6th August 2015 9:20 CST
Tags: , , , ,

The Goonies!When you’re getting started with an API, getting started is pretty simple. You study the Quickstarts, combine them with your API key, and start hacking away. In a matter of minutes, you’re doing something useful. In a matter of days, you build the API into your application and launch. Over the following weeks and months, you get a few, then dozens, then hundreds of happy customers and the world is a happy place.

And then it happens.

Someone inadvertently commits your API key to the repository. Or they accidentally include it in a screenshot. Or they send it in a code snippet to a customer.


While some people may panic, you planned for these sorts of scenarios and have it under control. With a single click, you cancel the old API key and roll out a new one. It’s almost too easy.

And that’s the problem.

This exact scenario happened to us earlier this year. We had a set of credentials inadvertently shared. We realized it immediately, reset the API key, and changed the impacted system. It was a smooth transition with no noticeable impact until we realized a secondary system also used that API and those credentials. As a result, we caused a brief outage for ourselves. It wasn’t customer-facing but still caused us pain.

Unless you arrange some deployment acrobatics with great timing, your systems are going to run into the same issue. If you’re lucky – like us – it’s only a brief moment and annoying. If you’re unlucky, it can be devastating and highly visible to users and gives them a bad day.

Multiple API Keys to Rescue!

Two API Keys are.. key.

For the Clarify API itself, we took a different approach. Instead of just creating one key, we’ve allocated space for two. It doesn’t seem like much, but what does it allow?

Let’s go back to the situation above.

This time, instead of just destroying the old API key, we first generate a new one in the “Key 2” slot.

Now we can update our application – and all supporting applications – with Key 2. Once we’re confident everything works as expected, we destroy the old key and the potential vulnerability is closed. There’s one time extra step but the rest is reordering what we already had to do.

The only thing we’re missing from the process above is the downtime. It’s the best of both worlds with almost no effort.

Leave a Reply

Your email address will not be published. Required fields are marked *