RapidAPI Twitter Alternative: Direct API vs Marketplace

Most developers find RapidAPI the same way: they search "twitter api" on Google, land on a marketplace listing, sign up because it looks simpler than X's developer portal, and ship something that works for a week. Then a listing goes dark for three days, a billing line item triples without warning, or a response schema changes mid-sprint. By the second or third incident, the question shifts. The real question is no longer "which RapidAPI Twitter listing do I pick" but "what is the right RapidAPI Twitter alternative for production traffic."

This guide answers that question. It explains how the RapidAPI marketplace actually works for Twitter and X data, where it shines, where it breaks, and how a direct API like GetXAPI changes the economics. No vendor bashing. RapidAPI is a real product and the marketplace solves real onboarding pain. The argument here is narrower: for production Twitter workloads, the marketplace layer adds risk you can remove.

What Is RapidAPI For Twitter

RapidAPI is an API marketplace. Third-party developers (the "publishers") list their APIs on the platform; consumers sign up once on RapidAPI, browse listings, subscribe to a plan, and call the listed APIs through RapidAPI's unified auth header. RapidAPI charges the consumer, takes a marketplace fee, and pays the publisher.

For Twitter and X data specifically, the marketplace surfaces three broad listing types:

1. Headless-scraper listings. A publisher operates a fleet of stealth browsers (Puppeteer, Playwright, Selenium with proxy rotation) hitting the X web frontend. The listing exposes a clean REST shape on top of the scraping pipeline.
2. Unofficial-API wrappers. A publisher reverse-engineers the mobile or guest endpoints X uses internally and wraps them with auth, retries, and pagination. The listing exposes those wrapped endpoints through RapidAPI.
3. Aggregator listings. A publisher routes requests through several backends (their own scrapers, third-party APIs, archived datasets) and returns whichever returns first or lowest-cost.

All three types live behind the same https://rapidapi.com/... URL pattern and use the same X-RapidAPI-Key and X-RapidAPI-Host headers. From a developer integration perspective they look identical. From a reliability and cost perspective they are not.

The Three Real Options

A developer choosing how to read Twitter or X data in 2026 has three real options. The cleanest way to think about the choice is to compare the marketplace layer (RapidAPI) against the source-of-truth layer (the official X API) against a purpose-built direct API (GetXAPI).

Dimension	RapidAPI marketplace listings	Official X API v2	GetXAPI
Operator	Third-party publisher	X (xAI)	GetXAPI team
Auth	X-RapidAPI-Key + X-RapidAPI-Host headers	OAuth 2.0 PKCE or Bearer	Single Bearer header
Setup time	5 minutes (RapidAPI signup)	Days to weeks (developer account)	Under 5 minutes
Free tier	Varies by listing (often 25 to 500 calls per month)	None on public v2 since Feb 2023	$0.10 in credits, no card
Standard read pricing	$0.15 to $5.50 per 1,000 results, listing-dependent	About $5.00 per 1,000 standard reads	$0.05 per 1,000 tweets
Pricing transparency	Visible on listing page, marketplace fee bundled	Visible in Developer Console	Visible on the pricing page
Volume cap	Listing tier ceiling (often 100K to 1M per month)	2M post reads per month before Enterprise	None (pay per call)
Uptime ownership	Publisher	X infrastructure	GetXAPI team
Multi-platform	Some listings wrap several social platforms	X only	X only
Schema stability	Listing-dependent, can change with publisher updates	Stable (v2 contract)	Stable, denormalized JSON
Write endpoints (post, like, DM)	Rare on Twitter listings	Yes (OAuth required)	Yes (Bearer header)

Every row of that table matters when something breaks at 3 AM. The marketplace surface is genuinely faster to onboard, but the operating model changes the moment your service has paying customers.

Where RapidAPI Wins

Treating RapidAPI fairly means acknowledging what it does well. There are several real strengths that justify it as a starting point.

One billing relationship for many APIs. A team building a product that needs Twitter data plus weather data plus exchange rates can subscribe to three listings under one RapidAPI account, one invoice, one set of usage dashboards. That consolidation has real operational value for small teams.

Marketplace breadth. RapidAPI lists tens of thousands of APIs. For developers exploring a category, the marketplace is a discovery engine. You can compare three Twitter scrapers side-by-side, read consumer reviews, and pick one without three separate signups.

Uniform auth pattern. Every listing on RapidAPI uses the same two headers: X-RapidAPI-Key and X-RapidAPI-Host. Once you wire that pattern into your HTTP client, adding a new API is a one-line config change. This is genuinely nice when you are prototyping.

Built-in usage dashboards. RapidAPI provides per-API usage charts, call logs, and tier-utilization graphs. Publishers do not always offer this depth on their own websites, so the marketplace dashboard can be the better observability surface during development.

Try-before-you-buy. Most listings offer a free tier of 25 to 500 calls per month. You can validate a listing's response shape and reliability before committing to a paid plan. That trial-without-friction is the marketplace's strongest onboarding lever.

These are real benefits. The argument in this guide is not "RapidAPI is bad." The argument is "the marketplace layer that makes onboarding pleasant also adds risk you eventually want to remove."

Where RapidAPI Hurts

The pain shows up in five specific places, none of them obvious until you have shipped to production.

Reliability Is Inherited From The Publisher

Every listing on RapidAPI is operated by a third party. RapidAPI's status page tracks the marketplace platform itself, not individual listings. When a Twitter scraper listing goes dark for three days because X updated the frontend and the publisher is on holiday, RapidAPI shows green. Your error budget shows red.

Real incident pattern: a scraper listing breaks on a Friday afternoon when X ships a CSS class refactor. The publisher's GitHub issue tracker fills with reports over the weekend. The publisher pushes a fix on Tuesday. Your service was returning 502s the entire time. Your customers churned, RapidAPI billed for the failed calls, and the publisher is back to green on Wednesday with a note in the changelog.

This is not theoretical. The pattern repeats two to four times per year on the most popular Twitter scraper listings, tracked publicly through marketplace consumer reviews and GitHub mirrors. The pattern is structural, not specific to any one publisher.

Billing Is Two-Layered

You pay two parties on every RapidAPI call: the publisher and RapidAPI's marketplace markup. Both costs show up on your monthly invoice, but they are not always visible at the listing level. Common patterns:

• Tiered subscriptions. A listing might charge $25 per month for 10,000 calls plus $0.005 per call beyond. The $25 includes the publisher's revenue plus RapidAPI's fee. If you exceed the tier and pay overages, the per-call price often jumps.
• Pay-per-result with marketplace surcharge. A listing might charge $0.20 per 1,000 results. RapidAPI's marketplace fee is built into that price (often 20 percent of the publisher's revenue). The publisher quotes $0.16; RapidAPI shows $0.20.
• Hard-to-predict overage scenarios. Several Twitter listings charge per-API-call AND per-result. A search query returning 100 tweets costs one call (against your tier) plus 100 results (against a separate counter). Two counters in one transaction makes monthly forecasting harder.

Net effect: forecasting your Twitter API spend from RapidAPI requires reading the small print on each listing carefully, then modeling both counters in a spreadsheet. The direct-API alternative gives you one counter (calls) and one rate.

Schema Drift Is Not Versioned

The official X API publishes a stable v2 contract. GetXAPI publishes its endpoint reference at docs.getxapi.com and changes are announced. RapidAPI listings have no shared versioning convention. A publisher can change response field names, drop fields, or restructure pagination without a marketplace-level changelog. You discover the drift when a deploy fails or your data warehouse rejects a row because a JSON column changed type.

The defensive pattern is to pin your code to a snapshot of each listing's response shape and write integration tests that hit the listing weekly. That overhead is real engineering work that the marketplace layer adds.

Rate Limits Are Publisher-Defined

Each listing has its own rate limits, often hidden in the listing's documentation tab rather than the marketplace pricing tab. Common patterns:

• 5 requests per second per consumer, hard ceiling
• 100 requests per minute on free tier, 1,000 per minute on $25 tier
• Concurrent-request caps that throttle parallel scraping pipelines

RapidAPI surfaces some of this in the API console but not consistently across listings. Hitting an undocumented rate limit at 11 PM during a traffic spike, with the publisher's support email unattended until Monday, is a familiar pattern.

You Cannot Negotiate

RapidAPI's pricing is set by the publisher and is not negotiable for marketplace consumers. If your volume grows to a level where direct pricing would make sense, you cannot call the publisher and ask for a custom rate. You either stay on the published tier or move off-marketplace entirely. By contrast, direct APIs (including GetXAPI) offer volume pricing once you cross usage thresholds; the conversation happens in one channel because there is no middleman.

For early-stage usage, these five pain points are tolerable. For production traffic with paying customers behind it, each one accumulates into ongoing cost or risk.

Pricing Comparison: Real Numbers

Pricing is the most concrete dimension. The numbers below come from RapidAPI listing pages, the X API pricing reference maintained by X, and GetXAPI's published rate card. Where a number is volatile (RapidAPI listings change frequently), the link to the live pricing page is provided.

Per-1,000-Tweet Cost

Source	Per 1,000 tweets	Notes
Official X API v2 (standard reads)	About $5.00	$0.005 per post read on pay-per-use; verify in Developer Console
RapidAPI listing A (popular scraper)	$0.50 to $1.50	Tiered by monthly call volume; see listing page
RapidAPI listing B (unofficial API wrapper)	$1.50 to $3.00	Per-call billing plus result counter
RapidAPI listing C (aggregator)	$2.00 to $5.50	Higher because aggregator pays multiple backends
GetXAPI	$0.05	$0.001 per call, ~20 tweets per call. See pricing

The takeaway is not that every RapidAPI listing is more expensive than GetXAPI by 10x to 100x. It is that the marketplace's cost range is wide and noisy, and that the variance compounds at production volume.

What 100,000 Tweets Per Month Actually Costs

At a realistic mid-size workload of 100,000 tweets per month (a sentiment dashboard for a single brand, a small influencer tracker, or a research tool), the monthly numbers look like this:

Source	Monthly cost at 100K tweets
Official X API v2	$500
RapidAPI listing A	$50 to $150
RapidAPI listing B	$150 to $300
RapidAPI listing C	$200 to $550
GetXAPI	$5

For exact monthly numbers tied to your specific endpoint mix (search vs user lookup vs DM), the cost calculator gives a side-by-side estimate in seconds. Plug in your monthly volume and it shows the breakdown for each operation type.

The Hidden Cost: Failed Calls

A line item that does not appear on the pricing page is the cost of failed calls. RapidAPI listings typically bill against your tier whether the response was successful or not. A 502 from the upstream publisher still consumes your tier allowance. At a 5 percent failure rate, you are paying for 5,000 wasted attempts in every 100,000-call month. GetXAPI's billing model only counts successful responses; failed calls (4xx, 5xx) do not deduct from your credit balance.

Reliability And Uptime

Reliability is harder to compare in dollars but easier to compare in incidents per quarter. The data sources are public:

• RapidAPI listings have consumer review threads on each listing page that surface multi-day outages, and RapidAPI's own status page tracks the marketplace platform separately from the individual listings hosted on it.
• The X API v2 has X's own status page and the Developer Community forum for incident discussion.
• GetXAPI publishes uptime on docs.getxapi.com and operates a single team responsible for both endpoint maintenance and infrastructure.

A typical pattern across 2025 and the first half of 2026, drawn from public review threads:

• Most popular RapidAPI Twitter scraper listings: 3 to 5 multi-day outages per year, usually after X frontend updates. Mean time to recovery 2 to 7 days.
• Mid-tier RapidAPI Twitter listings (unofficial API wrappers): Fewer outages but harder failures when X tightens guest-session policies. Mean time to recovery 1 to 4 weeks.
• Official X API v2: Rare outages, but planned policy changes (like the February 2023 free tier removal and the April 20, 2026 pricing update) require code changes from consumers.
• GetXAPI: Tracked uptime above 99.9 percent across 2026, with maintenance owned by a single team that ships patches server-side without consumer code changes.

The Twitter-API subreddit and adjacent developer forums capture the reliability conversation in real time. Threads on r/webdev, r/SaaS, and r/learnpython regularly surface multi-day RapidAPI Twitter listing outages, with consumers comparing failover strategies and posting migration write-ups to direct APIs. The pattern in those threads is consistent: developers move to RapidAPI for onboarding speed, hit a multi-day outage on a popular listing, then either rotate to another listing or migrate to a direct API. The cycle repeats two to three times before most teams settle on a direct integration.

How The Migration Looks

A migration from a RapidAPI Twitter listing to GetXAPI is a four-step process that typically takes under an hour. The mechanics are mostly identical across languages.

Step 1: Sign Up And Get The Key

Head to the signup page. You get $0.10 in credits (enough for roughly 2,000 tweets) without a credit card. Copy the API key from the dashboard.

Step 2: Swap Headers And Base URL

Before, with RapidAPI:

const res = await fetch(
  "https://twitter-api45.p.rapidapi.com/search.php?query=machine+learning&search_type=Latest",
  {
    headers: {
      "X-RapidAPI-Key": process.env.RAPIDAPI_KEY,
      "X-RapidAPI-Host": "twitter-api45.p.rapidapi.com",
    },
  }
);
const data = await res.json();
const tweets = data.timeline;

After, with GetXAPI:

const res = await fetch(
  "https://api.getxapi.com/twitter/tweet/advanced_search?query=machine+learning&queryType=Latest",
  {
    headers: { Authorization: `Bearer ${process.env.GETXAPI_KEY}` },
  }
);
const data = await res.json();
const tweets = data.tweets;

Three things changed: the host header, the auth header, and the parameter name (query and queryType instead of query and search_type). Everything else is the same fetch pattern.

The equivalent Python migration is just as short. Before, with RapidAPI:

import os
import requests

url = "https://twitter-api45.p.rapidapi.com/search.php"
headers = {
    "X-RapidAPI-Key": os.environ["RAPIDAPI_KEY"],
    "X-RapidAPI-Host": "twitter-api45.p.rapidapi.com",
}
params = {"query": "machine learning", "search_type": "Latest"}
res = requests.get(url, headers=headers, params=params, timeout=15)
tweets = res.json()["timeline"]

After, with GetXAPI:

import os
import requests

url = "https://api.getxapi.com/twitter/tweet/advanced_search"
headers = {"Authorization": f"Bearer {os.environ['GETXAPI_KEY']}"}
params = {"query": "machine learning", "queryType": "Latest"}
res = requests.get(url, headers=headers, params=params, timeout=15)
tweets = res.json()["tweets"]

If you prefer raw curl during the validation pass before touching application code:

curl -s "https://api.getxapi.com/twitter/tweet/advanced_search?query=machine+learning&queryType=Latest" \
  -H "Authorization: Bearer $GETXAPI_KEY" | jq '.tweets | length'

A successful response prints a positive integer (the count of tweets in the page). If you see null or 0, double-check the query string encoding; if you see an HTTP error, the body of the response carries a JSON error field with the reason.

Step 3: Update The Response Parser

RapidAPI listings vary, but a common pattern is a normalized response with the timeline under a top-level array. GetXAPI returns a denormalized response with each tweet carrying its author inline.

Field	Typical RapidAPI listing	GetXAPI
Tweet text	tweets[].text or timeline[].full_text	tweets[].text
Author username	tweets[].user.screen_name	tweets[].author.userName
Author followers	not always included	tweets[].author.followers (inline)
Like count	tweets[].favorite_count	tweets[].likeCount
Retweet count	tweets[].retweet_count	tweets[].retweetCount
Pagination	next_cursor or listing-defined	next_cursor

The pagination model is similar: cursor in, cursor out, follow the cursor until null. Most teams write a small adapter function that maps the RapidAPI shape to their internal Tweet model, then point that adapter at GetXAPI's shape during the migration. Tests pass against both shapes during the cutover window.

A minimal adapter looks like this in JavaScript:

function normalize(tweet, source) {
  if (source === "rapidapi") {
    return {
      id: tweet.id_str || tweet.id,
      text: tweet.text || tweet.full_text,
      author: tweet.user?.screen_name,
      likes: tweet.favorite_count ?? 0,
      retweets: tweet.retweet_count ?? 0,
    };
  }
  // GetXAPI
  return {
    id: tweet.id,
    text: tweet.text,
    author: tweet.author?.userName,
    likes: tweet.likeCount ?? 0,
    retweets: tweet.retweetCount ?? 0,
  };
}

With one function in the codebase, the rest of your application reads normalize(tweet, "getxapi") and never touches a vendor-specific field directly.

Step 4: Strip RapidAPI Plumbing

After the cutover, remove the RapidAPI account headers, the listing-specific retry logic, and any code that handled the listing's quirks (deduplication, schema patching, polling for asynchronous results if the listing supported that pattern). Update your environment variables; delete the RAPIDAPI_KEY and RAPIDAPI_HOST. Drop the RapidAPI subscription once GetXAPI usage is stable in production.

Side Note: Migrating From Marketplace Aggregators

If you used a RapidAPI aggregator listing (one that routes to multiple backends), the migration also simplifies your observability. With the aggregator, errors could come from any of several upstream services and the listing did not always tell you which. With GetXAPI, errors come from one place and follow standard HTTP semantics: 200 is success, 429 is rate-limited (rare on GetXAPI), 4xx is your request, 5xx is the API. Standard error-handling code applies.

For a deeper Python walkthrough of the same migration mechanics applied to async batch jobs, see the Python Twitter API tutorial. For the equivalent migration off the twitterapi.io competitor, see the migration guide.

When RapidAPI Is Still The Right Call

The pitch in this guide is not "always pick GetXAPI over RapidAPI." There are four scenarios where the marketplace surface is genuinely the better fit.

Multi-platform workflows under one billing. If your product pulls Twitter data plus LinkedIn plus Reddit plus weather plus exchange rates, and consolidating five vendors into one marketplace is operationally cleaner than five separate billing relationships, RapidAPI's consolidation has real value. The premium you pay is the cost of that consolidation.

Very low volume. If you call Twitter data 500 times per month for a personal project, the price difference between GetXAPI ($0.025 per month) and a RapidAPI listing free tier ($0 per month if you fit) is irrelevant. Pick whichever is easier to set up. RapidAPI's free tier is often easier.

Listing-specific feature. A few RapidAPI Twitter listings expose niche features that direct APIs do not. If your use case depends on one of those features (some listings, for example, expose historical archives via stitching), staying on RapidAPI is the pragmatic call until a direct provider catches up.

Internal procurement constraints. Some larger companies have a procurement workflow that approves marketplace vendors but not direct vendors. If your finance team requires you to source through a marketplace, that constraint is downstream of engineering choice. RapidAPI is a legitimate option in that environment.

For everything else (production data pipelines, real-time dashboards, customer-facing analytics, anything where downtime costs revenue), a direct API removes a layer of risk that the marketplace adds.

Migration Mistakes To Avoid

Teams switching from a RapidAPI Twitter listing to GetXAPI run into a few predictable mistakes. None are blockers, but each one can extend the migration timeline by a day if missed.

Mistake 1: Keeping the RapidAPI subscription active during the cutover indefinitely. A defensive engineering instinct is to leave the old integration running while the new one stabilizes. That is correct for the first 48 hours. Beyond that, dual-billing eats the savings the migration was supposed to capture. Set a calendar reminder to terminate the RapidAPI subscription 7 days after the GetXAPI cutover, then do it on day 7.

Mistake 2: Not updating retry logic. RapidAPI listings often return a generic 4xx when the upstream publisher's scraper is degraded, which is hard to distinguish from a request error. Teams write defensive retry loops that retry every 4xx. GetXAPI uses standard HTTP status codes: 429 means rate-limited (rare), 4xx means your request has a problem, 5xx means try again. Update your retry logic to only retry 5xx and 429:

def get_with_retry(url, headers, params, max_attempts=3):
    import time, requests
    for attempt in range(max_attempts):
        r = requests.get(url, headers=headers, params=params, timeout=15)
        if r.status_code < 400:
            return r.json()
        if r.status_code in (429, 500, 502, 503, 504):
            time.sleep(2 ** attempt)
            continue
        # 4xx other than 429: caller bug, do not retry
        r.raise_for_status()
    raise RuntimeError(f"giving up after {max_attempts} attempts")

Status codes outside {429, 5xx} bubble up immediately so a malformed query fails loudly instead of consuming the retry budget.

Mistake 3: Underestimating pagination differences. RapidAPI listings vary in how they paginate. Some use a cursor, some use a since_id, some use offset-and-limit. GetXAPI uses a cursor pattern consistently across endpoints. When migrating, take the time to test pagination across the full data range, not just the first page.

Mistake 4: Forgetting to migrate rate-limit handling. If your RapidAPI listing throttled you at 5 requests per second, your code probably has a sleep loop. GetXAPI has no platform-level rate limits, so the sleep loops add latency for no reason. Remove them during the migration.

Mistake 5: Treating GetXAPI like a marketplace API. Marketplace listings get rotated frequently as publishers churn or pricing shifts. GetXAPI is a direct API with a stable contract; you do not need to architect for the case where your provider disappears next quarter. Build for one provider, not for a rotating cast.

What Production Looks Like After Migration

A common pattern across teams that have moved off RapidAPI Twitter listings to GetXAPI in 2025 and 2026:

• Time-to-recover from upstream incidents drops to minutes. Because GetXAPI maintains endpoint health server-side, when X ships a change the patch propagates without consumer code changes. There is no "wait for the publisher to update their scraper" window.
• Monthly costs become forecastable. One counter (calls), one rate ($0.001), one billing relationship. Spreadsheets get simpler.
• Engineering hours on integration maintenance drop. No more weekend incident tickets for "the Twitter scraper listing is throwing 502s again." The team's on-call rotation gets quieter.
• Pricing leverage opens up at scale. Once you cross 1M tweets per month, the GetXAPI team will discuss volume rates. No marketplace fee carve-out, no publisher relationship triangulation.

These improvements are not "GetXAPI is magic." They are the predictable consequences of removing a marketplace layer from a production pipeline. Any direct API with comparable operating discipline would deliver similar improvements. GetXAPI happens to be the lowest-cost direct option in 2026 for Twitter and X data, which is why it shows up at the top of most RapidAPI alternative searches in the first place.

For teams running write workloads (posting tweets, sending DMs, liking and retweeting on behalf of users), GetXAPI handles those endpoints at $0.002 per call. The DM API guide walks through the DM endpoint with sample code. For teams that need to combine GetXAPI with the official X API for specific compliance or OAuth flows, the X API v2 comparison covers when each is the right call.

The community conversation around RapidAPI alternatives has been active on X across 2025 and 2026. Developer threads consistently surface the same questions about response shape, rate limits, pricing at specific volumes, and whether write endpoints exist. Those questions are baked into the GetXAPI best practices guide for new accounts so the migration starts with the right defaults rather than a back-and-forth thread.

Decision Framework

The decision between a RapidAPI Twitter listing and a direct API like GetXAPI comes down to four questions. Answer them honestly and the choice usually resolves itself.

1. Is Twitter data going through a paid product? If yes, the marketplace risk model is harder to justify. Move to a direct API. If no (personal project, internal tool, research script), the marketplace is fine.
2. Is your monthly volume above 10,000 tweets? If yes, the pricing gap between RapidAPI listings and GetXAPI starts to matter. At 100,000 tweets per month the gap is 10x to 100x. If no (under 10,000 tweets per month), the dollar difference is small enough that either option is workable.
3. Do you need write endpoints (post, DM, like, retweet)? Most RapidAPI Twitter listings are read-only. Direct APIs (the official X API v2 and GetXAPI) offer write endpoints. If your product needs to post, GetXAPI is the simpler path at $0.002 per write call.
4. Are you OK with publisher-owned uptime? If your service can absorb a 2 to 7 day outage on Twitter data without losing customers, RapidAPI's marketplace model is fine. If not, move to a direct API where one team owns endpoint health.

Most teams running production traffic answer "yes, yes, sometimes, no" to those four questions, which lands them on a direct API. GetXAPI is the lowest-cost direct option in the Twitter and X category, which is why it surfaces as the most common RapidAPI alternative.

Bottom Line

RapidAPI is a solid onboarding surface for Twitter data. The marketplace gets you a working API integration in five minutes, gives you a uniform auth pattern across many APIs, and consolidates billing into one relationship. Those benefits are real.

The same marketplace layer becomes a liability once your service has paying customers. You inherit publisher reliability without recourse, you pay a marketplace markup on top of the publisher's rate, you cannot negotiate pricing as you scale, and you absorb schema drift without a versioned changelog.

A direct API removes those four risks. For Twitter data specifically, GetXAPI is the most affordable direct option in 2026, with $0.05 per 1,000 tweets, sub-2-second responses, no platform-level rate limits, and an auth model that is one header. The migration from a RapidAPI Twitter listing typically takes under an hour. The savings show up on the first monthly invoice, and the reliability dividend shows up the next time X ships a frontend change.

Get your API key and try GetXAPI free with $0.10 in starter credits. No credit card required. For specific endpoint patterns covered in detail, the advanced search operators guide walks through the full query syntax, and the Python Twitter API tutorial has running code samples for every endpoint.