Twitter Search API

Search public Twitter/X posts by keyword, hashtag, mention, and account

TwtAPI gives you a REST endpoint for public Twitter/X search. Run brand terms, hashtags, mentions, exact phrases, language filters, and from:username queries, then process the results in your own backend, scripts, or HTTP-based tools.

GET /api/v1/twitter/Searchq/type/count/cursor parametersStructured search resultsCallable from any HTTP client

Quick Take

Start with the decision, then read deeper if you need to

If you only need the fast decision frame, start with these points before reading the rest of the page.

What you can verify in 5 minutes

Start with one real query before turning search into a scheduled workflow.

  • Run q=(your brand OR competitor) lang:en against the latest results.
  • For example: q=("TwtAPI" OR "twitter api") lang:en, type=Latest, count=20. Confirm relevance before wiring automation.
  • Examples: q=("pricing page" OR "API cost") lang:en, q=#buildinpublic, q=@twtapi. Useful for brand mentions, campaign feedback, and content research.
  • Search brand names, product terms, @mentions, and support phrases, then let your own job write selected results to a sheet, ticket queue, or alerting system.

Use Cases

Use it when search results need to feed another tool

For one-off manual checks, the browser can be enough. TwtAPI is for repeated search jobs, saved results, and downstream analysis.

Brand mentions and support monitoring

Search brand names, product terms, @mentions, and support phrases, then let your own job write selected results to a sheet, ticket queue, or alerting system.

Competitor and launch tracking

Track competitor names, launch terms, and campaign hashtags with tweet links, timestamps, and author context for weekly review.

Content research and market scanning

Collect samples with keywords, exact phrases, and language filters before classification, summaries, or topic clustering.

AI agents, scripts, and internal tools

Use the Search REST API as the first data step, then connect it through your code, an HTTP Request node, or a backend job to Claude/OpenAI, databases, dashboards, or agent workflows.

Trial and Cost

Estimate usage with one real query

Do not judge only by a successful first request. Check query frequency, pagination depth, and the amount of useful data you will process each day.

Start with a production-like query

For example: q=("TwtAPI" OR "twitter api") lang:en, type=Latest, count=20. Confirm relevance before wiring automation.

Count pagination in your usage model

One page of 20 results and five cursor pages are different workloads. Monitoring jobs also need rules for empty runs and duplicates.

Open pricing before the pilot grows

If a job runs hourly across dozens of keywords, estimate the plan before you decide the final query split and schedule.

Separate historical search from monitoring

Current monitoring and full-archive research are different jobs. If you need older posts from a fixed date range, confirm coverage and cost separately.

Capabilities

Four search jobs you can build from the endpoint

Start with Search, then enrich with tweet detail or account data only when the workflow needs it.

AreaWhat to checkWhy it matters
search_tweetsSearch keywords, hashtags, mentions, and exact phrasesExamples: q=("pricing page" OR "API cost") lang:en, q=#buildinpublic, q=@twtapi. Useful for brand mentions, campaign feedback, and content research.
get_tweet_detailUse tweet detail when the next step needs more fieldsAfter Search returns tweet IDs, fetch detail to verify text, engagement, links, media, and conversation context before storing the result.
get_user_by_usernameLook up the author behind a resultWhen a result matters, enrich the username to see whether the author is a customer, competitor, creator, or casual account.
get_user_tweetsExpand one search result into an account timelinePull recent posts from the same account to see whether the tweet is a one-off comment or part of an ongoing topic.

Setup

From the first request to a scheduled search job

Make a single request reliable before you connect it to monitoring, reports, or AI analysis.

  1. 1

    1. Write one real query

    Use the actual brand, competitor, support phrase, hashtag, or account pattern you plan to monitor: q=("your brand" OR competitor) lang:en, q=#campaign, or q=from:username.

  2. 2

    2. Inspect the payload

    Check for tweet_id, text, timestamp, author, engagement, and source URL. Add TweetDetail or user lookup only if the next step needs more context.

  3. 3

    3. Add cursor, dedupe, and retries

    Scheduled jobs should store a cursor or last-seen value, avoid duplicate processing, and retry failures without leaving a sheet or report half updated.

  4. 4

    4. Send results downstream

    TwtAPI returns search results; it does not natively push to third-party tools. Use a backend job, Apps Script, an HTTP Request node, or your own webhook handler to write results to a database, sheet, alert, or AI summary step.

FAQ

Questions before you start using it

These are the practical checks teams make before putting tweet search into a real workflow.

How long does it take to run the first Twitter/X search?

Usually a few minutes: get an API key, open the Search docs, and call /api/v1/twitter/Search with curl or your HTTP client. Use a real brand, hashtag, or from:username query for the first test.

Which search query styles are supported?

Use keywords, hashtags, mentions, exact phrases, language filters, and account filters such as q=#AI, q=("pricing" OR "cost") lang:en, or q=from:username. Check the docs and live response for the exact behavior your workflow needs.

How many results can I fetch at once?

Start with count=20 for a small test. For production, model cursor pagination, duplicate handling, empty runs, and how often the job will run each day.

Are n8n, Google Sheets, or webhook integrations built in?

No native integration is built in here. TwtAPI provides the Search REST API. You can call it from an n8n HTTP Request node, Apps Script, a backend job, or your own webhook handler, then write the result to Sheets, alerts, or an AI workflow.

How is this different from the official X API or a scraper?

The official X API is the right path for official permissions, posting, OAuth, ads, or DMs. Scrapers can fit one-off extraction or unusual pages. TwtAPI is for public read workflows such as tweet search, user lookup, timelines, and monitoring when you want a faster integration path.

How should I estimate pricing?

Write down the real schedule first: number of queries, frequency, pages per query, and whether you also call TweetDetail or user lookup. Then compare that usage with the pricing page.

What if I need historical full-archive search?

First decide whether you need current monitoring or historical research. Full-archive jobs usually need separate checks for coverage, pagination, cost, and compliance expectations.

Next step

Validate tweet search before you schedule it

Run a real query, check the payload and expected usage, then connect tweet search to monitoring, reporting, or AI analysis.