How to Search and Track Mentions on Twitter (X), Including Someone Else's

On X, a mention is a post whose text contains @handle, and the platform records it in the post's entities.user_mentions list. Three kinds of posts end up carrying a handle: a plain post someone wrote that includes it; a reply to that account, where the client prepends the handle automatically; and a reply anywhere further down a thread the account took part in, because the reply chain keeps prepending every participant. Quote posts are different: a quote of the account's post does not contain the handle in its text unless the author types it, so quotes mostly live outside a mention search. In our sample of 240 distinct mention posts, exactly one was a quote post, and every one of the 240 carried the handle in entities.user_mentions.

The Notifications timeline is a private, per-account feed: it is assembled server-side for the signed-in user from events that concern that user (mentions, replies, likes, follows) and there is no URL that opens it for another handle. That is why none of the "how can I see @mentions for another user" threads in forums end with a Notifications trick; the only routes that read someone else's mentions are search and the API, both of which operate on public posts. Those routes also work logged out and have nothing to do with whose account you own, which is the whole point: a mention search for @Stripe returns the same posts for Stripe's social team and for a developer who has never logged in.

Two limits are worth knowing before you build on this. Protected accounts' posts never appear in search, so a mention written by a protected account is invisible to everyone except that account's approved followers; X's search operators reference on docs.x.com/x-api/posts/search/integrate/operators defines @ as "Matches Posts mentioning a username", and that definition covers public posts only. And deleted posts drop out of search immediately, so a tracker that saw a mention at 10:00 and cannot find it at 10:05 is not broken; the post is gone.

The operators below are the ones you need for mentions. The first column is what you type into the x.com search box; the same string goes into the query parameter of /twitter/tweet/advanced_search, which follows X's advanced-search syntax. The last column says how we checked it: "docs.x.com" means the operator is defined on X's operators reference; "tested" means we ran it against our endpoint this session with @vercel and looked at the returned fields.

The one caveat is dates. On x.com's own advanced-search form (help.x.com/en/using-x/x-advanced-search) dates are entered as since:YYYY-MM-DD and until:YYYY-MM-DD. Our endpoint documents since_time: and until_time: in unix seconds instead and says the since: date form is unsupported. We tested both: the unix form returned twenty posts that all fell inside the requested two days, while the since: / until: date form returned twenty posts dated outside the requested range. If you are copying a query from the x.com search box into code, convert the dates to unix seconds first.

Combine operators with a space for AND, OR for alternatives, and parentheses for grouping; X's query-building guide on docs.x.com/x-api/posts/search/integrate/build-a-query states that a negated operator cannot stand alone, so always pair -from:handle with a positive term such as @handle. Two useful compound searches: @handle -from:handle -filter:replies is the closest thing to "people talking about this account on their own timeline", and (@handle OR "Brand Name") -from:handle catches people who typed the name without the handle, which no mentions endpoint can see.

If you only need to look once, the x.com search box with the Latest tab is enough, and X's own form at x.com/search-advanced builds the same string for you. Everything from the next section on is about doing it repeatedly, for a handle you do not own, in code.

Before building a tracker, it helps to know what it will print. We pulled the two most recent pages of mentions for six organization accounts, @vercel, @github, @Stripe, @Cloudflare, @Shopify and @NASA, through three routes, and classified every post inside the window where all three routes had coverage. The split was lopsided: of 240 distinct posts, 161 (67%) were replies to somebody else in a thread the account had taken part in, carrying the handle only because the reply chain prepends it; 35 (15%) were direct replies to the account; 43 (18%) were plain posts that mention the account on purpose; 1 was a quote post. Overall, 74.2% of @handle search results were replies by the isReply flag.

The per-account picture varies with how the account uses X. @NASA, which answers few replies and gets quoted and tagged in standalone posts, had 19 plain mentions out of 40. @Stripe, whose support conversations happen in long threads, had 37 of 40 posts classified as replies elsewhere in a thread and zero direct replies inside its 105-minute window. @github sat in between with 15 direct replies and 18 thread replies. The rate also varies by an order of magnitude: @Stripe accumulated 22.8 mention posts per hour and @NASA 18.9, while @Shopify, @github and @vercel ran at 6.8 to 7.4 per hour.

The practical rule that falls out of this: filter before you alert. inReplyToUsername == handle isolates direct replies (what a support team wants), isReply == false isolates standalone mentions (what a brand or PR team wants), and quoted_tweet.author.userName == handle isolates quotes, which you will mostly have to fetch with a separate quoted: style query because they rarely carry the handle in text. Printing everything that matches @handle produces a feed where two out of three lines are thread chatter.

Question. For the same handle, how much do the three API routes to "mentions" differ, what kinds of posts make up the result, how fast do mentions arrive, and what would continuous tracking cost on two rate cards?

Accounts and queries. Six organization accounts: @vercel, @github, @Stripe, @Cloudflare, @Shopify, @NASA. For each, two pages (40 posts) from /twitter/user/mentions?userName=handle, two pages from /twitter/tweet/advanced_search?query=@handle&queryType=Latest, and two pages from /twitter/tweet/advanced_search?query=to:handle&queryType=Latest. Five further single-page probes against @vercel tested -from:, filter:replies, -filter:replies, the since: date form and the since_time: unix form.

Window and sample. 41 requests, 820 posts fetched, collected in 2026, at a cost of $0.123 at $0.15 per 1,000 tweets. Per account, the comparison window runs from the oldest post that all three routes covered to the newest post seen, between 1.8 hours (@Stripe) and 5.9 hours (@Shopify); 515 route-posts fell inside those windows, 240 of them distinct. Overlap is measured on post ids. Kinds come from inReplyToUsername, isReply and quoted_tweet.author.userName.

What the sample cannot show. Two pages per route is a snapshot of a few hours on a weekday; mention rates swing with product launches and outages, so the per-hour figures size a budget rather than predict a month. Protected and deleted posts are absent from every route, so we cannot say how many mentions exist that search does not show. The cost projection assumes the measured rate holds for 30 days.

Privacy. The six target accounts are organizations and are named. The people who mentioned them are private individuals: raw API pages were not committed, the published sample holds only de-identified rows (route, kind, reply flag, minutes before window end, language, media flag), and every number on this page is an aggregate.

twitterapi.io exposes mentions two ways: a dedicated endpoint, GET /twitter/user/mentions?userName=handle with optional sinceTime and untilTime in unix seconds, and the general GET /twitter/tweet/advanced_search with a mention query. The dedicated endpoint returns exactly 20 posts per page, newest first, with has_next_page and next_cursor; the search endpoint returns up to 20 per page (its docs note that ads and non-post items are filtered out), also with a cursor. Both are billed at 15 credits per post returned, so there is no cost reason to prefer one.

We expected them to differ at the margins. They did not: for 6 of 6 accounts, the set of post ids inside the shared window was identical between /twitter/user/mentions and advanced_search with query=@handle (Jaccard similarity 1.0 for every account, 0 posts unique to either route). The to:handle route was a strict subset in every case, 35 of the 240 distinct posts, and all 35 were also present in the other two routes. That gives a clean decision table.

Two field-level notes from the raw pages. Every to:handle result also carried @handle in text, because X prepends the parent author's handle to replies; so to: adds no posts that @ lacks, it only narrows. And among the to: results, between 9 and 17 per account had inReplyToUsername equal to the handle while isReply was false; treat inReplyToUsername as the authority for "is this a reply to the account" and isReply as the authority for "is this a reply at all".

On the official X API the equivalent calls are GET /2/users/:id/mentions (the user mention timeline) and GET /2/tweets/search/recent with the same @ and to: operators, both billed at $0.005 per post read on the pay-per-usage plan published at docs.x.com/x-api/getting-started/pricing, with time bounds passed as start_time / end_time request parameters rather than query operators. The operator semantics are the same; the difference is price and that the recent-search endpoint covers the last seven days.

The tracker below runs forever, asking every five minutes for posts newer than a since_time: that it keeps ten minutes behind the clock. The overlap is deliberate: X search indexing is not perfectly ordered by createdAt, and a post indexed a minute late would be missed by a tight cursor. The seen-ids set absorbs the duplicates that the overlap creates, so each post prints exactly once. State lives in a small JSON file so a restart does not replay the last hour.

Three things to change for your case. Replace the handle on the command line; add -filter:replies to the query if you only want standalone mentions, or switch the query to to:handle if you only want direct replies; and swap the print for a Slack or Discord webhook POST, which is a one-line change (our Twitter to Discord bot page shows the webhook side). If you would rather use the dedicated endpoint, replace the URL with /twitter/user/mentions, pass userName and sinceTime as request parameters, and keep the rest; the response shape is the same tweets[].

Rate limits are not a concern at this cadence: the loop makes one request per poll (two if a burst spills onto a second page), and the account-level limit is 20 requests per second once a payment is on file, 0.2 per second before. The budget is the thing to watch, and the next section works it out.

Five-minute polling is 8,640 requests a month. At twitterapi.io, a request that returns posts costs 15 credits per post ($0.15 per 1,000 tweets) and a request that returns nothing costs the 15-credit minimum ($0.00015), so the floor for an account nobody mentions is $1.30 a month and the bill grows with the mention volume. Projecting each account's measured rate over 30 days: @vercel at 5,328 mentions a month, @github at 4,968, @Shopify at 4,918 and @Cloudflare at 7,128 all land at about $1.30, because fewer than one post arrives per poll on average and the per-poll minimum dominates; @NASA at 13,630 projects to $2.04 and @Stripe at 16,445 to $2.47.

The same volumes on the X API pay-per-usage plan, at $0.005 per post read from the rate card on docs.x.com/x-api/getting-started/pricing, project to $24.59 (@Shopify) up to $82.22 (@Stripe); the card also caps pay-per-usage at 3 million post reads per month and offers $20 in credits on a first card plus a match of the first auto-recharge up to $50. Per 1,000 tweets the ratio is $5.00 to $0.15, roughly 33 to 1, and on our side you pay only for the data returned with no X account needed for reads. Neither card charges for the polls that come back empty on the X side, so the X figure is a pure per-post cost.

If you poll every minute instead, the twitterapi.io floor rises to 43,200 requests, $6.48 a month, and the per-post part stays the same; whether that is worth it depends on how fast you need to react, which is the subject of the next section. For dozens of handles, put them in one query with OR (@a OR @b OR @c) so an empty poll is one minimum rather than one per handle; the posts returned cost the same either way.

A polling loop is the right tool for one to a handful of handles, a five-minute reaction time, and a budget measured in single dollars. It stops being right in three situations. First, latency: if a support team needs to see a complaint within a minute, every-minute polling multiplies the floor by five and still leaves up to sixty seconds of lag. Second, breadth: a watchlist of fifty handles plus brand phrases turns one query into several (X search queries have a practical length limit) and the empty-poll floor multiplies with them. Third, operations: a loop on a laptop dies when the laptop sleeps, and a loop on a server needs a process supervisor and alerting of its own.

For those cases there are two push-style options. A filter rule, registered once through /oapi/tweet_filter/add_rule with the same @handle query, has the service run the search on an interval and POST each match to a URL you host, so your side is a stateless receiver; our guide to monitoring Twitter via the API covers the receiver pattern and when it beats polling. The Twitter Stream monitoring product is the no-code version for account watchlists: the Starter Plan is $29 a month for 6 monitored accounts, and higher plans cover 20 to 2,000 accounts (plan list in the app; prices are on the product page).

A simple decision rule: start with the 30-line tracker, because it costs about a dollar a month and you will learn what the mention stream of your target handle actually looks like. Move to a filter rule when you want it running without a server of your own, and to the monitoring product when the thing you are watching is a list of accounts rather than a search. Our overview of Twitter monitoring for accounts and keywords lays out the three setups side by side without repeating this page.

Searching the handle without the @. vercel matches the word anywhere, including domains, bios quoted in text and unrelated uses; @vercel matches the mention entity. Use both only when you deliberately want name mentions, and then as (@vercel OR "Vercel") -from:vercel.

Forgetting -from:handle. An account's own replies mention the people it is replying to, and when it replies inside a thread it started, its own handle appears in the prepended chain. In our @vercel probe, adding -from:vercel removed the account's own posts and left 20 posts by other authors on the first page.

Treating every result as a new conversation. Two thirds of the sampled @handle results were replies deeper in existing threads. Group by conversationId before alerting and you will alert once per thread instead of once per reply.

Using the Top tab for monitoring. queryType=Top ranks by engagement and omits most low-engagement posts; a tracker wants Latest, which is chronological. Top is for a one-off look at what got traction.

Copying since: dates into API code. The date form belongs to the x.com form; on /twitter/tweet/advanced_search use since_time: and until_time: in unix seconds, which is what the tracker above does.

Expecting quotes in a mention search. Quote posts carry the handle only if the author typed it. If quotes matter, run a second query or read quoteCount on the account's own posts and fetch the quotes from there.