Have you ever wanted to request an API feature, or ask for additional information in the Twitter API? Read on for information about how you can be a part of the Open Evolution process.
Sign up to build what's next, with a Twitter Developer account
One of the things we have been doing since the inception of Twitter API v2 is building in the open - showing the developer community what we are working on, and asking what we could be doing differently or better. For me, this is one of the most exciting parts of working in Developer Relations - talking to the people who use the platform and product every day, and representing their thoughts and needs back to the engineering teams.
We started out with Twitter Developer Labs, which was the label for our early exploration of the new concepts (data structures and API specifications) that are now foundational in v2. Labs was an early access program that enabled us to test out the new formats, and also to check that our new systems scaled.
We've also been building in the open with features like the Spaces API. Spaces are a product feature that were added while we were working on the new Twitter API, and we were able to run sessions where we asked the community what data and features would be most important in the API, and to respond to that feedback. Most recently, I also hosted two series of Spaces back in March, to talk about potential future additions to the developer platform, around Tweet formats and timeline customisation.
We're grateful to everyone that joined those Spaces! We had some great conversations, and we are continuing to build on what we learned.
Follow @TwitterDev to watch out for future opportunities to join live discussions with us. There's also a monthly Developer Town Hall session where you can learn about the latest updates, and ask questions about the API.
There's also a way to directly influence the technical direction of the API: the Open Evolution process.
It's important to note that this is specific to the Twitter Developer Platform (the API - not to the main Twitter app or website); and also, it is only for the current version of the API. Previous versions may remain supported for use, but new features will not be considered for addition.
You can find the repository and workflow on GitHub.
Twitter API Open Evolution
This repository allows you to submit proposals to change aspects of the Twitter public API. You can read more about this process below, and in the announcement post on the Twitter Developer Community forums.
Submitting a proposal
Anyone can submit a proposal for consideration by Twitter. Proposals must conform to a defined template, and must respect the general principles of the Twitter API platform.
Before submitting a proposal, we strongly encourage you to start a discussion by opening an issue on GitHub, and to seek consensus and input from the broader developer community.
- Fork this repository.
- Make a copy of proposal-template.md, and rename it so that the title describes the proposal (it can have the same title as your proposal). Use a format like
your-proposal-nameis a descriptive name (e.g. the proposal title), keeping
000for the numeric part.
A proposal needs to conform to a specific template, provided in the repository; and it also needs to align with the general principles of the Twitter API platform, the fundamental rules of how we approach design of the public / external Twitter API. You'll see that these are around security, consistency, and a few other features - make sure to read the principles in detail, to understand the background.
If you're not sure about how your proposal would fit, you can open a conversation via GitHub Issues or on the developer forums to get things started, and to get feedback from other members of the community. The core process is driven by a Pull Request using the template, to define the requirement and proposal.
The process is:
- fork the Open Evolution repository;
- complete the template with your proposal, named so that it describes the suggested addition or change;
- submit a Pull Request containing the proposal;
- await a review from our team (we aim to get back to you within 15 working days if possible, although this may vary slightly with availability).
Proposals can be approved, or rejected. If the review process results in approval, this means that the changes are agreed in principle, but does not mean that they will be immediately implemented, and they may have to wait for a future developer platform revision.
As an example of how this can go, one of the Twitter Developer Insiders, @IgorBrigadir, made a great proposal requesting improvements to the way that Retweets are represented in the API. You do not have to be an Insider to get involved in the process, though! We welcome all proposals that meet the criteria described in the repository, and we love to learn more about how you use the API and what you might want to build with it.
- Learn about the Chirp Developer Challenge, and enter for your chance to improve the Twitter experience for users, and to win prizes
- Read our DEV posts and explore the #twitter topic for examples of how to use Twitter API v2
- Check out our code examples on GitHub
- Find a local Twitter community group via our website
- Follow us on Twitter @TwitterDev, and you can find other members of the community in our developer forums.