TwitterAPIs vs GetXAPI

// PRICING

Pricing

Pay-as-you-go rates, side by side.

GetXAPI figures as published on 21 July 2026. How to read the per-1,000 rows: both services bill per call, and both publish a per-1,000-tweet figure derived by assuming a full 20-tweet page, so this comparison is like for like. Neither per-1,000 figure is a billed rate. Measured across 396,817 of our own read calls, pages average fewer than 20 tweets, which lifts the real cost per 1,000 on both services by the same mechanism. The numbers you are actually charged are the per-call rates, $0.0008 against their $0.001.

What the Gap Costs at Volume

On pay-as-you-go the difference is one cent per 1,000 tweets, so it stays small until throughput rises. Below is what it adds up to. Their monthly plans change this picture, and the next section covers that.

// THE CAVEAT

Their Monthly Plans Undercut Our Flat Rate

The 20% gap above is the pay-as-you-go comparison, and it is the one most teams start on. GetXAPI also sells monthly plans that bundle bonus credits, which pushes their effective rate below our flat $0.0008. Here is that comparison in the unit their own pricing page uses, cost per 1,000 standard calls, as published on 21 July 2026.

One more thing in their favour that the table does not show: they add bonus credit when you pay in crypto, which on the $99 plan works out near $0.28 per 1,000 calls. That is the lowest published figure on either side, and if a monthly plan suits you it is the number to beat.

Read that honestly: from their $15 plan upward, their credits cost less per call than ours. What you take on in exchange is a monthly commitment and credits that renew on a cycle rather than sitting there until you spend them. Our $0.0008 needs no plan, no minimum, and no forecast of next month's volume. If your throughput is steady and large enough to consume a plan every month, their plan pricing is the better deal and you should take it. If your volume moves around, or you would rather not predict it, the flat rate is the cheaper choice in practice.

// SIDE BY SIDE

How the Two Services Line Up

// MIGRATION

Moving Across Takes One Parameter Rename

Search is the endpoint most teams call first, and the two services agree on almost every part of it: the same path, the same bearer auth header, the same Latest and Top product values, and the same cursor pagination. The search parameter name is the one thing that differs. GetXAPI sends it as q. TwitterAPIs reads it as query, and returns a 400 with a missing-parameter message if it is absent.

const params = new URLSearchParams({
  q: "from:elonmusk",        // <- their parameter name
  product: "Latest",
});

const response = await fetch(
  `https://api.getxapi.com/twitter/tweet/advanced_search?${params}`,
  { headers: { Authorization: `Bearer ${apiKey}` } }
);

const params = new URLSearchParams({
  query: "from:elonmusk",    // <- the only rename: q becomes query
  product: "Latest",
});

const response = await fetch(
  `https://api.twitterapis.com/twitter/tweet/advanced_search?${params}`,
  { headers: { Authorization: `Bearer ${apiKey}` } }
);

Beyond search, most parameter names port across untouched, because TwitterAPIs already accepts a set of competitor spellings without you having to change them. Send userName and we read it as username. Send tweetId and we read it as id. Send pageSize and we read it as count. Send queryType and we read it as product. The search parameter is the one that is not aliased, which is why it is the rename worth knowing about.

What GetXAPI Does Better

The Endpoints Most Alternatives Skip

A low-cost Twitter/X reseller usually covers the read-heavy core well: search, timelines, profiles, followers, DMs. Where they thin out is everything past that core. GetXAPI's own 73-endpoint price list, read on 28 August 2026, is a clean example, and every line below is checked against our own OpenAPI document rather than asserted.

None of this erases GetXAPI's own two real advantages, joining a community and downloading Space audio with a transcript, covered above. It does mean that once you look past tweet search and profile lookups, the two catalogs stop matching feature for feature, and the direction of that gap runs toward TwitterAPIs on every family in this table.

How We Checked These Numbers

Our own rates are generated from the same pricing configuration that our biller charges against, so the figures on this page cannot drift from what you are actually billed. GetXAPI's rates were read directly from their published pages on 21 July 2026: their homepage and pricing page for the per-call and per-1,000 figures, and their advanced search documentation for the parameter names, the product values, and the roughly 20 tweets per call. We did not take any of their figures from a third-party summary. Their endpoint count and catalog (the table above) were re-read separately on 28 August 2026, because a provider's endpoint list changes on its own release cadence and can drift out of sync with its pricing figures. They are an independent company and control their own pricing and catalog, so treat every number attributed to them here as accurate on the date beside it and worth re-checking on yours.

Writes, pricing models and other per-call APIs

Write workflows

Reading is most of the traffic, but agents and schedulers also write. On TwitterAPIs a like, retweet, bookmark or follow, and each undo, is $0.0008 per call, and creating a tweet is $0.0016, all on the same key as your reads. Before you move a write workflow, check that each action you need is on the provider's price list: GetXAPI's page listed 73 endpoints when we read it, and the endpoint table above shows the families it did not carry.

Usage-based pricing against monthly plans

Both providers bill usage per call. The difference is what sits on top: GetXAPI also sells monthly plans with bonus credits, which lower their effective rate for steady volume, while TwitterAPIs has one metered rate and no plan. Usage-based billing wins when volume moves month to month; a plan wins when you will spend its full allowance every month. Price both against the calls you actually made last month.

Other pay-per-call Twitter APIs

GetXAPI is one of several providers that bill per call or per item for X data, each with its own trade-off between price, coverage and limits. We compare the rest on the same terms: TwitterAPI.io, TweetAPI, TwexAPI, SociaVault and SocialData.

// SWITCHING KIT

Running both side by side before you switch

Most teams do not cut over in one go. They point a share of traffic at the second provider, compare what comes back, and move the rest once the numbers hold. Everything below is what that week of running both looks like: the per-type cost, the one request to send to each, the limits you will hit, a small adapter so the same code calls either service, and the checklist we would follow ourselves.

Cost per 1,000 by data type

A per-call price only becomes comparable once you know how much data one call returns, so here are the common data types priced per 1,000 units. Our column comes from our published pricing; theirs is from their pricing page as read on 21 July 2026, and the tweet rows assume a full page of about 20 tweets per call on both services.

These are pay-as-you-go rates. On one of their monthly plans the effective per-call figure drops, as the plan table above shows, so price your own mix against the plan you would actually buy.

The same request on both

Send one advanced search for the same query to each service and compare three things: tweets returned, fields present, and what the call cost. One search call is $0.0008 on TwitterAPIs and $0.001 on GetXAPI at their pay-as-you-go rate, so the same 1,000 searches cost $0.8 and $1. The request itself is the one shown in the migration section: same path, same bearer header, and only the search parameter renamed from q to query.

Rate limits in practice

TwitterAPIs allows 600 requests a minute and 20 concurrent requests per key, with no monthly cap, as stated on our rate limits page. GetXAPI's homepage FAQ, read on 15 October 2026, says it has no endpoint-specific quota and no 15-minute windows, and that sustained concurrency can still return a 429. Neither service applies X's per-endpoint windows, so the limit you actually plan around is per-key throughput. Wrap long backfills in a retry with backoff on either provider. On our side, the status page runs a live probe you can poll from your own monitoring.

One adapter for either provider

Because the two search requests differ only in base URL and one parameter name, a small adapter lets the same code call either service. That is what makes a side-by-side week cheap: flip the provider per request, log both responses, and diff them.

type Provider = { baseUrl: string; queryParam: "q" | "query"; apiKey: string };

const providers: Record<"getxapi" | "twitterapis", Provider> = {
  getxapi: { baseUrl: "https://api.getxapi.com", queryParam: "q", apiKey: process.env.GX_KEY! },
  twitterapis: { baseUrl: "https://api.twitterapis.com", queryParam: "query", apiKey: process.env.TA_KEY! },
};

export async function search(name: keyof typeof providers, text: string, cursor?: string) {
  const p = providers[name];
  const params = new URLSearchParams({ [p.queryParam]: text, product: "Latest" });
  if (cursor) params.set("cursor", cursor);
  const res = await fetch(`${p.baseUrl}/twitter/tweet/advanced_search?${params}`, {
    headers: { Authorization: `Bearer ${p.apiKey}` },
  });
  if (!res.ok) throw new Error(`${name} search failed: ${res.status}`);
  return res.json();
}

Switching checklist

1. List every endpoint you call today and confirm each one is in our catalog of 121 endpoints.
2. Rename q to query on search, then check every other parameter you send against our endpoint reference.
3. Swap the base URL and the bearer key, using the free $0.5 credit for the first runs.
4. Run both providers on the same inputs for a few days and diff the fields you consume.
5. Check your retry logic against 429 responses at your real concurrency.
6. Price last month's actual call mix on both, including any write and DM calls.
7. Move the remaining traffic, then remove the old key once nothing calls it.

Related repositories

Our MCP server is open source at github.com/TwitterAPIs/twitterapis-mcp and published on npm as @twitterapis/mcp, so an agent can call the same endpoints this page prices. The full API contract, with an x-cost-usd price on each endpoint, is the OpenAPI document, which most code generators read directly. We do not maintain a client for GetXAPI; the adapter above is the only glue the comparison needs.

Links

• TwitterAPIs pricing, the rates every figure on this page is generated from.
• TwitterAPIs documentation, endpoint by endpoint.
• Rate limits, per key and per endpoint.
• GetXAPI's homepage, pricing page and advanced search documentation, the sources for every figure attributed to them above, read on the dates stated.