Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.x.com/llms.txt

Use this file to discover all available pages before exploring further.

title: Build a query sidebarTitle: Build a query keywords: [“build query counts”, “counts query”, “query builder counts”, “counts query syntax”, “build counts query”] description: **Query limitations! ** Your queries will be limited depending on which access level you are using.---

​
Building a query

Query limitations! Your queries will be limited depending on which access level you are using.  Your query can be 512 characters long for pay-per-use customers, or up to 4,096 characters for Enterprise customers. If you have Enterprise access, please reach out to your account manager.  Operator availability While most operators are available to any developer, there are several that are reserved for those that have been approved for Enterprise access. We list which access level each operator is available to in the list of operators table using the following labels: * Core operators: Available when using any Project. * Advanced operators: Available when using a Project with Enterprise access   

​
Operator types: standalone and conjunction-required

Standalone operators can be used alone or together with any other operators (including those that require conjunction). For example, the following query will work because it uses the #hashtag operator, which is standalone: #xapiv2 Conjunction-required operators cannot be used by themselves in a query; they can only be used when at least one standalone operator is included in the query. This is because using these operators alone would be far too general, and would match on an extremely high volume of Posts. For example, the following queries are not supported since they contain only conjunction-required operators: has:media has:links OR is:retweet If we add in a standalone operator, such as the phrase “X data”, the query would then work properly.  “X data” has:mentions (has:media OR has:links)

​
Boolean operators and grouping

If you would like to string together multiple operators in a single query, you have the following tools at your disposal:
AND logicSuccessive operators with a space between them will result in boolean “AND” logic, meaning that Posts will match only if both conditions are met. For example, snow day #NoSchool will match Posts containing the terms snow and day and the hashtag #NoSchool.
OR logicSuccessive operators with OR between them will result in OR logic, meaning that Posts will match if either condition is met. For example, specifying grumpy OR cat OR #meme will match any Posts containing at least the terms grumpy or cat, or the hashtag #meme.
NOT logic, negationPrepend a dash (-) to a keyword (or any operator) to negate it (NOT). For example, cat #meme -grumpy will match Posts containing the hashtag #meme and the term cat, but only if they do not contain the term grumpy. One common query clause is -is:retweet, which will not match on Retweets, thus matching only on original Posts, Quote Tweets, and replies. All operators can be negated, but negated operators cannot be used alone.
GroupingYou can use parentheses to group operators together. For example, (grumpy cat) OR (#meme has:images) will return either Posts containing the terms grumpy and cat, or Posts with images containing the hashtag #meme. Note that ANDs are applied first, then ORs are applied.
A note on negations The operators -is:nullcast must always be negated. Negated operators cannot be used alone. Do not negate a set of operators grouped together in a set of parentheses. Instead, negate each individual operator. For example, instead of using skiing -(snow OR day OR noschool), we suggest that you use skiing -snow -day -noschool.  Order of operations When combining AND and OR functionality, the following order of operations will dictate how your query is evaluated. 1. Operators connected by AND logic are combined first 2. Then, operators connected with OR logic are applied For example: * apple OR iphone ipad would be evaluated as apple OR (iphone ipad) * ipad iphone OR android would be evaluated as (iphone ipad) OR android To eliminate uncertainty and ensure that your query is evaluated as intended, group terms together with parentheses where appropriate.  For example: * (apple OR iphone) ipad * iphone (ipad OR android)   Punctuation, diacritics, and case sensitivity If you specify a keyword or hashtag query with character accents or diacritics, it will match Post text that contains both the term with the accents and diacritics, as well as those terms with normal characters. For example, queries with a keyword Diacrítica or hashtag #cumpleaños will match Diacrítica or #cumpleaños, as well as with Diacritica or #cumpleanos without the tilde í or eñe. Characters with accents or diacritics are treated the same as normal characters and are not treated as word boundaries. For example, a query with the keyword cumpleaños would only match activities containing the word cumpleaños and would not match activities containing cumplea, cumplean, or os. All operators are evaluated in a case-insensitive manner. For example, the query cat will match Posts with all of the following: cat, CAT, Cat. The filtered stream matching behavior acts differently from Post counts. When building a filtered stream rule, know that keywords and hashtags that include accents and diacritics will only match on terms that also include the accent and diacritic, and will not match on terms that use normal characters instead.  For example, filtered stream rules that include a keyword Diacrítica or hashtag #cumpleaños will only match the terms Diacrítica and #cumpleaños, and will not match on Diacritica or #cumpleanos without the tilde í or eñe Specificity and efficiency When you start to build your query, it is important to keep a few things in mind. * Using broad, standalone operators for your query such as a single keyword or #hashtag is generally not recommended since it will likely match on a massive volume of Posts. Creating a more robust query will result in a more specific set of matching Posts, and will hopefully increase the accuracy of your Post counts to help you find more valuable insights.  * For example, if your query was just the keyword happy you will likely get anywhere from 200,000 - 300,000 Posts per day. * Adding more conditional operators narrows your results, for example (happy OR happiness) place_country:GB -birthday -is:retweet * Writing efficient queries is also beneficial for staying within the characters query length restriction. The character count includes the entire query string including spaces and operators. * For example, the following query is 59 characters long: (happy OR happiness) place_country:GB -birthday -is:retweet Quote Tweet matching behavior When using the Post counts endpoints, operators will not match on the content from the original Post that was quoted, but will match on the content included in the Quote Tweet. However, please note that filtered stream will match on both the content from the original Post that was quoted and the Quote Tweet’s content.   Iteratively building a query Test your query early and often Getting a query to return the “right” results the first time is rare. There is so much on X that may or may not be obvious at first and the query syntax described above may be hard to match to your desired query. As you build a query, it is important for you to periodically test it out using one of the Search Post endpoints to ensure that the Posts that are matching your query are relevant to your use case. For this section, we are going to start with the following query and adjust it based on the results that we receive during our test:  happy OR happiness Use results to narrow the query As you test the query with Search Posts, you should scan the returned Posts to see if they include the data that you are expecting and hoping to receive. Starting with a broad query and a superset of Post matches allows you to review the result and narrow the query to filter out undesired results.   When we tested the example query, we noticed that we were getting Posts in a variety of different languages. In this situation, we want to only receive Posts that are in english, so we’re going to add the lang: operator: (happy OR happiness) lang:en The test delivered a number of Posts wishing people a happy birthday, so we are going to add -birthday as a negated keyword operator. We also want to only receive original Posts, so we’ve added the negated -is:retweet operator: (happy OR happiness) lang:en -birthday -is:retweet Adjust for inclusion where needed If you notice that you are not receiving data via Search Posts that you expect and know that there are existing Posts that should return, you may need to broaden your query by removing operators that may be filtering out the desired data.  For our example, we noticed that there were other Posts in our personal timeline that expressed the emotion that we are looking for and weren’t included in the test results. To ensure we have greater coverage, we are going to add the keywords, excited and elated. (happy OR happiness OR excited OR elated) lang:en -birthday -is:retweet Adjust for popular trends/bursts over the time period Trends come and go on X quickly. Maintaining your query should be an active process. If you plan to use a query for a while, we suggest that you periodically check in on the data that you are receiving to see if you need to make any adjustments. In our example, we notice that we started to receive some Posts that are wishing people a “happy holidays”. Since we don’t want these Posts included in our results, we are going to add a negated -holidays keyword. (happy OR happiness OR excited OR elated) lang:en -birthday -is:retweet -holidays  Once you’ve properly tested and iterated upon your query, you can start sending it with the Post counts endpoints to start to receive just the volume of Posts rather than the full Post payloads.

​
Adding a query to your request

To add your query to your request, you must use the query parameter. As with any query parameters, you must make sure to HTTP encode the query that you developed. Here is an example of what this might look like using a cURL command. If you would like to use this command, please make sure to replace $BEARER_TOKEN with your own Bearer Token: 
curl https://api.x.com/2/tweets/counts/recent?query=cat%20has%3Amedia%20-grumpy&tweet.fields=created_at&max_results=100 -H "Authorization: Bearer $BEARER_TOKEN"

​
Query examples

Tracking a natural disaster The following query matched on original Posts coming from weather agencies and gauges that discuss Hurricane Harvey, which hit Houston in 2017. Here is what the query would look like without the HTTP encoding: has:geo (from:NWSNHC OR from:NHC_Atlantic OR from:NWSHouston OR from:NWSSanAntonio OR from:USGS_TexasRain OR from:USGS_TexasFlood OR from:JeffLindner1) -is:retweet And here is what the query would look like with the HTTP encoding, the query parameter, and the recent Post counts URI: https://api.x.com/2/tweets/counts/recent?query=-is%3Aretweet%20has%3Ageo%20(from%3ANWSNHC%20OR%20from%3ANHC\_Atlantic%20OR%20from%3ANWSHouston%20OR%20from%3ANWSSanAntonio%20OR%20from%3AUSGS\_TexasRain%20OR%20from%3AUSGS_TexasFlood%20OR%20from%3AJeffLindner1) Reviewing the sentiment of a conversation The next rule could be used to better understand the sentiment of the conversation developing around the hashtag, #nowplaying, but scoped to just Posts published within