Over a million developers have joined DZone.

A Twilio Process to Emulate Within Your Own API Operations

DZone's Guide to

A Twilio Process to Emulate Within Your Own API Operations

Kin Lane explains why he believes that Twilio, one of the top API providers in the last 5 years, continues to do it right.

· Integration Zone
Free Resource

Share, secure, distribute, control, and monetize your APIs with the platform built with performance, time-to-value, and growth in mind. Free 90-day trial of 3Scale by Red Hat

Leading API providers do not always make me happy with they way that they conduct themselves. However, it always makes me smile to think 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 stood out for me that I think reflects the API potential that more companies should be emulating. It's 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.

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 that being API-first can bring to the table. It's not just about providing data, content, and algorithms available via the web; it's about opening up the conception, design, and iteration of these API resources 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 agencies approach technology within their own operations. Thanks for such a good story, Gordon, providing me with some material to riff on.

Explore the core elements of owning an API strategy and best practices for effective API programs. Download the API Owner's Manual, brought to you by 3Scale by Red Hat

endpoint ,api ,rest ,rest api

Published at DZone with permission of Kin Lane, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}