Track Mentions
The/mentions endpoint returns tweets that mention a specific handle. Use it to monitor brand mentions, support inquiries, campaign engagement, and competitive activity. Results are paginated (up to ~20 per page) and support engagement and date filters built into the request body.
Note: For a complete guide with production code examples, multi-channel monitoring patterns, and competitive analysis workflows, see How to Track Twitter Mentions With API on the blog.
Quick Start
Tip: Test the endpoint without code in the API Playground.
Endpoint Reference
| Parameter | Type | Required | Description |
|---|---|---|---|
query | string | Yes | The handle to track, without the @ symbol. Example: "elonmusk". |
order | string | No | "latest" (default, chronological) or "popular" (engagement-ranked). |
since_date | string | No | Start date in YYYY-MM-DD format. |
until_date | string | No | End date in YYYY-MM-DD format. |
min_likes | integer | No | Minimum likes a mention must have. |
min_retweets | integer | No | Minimum retweets a mention must have. |
min_replies | integer | No | Minimum replies a mention must have. |
next_cursor | string | No | Pagination cursor from a previous response. |
Response
next_cursor is present, more pages are available. When it is null or absent, you have reached the end. See Pagination for handling patterns.
/mentions vs /search-tweets
The two endpoints solve different problems:- Use
/mentionsfor posts that tag a specific handle (@brand). The endpoint catches @-tags, replies, and references, withmin_likes,min_retweets,min_replies,since_date, anduntil_dateavailable as first-class parameters. - Use
/search-tweetsfor keyword-based matches that don’t include the handle. Searching"Nike" -from:Nike lang:encatches posts that name the brand in prose. Use this endpoint when you need Boolean logic, media filters, or other operators that go beyond what/mentionssupports.
Common Patterns
Filter by engagement
Pull only mentions that have reached an audience. Useful for reputation dashboards and PR monitoring.Pull every mention (support queue)
Omit engagement filters and sort chronologically. Catches every mention, including zero-engagement ones.Date-windowed campaign analysis
Bound mentions to a campaign window withsince_date and until_date. Loop through next_cursor until exhausted.
Polling for new mentions
Track the most recent tweet ID across iterations to detect new mentions only.last_seen_id to disk or Redis so the loop survives restarts. For the full real-time pattern with deduplication and backoff, see Real-Time Monitoring.
Common Pitfalls
min_likesset too high for support use cases. A bug report with 2 likes is more important than a meme with 500. For support queues, setmin_likesto 0 and rely on keyword routing instead.- Single-page reads on high-volume handles. One request returns ~20 mentions. For brands with hundreds of daily mentions, always paginate through
next_cursor. - Confusing
/mentionswith full coverage./mentionsonly catches @-tagged posts. Combine with/search-tweetsto catch untagged brand references. - Aggressive polling on low-volume accounts. Match polling interval to mention volume. Every 15 seconds for high-traffic brands, every minute or two for smaller accounts. Universal rate limit is 20 req/s (Rate Limits).
- Not persisting state across restarts. Without a durable checkpoint, a restarted monitor either re-alerts on old mentions or skips the gap.
Next Steps
- Search Tweets - keyword-based search for untagged mentions.
- Search Operators - operators for complex queries (media, geo, Boolean).
- Real-Time Monitoring - polling architecture with deduplication and backoff.
- Historical Data - mention data older than 7 days.
- API Reference - full endpoint specification.