Developer terms

More about restricted uses of the Twitter APIs

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.

Sensitive information

You should be careful about using Twitter data to derive or infer potentially sensitive characteristics about Twitter users. Never derive or infer, or store derived or inferred, information about a Twitter user’s:

  • Health (including pregnancy)
  • Negative financial status or condition
  • Political affiliation or beliefs
  • Racial or ethnic origin
  • Religious or philosophical affiliation or beliefs
  • Sex life or sexual orientation
  • Trade union membership
  • Alleged or actual commission of a crime

Aggregate analysis of Twitter content that does not store any personal data (for example, user IDs, usernames, and other identifiers) is permitted, provided that the analysis also complies with applicable laws and all parts of the Developer Agreement and Policy.

Off-Twitter matching

Off-Twitter matching involves associating Twitter content, including a Twitter username or user ID, 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 (i.e. “John Doe” in your customer record is matched to @johndoe on Twitter).

We want people to feel comfortable to create a separate and, if they choose, pseudonymous identity on Twitter. If you intend to associate any information about a Twitter user with an off-Twitter identifier, we require that you get express, opt-in consent from the user before making the association. For example, you could get this consent if the user shares their Twitter handle directly 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, we require that any connection you draw be based only on information that a user would reasonably expect to be used for that purpose. If a user would be surprised to learn that you are using information they provided to link their Twitter account to an identity off of Twitter, don’t do it. In addition, absent a person’s express opt-in consent you may only attempt to match your records about someone to a Twitter identity based on:

  • Information provided directly to you by the user. Records about individuals with whom you have no prior relationship, including data about individuals obtained from third parties, do not meet this standard; and/or
  • Public data. “Public data” in this context refers to:
    • Information about a user which you obtained from a public, generally-available resource (such as a directory of members of a professional association)
    • Information on Twitter about a user which is publicly available, including:
      • Tweets
      • Profile information, including a user’s bio and publicly-stated location
      • Display name and username

Redistribution of Twitter content

If you need to share Twitter content you 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 (i.e. request the full Tweet, user, or Direct Message content) using the Twitter APIs. This helps ensure that end users of Twitter content always get the most current information directly from us.

We permit limited redistribution of hydrated Twitter content via non-automated means. If you choose to share hydrated Twitter content with another party in this way, you may only share up to 50,000 hydrated public Tweet Objects and/or User Objects per recipient, per day, and should not make this data publicly available (for example, as an attachment to a blog post or in a public Github repository).

There are a few other points to keep in mind about redistributing Twitter content:

  • You may only distribute up to a total of 1,500,000 Tweet IDs to a single entity within a 30 day period unless you’ve received prior express written permission from Twitter.
  • Individuals redistributing Tweet IDs and/or User IDs on behalf of an academic institution for the sole purpose of non-commercial research are permitted to redistribute an unlimited number of Tweet IDs and/or User IDs.
  • To request permission to share Twitter content as outlined above, please use the API Policy support form.

To the extent you are permitted to distribute Twitter content to a third party, note that this content remains subject to the Developer Agreement and Policy, and you must ensure such third party has agreed to the Twitter Terms of ServicePrivacy PolicyDeveloper Agreement, and Developer Policy before receiving Twitter content.

Multiple applications

You are not permitted to register multiple applications for a single use case, or substantially similar or overlapping use cases. Learn more about these policies here.

In this context, we define “use case” as a consistent set of analyses, displays, or actions performed via an application. 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. These rules apply both to applications you register, and to applications registered by the end users of your tool or service; requiring your end users to register applications for the purpose of using your tool or service could result in enforcement actions against you, your applications, your customers, and/or the end users of your tool or service.

The only exception to this rule is to create development (“dev”), staging, and production (“prod”) instances of the same service. Ensure that these applications are clearly labeled (for instance, in the application name or description), and that you do not use development or staging applications for production purposes.

Automation, spam, and auto-responses

The use of Twitter’s APIs and developer products to create spam, or engage in spammy behavior, is prohibited. You should review the Twitter Rules on spam, and ensure that your application does not, and does not enable users to, violate our policies.

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:

  • Always get a user’s explicit consent before sending them automated replies or messages
  • Immediately respect user requests to opt-out of being contacted by you
  • Never perform bulk, aggressive, or spammy actions, including bulk following
  • Never post identical or substantially similar content across multiple accounts

Measuring the Twitter service

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:

  • Calculate aggregate Twitter user metrics, such as the total number of active users or accounts
  • Calculate aggregate Twitter Tweet metrics, such as the total number of Tweets posted per day, or the number of user engagements or account engagements
  • Measure or analyze spam or security on Twitter, except as permitted in the Twitter Rules

Surveillance, privacy, and user protection

At Twitter, protecting and defending the privacy of our users is built into the core DNA of our company — and our developer and data products reflect that commitment. We believe that 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, or in any other way that would be inconsistent with our users' reasonable expectations of privacy. Period.

We describe prohibited uses of our data and developer products in the Developer Agreement, including prohibitions on investigating or tracking Twitter users or their content, as well as tracking, alerting, or monitoring sensitive events (such as protests, rallies, or community organizing meetings).

Other categories of activities prohibited under these terms include (but are not limited to):

  • Investigating or tracking sensitive groups and organizations, such as unions or activist groups
  • Background checks or any form of extreme vetting
  • Credit or insurance risk analyses
  • Individual profiling or psychographic segmentation
  • Facial recognition

These policies apply to all users of our APIs. Any misuse of the Twitter APIs for these purposes will be subject to enforcement action, which can include suspension and termination of access.

For additional information for law enforcement authorities seeking information about Twitter accounts, visit