Developer terms
Use of our developer platform requires that you review and agree to our Developer Agreement and Policy, as well as our related policies, including the Display Requirements and Automation Rules. Among other things, our agreements and policies provide guidance about several restricted use cases. We’ve provided additional information about some of these restrictions below.
You should be careful about using Twitter data to derive or infer potentially sensitive characteristics about Twitter users or their content. In particular, don’t derive or infer, or store derived or inferred, information about a Twitter user’s:
Aggregate analysis of Twitter data that does not process any personal information (e.g., information about identifiable accounts or individuals) is permitted, provided that the analysis also complies with applicable laws and all parts of the Developer Agreement and Policy.
Off-Twitter matching involves associating Twitter content with a person, household, device, browser, or other off-Twitter identifier. One example would be associating a Twitter username with a business’s customer records.
We want our users to feel comfortable that the identity they establish on Twitter is safe and, if they choose, pseudonymous. If you intend to associate any information about a Twitter user to an off-Twitter identifier, we accordingly require that you get express, opt-in consent from the user before making the association. For example, you could get this consent when you ask a user to share their Twitter handle with you as part of a signup process for your service.
In situations in which you do not have a user’s express, opt-in consent to link their Twitter identity to an off-Twitter identifier, you may do so only only if the link is based on:
If you need to share Twitter content obtained via the Twitter APIs with another party, the best way to do so is by sharing Tweet IDs, Direct Message IDs, and/or User IDs, which the end user of the content can then rehydrate using the Twitter APIs. You may only share up to 50,000 hydrated public Tweet Objects and/or User Objects per user of your service, per day, and should not make this data publicly available (e.g., as an attachment to a blog post).
There are a few other points to keep in mind whenever you’re redistributing Twitter content:
You are never permitted to create multiple applications for a single use case. In this context, we define “use case” as a consistent set of analyses, displays, or actions performed via an application. Please note that providing the same service or application to different end users (including “white label” versions of a tool or service) counts as a single use case. The only exception to this rule is to create development (“dev”), staging, and production (“prod”) instances of the same service. Learn more about these policies here.
If your application will be used to perform write actions on the Twitter service, including posting Tweets, following accounts, or sending Direct Messages, you should carefully review the Automation Rules to ensure your service complies with our guidelines. In particular, you should:
Do not use the Twitter APIs to measure the availability, performance, functionality, or usage of Twitter for benchmarking or competitive purposes. For example, you should never use the Twitter APIs to:
Twitter data can be a powerful force for good in the world — from saving lives during flooding in Jakarta to helping the USGS track earthquakes to working with the UN to achieve the Sustainable Development Goals. However, we prohibit the use of Twitter data and the Twitter APIs by any entity for surveillance purposes. Period. Any misuse of the Twitter APIs for these purposes will be subject to enforcement action, which can include suspension and termination of access. Learn more about these policies here. For additional information for law enforcement authorities seeking information about Twitter accounts, visit https://t.co/le.