A Twilio Process To Emulate Within Your Own API Operations

Kin Lane
Written by

Leading API providers do not always make me happy with they way they conduct themselves, but it always makes me smile that one of the top API providers consistently over the last five years, continues to do things right, and set a good example that I can write about. I am not delusional to think that everything is perfect behind the Twilio curtain, but a story from Gordon Wintrob (@gwintrob) about how Twilio's distributed team solves developer evangelism leaves me hopeful (once again) about the potential of APIs.

There are several gems in this post, but one of them that stood out for me, and I think reflects the API potential which more companies should be emulating, is about how Twilio designs, develops and evolves new APIs. I think Gordon tells it the best: 

We also have a broader concept of our Developer Network, which handles a lot of the coding and writing for our public-facing documentation, blog posts, and our interactions with the community. Typically they’ll give feedback on the budding ideas for the new API. This feedback comes long before it goes out to the first beta customers.

The Developer Network brings a fresh set of eyes with less biased perspectives. They’ll say things like, “You know what? These parts of the API are awesome. This is what I would use it for.” or “These are the things that need work.” That way we know how the API would work for a developer at a hackathon or trying to finish the story points in a sprint. How do we make it as easy as possible for them?

Once the API or service comes together, we go to a closed beta process for a small group of customers. If we do a product announcement at all, then we’ll have a “request access” button. We’ll use that as a list of people that are really chomping at the bit to get coding. Then, after a period of time, when we have some API stability with people in our private beta process, we’ll switch to a public beta. Then it’s open to everyone who needs access.

We get more feedback before we go fully operational, but there should be no API instability after a public beta period. As an API company, we can’t go and change that underlying API once it’s in production. That would be a terrible experience. If we really need to change that endpoint API, it should be a new version.

Forgive me for just copying and pasting this much from your story Gordon, but I think it needs isolation as its own story. This is the approach to designing, developing, and operating APIs that companies need to hear more about. These are the technical product development benefits which being API-first can bring to the table. It's not just about providing data, content, and algorithms available via the web, it is about opening up the conception, design, and iteration of these API resource in a structured, collaborative, and evolutionary lifecycle on the web. 

This is what makes Twilio such a great API role model to showcase. I know Gordon is telling pretty stories, originating from Twilio, but like the secret to Amazon's success--these stories can have a significant impact on how individuals, companies, institutions, and government gencies approach technology within their own operations. Thanks for such a good story Gordon, providing me with some material to riff on.