Twitter API: the story of a new beginning

In this lightning talk from DevRelCon London, Aurelia Specker talks about the importance of bringing your existing developer community with you when changing an API and also how Twitter is working with their developer community to put them at the heart of their product development.

Transcript

Aurelia: Hi, everybody, it’s great to be here. So, as Carla said, my name’s Aurelia, and I work at Twitter in its developer relations team. And in the next five minutes, I want to tell you about something new and exciting that’s happening with the Twitter API.

I’ll start off with a bit of context setting for those of you who might not know. The API was initially made available to developers in 2006, that was less than six months after Twitter was launched as a public platform, and then in 2012, we had our first major technical revision, leading to version 1.1.

Now, we’ve always been lucky to have a healthy base of developers who want to use our APIs, and this has led to a variety of different interesting use cases. We’ve seen developers want to enhance the Twitter experience, TweetDeck, the mobile app experience, or search as a service were initially developed by developers using the API.

Developers come to our API to have fun. Someone built a plant that tweets when it needs watering. Or to understand the world, this is a great example demo of how you might use our real-time endpoints to see what’s happening in the world in real time, trends, sentiment analysis, et cetera, and to solve daily problems. I posted a tutorial a month ago that tells you how you might use the Twitter API to get bespoke commute information if, like me, you use the TFL underground network to get to work in the morning.

So, we’ve seen a lot of creativity over the years, but what might not be as obvious is that there’s been no major technical revision of the API, the standard Twitter API, since 2012, and this means that one, the API no longer fully reflects what the platform has to offer. We now support native media, quotes, quote tweets, polls, but that isn’t accessible with the API necessarily, but also, as you can imagine from a technical standpoint, the API is no longer as up to date as it could be.

This leads me to earlier this year, when we announced that we are now building the next generation of the Twitter API. And what this means is we’re going to be launching a new set of endpoints and features that, one, will make it easier for developers to get started on our platform, but two, that will also cater to more use cases and the needs of a greater range of different types of developers.

We want to reach more developers, and in doing so, we’re radically changing our approach, in that we want to build this next generation of the API with the people who use it and love it the most. And so, this means that we’re actively collecting developer feedback to inform our decision making in our current work, but also on an ongoing basis.

We want to build a platform that’s more dynamic, that supports versioning, and where we can constantly feed in that developer feedback that we’re collecting. In this context, we launched Twitter Developer Labs, which is a new program where developers can get early access to new endpoints and features, try them out, and then let us know what they think, and they can do that on our new feedback platform.

So here, developers can post ideas, they can review existing ideas, comment on these, or vote for the ones that they like, and we’re using a platform called UserVoice to do this, and so we’re actively seeking that feedback, as I said. And when I say we’re seeking feedback from the community, I mean the broad developer community, and that includes all of you in this room today.

So we’ve had a healthy amount of suggestions on this developer platform, feedback platform. We’ve had more than 100 ideas posted in the last few months, and we’re using these external statuses to connect back with developers, so we don’t want to just receive feedback, and developers take the time to send feedback but they never hear back from us. Instead, we want to have a kind of ongoing, two-way dialogue, and so this feedback, sorry, these external statuses enable us to tell developers “this was a great suggestion, “we want to implement it”, or “we can’t, “because x, y, z”, or “this has been done now”, and have this ongoing connection.

The response from the community has been very positive. Someone here says, within a day, my suggestions on that developer feedback platform were under review. Twitter feedback, the feedback is so cool. Someone else said “The Labs initiative is one of my favorite “developer initiatives”, and that has been really, really rewarding on our end of things.

I think my five minutes are coming to an end, so I’m going to leave you with some links if you are interested in finding out more. The top one is the labs initiative, we’ve got our feedback platform there in the middle, our road map, our documentation, and at the bottom, where you can sign up for developer account, if you don’t have one already, to use our APIs. I hope this has inspired you to think about how you might collect developer feedback yourself. If you have any questions, you can find me @AureliaSpecker, or the team @TwitterDev, thank you very much.