TwitterAPIs vs Apify: Compute Units, Credit Expiry, and Real Cost

Every price lives in the OpenAPI spec, not just this page

The prices quoted on this page are not marketing copy that could quietly drift from what your account is actually billed. Every one of our 109 endpoints carries its own price as an x-cost-usd field inside the published OpenAPI document, so a client library, an internal cost dashboard, or a procurement review can read the exact rate for a specific call before making it, straight from the same machine-readable contract that generates our docs. There is nowhere for the number on this page and the number your integration actually pays to diverge, because they come from the same file.

Apify has no equivalent for a specific Actor, because an Actor's effective price depends on how it was written, not on a rate the platform publishes per-endpoint. Two Actors doing the same job can carry two different effective prices with nothing in a spec to tell you which one you are about to run.

Feature Comparison Table

The row that matters most is the second one. Everything else follows from it.

What it costs in three real patterns

Usage shape decides the winner more than the headline rate does.

Where Apify is genuinely the better tool

Apify is a platform, not a Twitter product, and that is its actual strength. If you need twenty unrelated sources, an e-commerce catalog, a maps listing and a job board alongside social data, running all of it on one platform with one billing relationship is worth real money in saved integration time. Its Actor catalog is large and its scheduling and storage are solid. Nothing on this page argues otherwise.

The trade shows up when Twitter and X are the data you actually need. Then you are paying platform prices for one target, your endpoint surface is whatever the Actor author decided to expose, and when Twitter changes something you wait for that author to notice. A first-party API takes that maintenance risk off your desk.

Is Apify good for beginners?

For someone who has never written an API client, yes, and more so than we are. You can run an Actor from the Apify Console without writing any code, the Store listed 67,620 Actors when we checked on 5 September 2026, and Apify Academy is a free course that teaches the platform properly. We are an HTTP API and nothing else. If you are not comfortable sending a request and reading JSON back, you will get to a first result faster on Apify than on us, and we would rather tell you that than pretend a terminal is a friendly on-ramp.

The place beginners get caught is the bill, not the interface. Apify meters compute units at $0.2 per unit on the Free and Starter plans, where a unit is one gigabyte of RAM for one hour, so the cost of a run depends on how long somebody else's Actor takes and how much memory it asked for. That is knowable afterwards, from the billing screen, rather than before, from the docs. Our price per call ships inside the published OpenAPI document as an x-cost-usd field, so the arithmetic for a job is available before you run it. Neither model is dishonest. One of them is easier to predict on your first week.

Is there a free Apify alternative?

Apify already has a free plan, and on size alone it beats ours. Read from apify.com/pricing on 5 September 2026, it is $0 a month carrying $5 of prepaid platform usage, and that $5 renews every billing cycle. Our free credit is $0.50 at signup with no card, which is about 625 calls at $0.0008. Ten times a recurring allowance is a real advantage and we are not going to argue it away.

Two conditions decide whether that advantage survives contact with your project. Apify's own pricing FAQ states that unused usage credits are not rolled over and expire at the end of the billing cycle, and that a free-plan account is blocked until the next cycle once the prepaid amount is spent. So the $5 is a monthly budget that resets whether or not you used it, and running out mid-month stops the account rather than charging overage. Our $0.50 does not expire and does not renew: it sits there until you spend it, and topping up starts at $10 with no plan attached. If you are evaluating on and off across a few months, a credit that waits for you is worth more than a larger one that resets. If you are working steadily every month, $5 a month is simply more free usage than $0.50 once.

What changed in 2026

One number on this page moved between our August and September readings, and it moved in Apify's favour. Starter was $29 a month when we first priced this comparison on 6 August 2026. On 5 September 2026 apify.com/pricing lists it at $19 a month with $19 of included usage, so the entry price for a paid Apify plan fell by roughly a third. Every figure on this page now reflects the lower number.

What did not move: Scale is still $199 a month, Business is still $999, compute is still $0.2 per unit on Free and Starter, and the rule that unused prepaid usage expires at the end of the billing cycle is unchanged. The structural comparison is therefore the same as it was. A cheaper entry plan makes the first month easier and does not change what a compute unit is or when your allowance disappears.

The practical advice is the one we would give about any comparison page including this one: a competitor's price is only as current as the day somebody last opened their pricing page. Ours is dated in the box above. Check theirs before you commit, because we will not always catch a change the week it happens.

Real-time capabilities

Apify Actors run on a schedule or on demand. There is no push notification when a watched account posts; you decide how often to trigger a run, and each trigger is a fresh billable job that spins up, does its work and shuts down. Watching an account continuously means scheduling frequent runs and accepting the compute cost of each one, or building your own polling loop around the Actor.

TwitterAPIs has a dedicated, zero-rated push path instead of a polling loop you build yourself: register a webhook and a monitor and we watch the account for you. Detection runs on a shared poll interval currently around 60 seconds, and delivery, the time from us seeing the post to our signed POST landing on your endpoint, was about 3.6 seconds on a real production event we measured after shipping the feature, for roughly 38 seconds end to end. Creating the webhook and the monitor is free; watching more than one account at a time needs a monitoring plan starting at $15/mo, a flat subscription layered on top of the per-call model rather than replacing it. This is a fast-polling architecture, not a sub-second firehose, but it removes the loop-building and the extra compute cost Apify's schedule-a-run model requires for the same job.

What does 1,000 profiles actually cost?

On TwitterAPIs, a profile lookup is a standard-tier read at $0.0008 per call, so 1,000 profiles is $0.80, flat, regardless of how large or how quiet each profile is. The number does not move if a profile has 3 tweets or 30,000.

On Apify, the same 1,000 profiles do not have a fixed price, because the meter is RAM-time, not results. A lightweight Actor holding a small amount of memory for a short run and a heavier one that loads a browser to render each profile can bill very differently for an identical 1,000-profile output. As an illustration using Apify's own published unit (1 CU = 1 GB of RAM for 1 hour): a modest 512 MB Actor that spends 3 seconds per profile burns roughly 0.417 CU across 1,000 profiles, and Apify prices compute starting near $0.40/CU on paid plans, so a well-optimized run might land under $0.20 in raw compute, before the $19/mo plan fee that compute draws down against. A heavier, browser-based Actor at 2 GB of RAM and 8 seconds per profile burns roughly 4.4 CU for the same 1,000 profiles, several times the lightweight case, for identical output. Which end you land on depends on an Actor you did not write and generally cannot see the internals of.

The real per-1,000-tweets price floor

Every price below is sourced from our own head-to-head pages against each vendor, not a third-party summary, and each one carries the caveat that actually decides your real cost.

1. TwitterAPIs: the floor at $0.04 per 1,000 tweets, modelled on a full 20-tweet page from a single $0.0008 call. It is a modelled figure, not a per-item price: our own billing logs put real delivered pages closer to 8 to 13 tweets, which puts actual cost nearer $0.06 to $0.11 per 1,000 depending on query type. See the SocialData comparison for the full breakdown of that gap.
2. Apify: no per-tweet floor exists, because the meter is compute time, not items. See the compute-unit breakdown above and below for why an identical 1,000-tweet job can land anywhere across a wide range depending on the Actor.
3. SocialData.tools: a flat $0.20 per 1,000 tweets or profiles ($0.0002 per item), with one expensive exception, its extended-bio lookup runs 5x the standard item rate. See TwitterAPIs vs SocialData.tools for the full rate card.
4. TweetAPI.com: subscription tiers from roughly $0.10 to $0.17 per 1,000 requests depending on which tier you buy, and the effective rate moves as you cross tier boundaries rather than staying flat. See TwitterAPIs vs TweetAPI.com for the tier table.

Apify Pricing Plans in 2026

Apify sells access as a monthly plan, not a pay-as-you-go meter, and the plan is what determines how much compute you have before you pay overage. The Free plan includes $5 of usage a month, enough for light, occasional runs. Starter is $19/mo, and Scale is $199/mo, each including a larger compute allowance that draws down as your Actors run. All figures on this page were read from apify.com/pricing on 6 August 2026; check the live page before committing, since plan pricing moves.

The plan fee is a floor, not a cap: once a month's included compute is used up, further runs bill at Apify's per-CU overage rate on top of the flat fee you already paid. That is the mechanic behind the "Spiky usage" row in the cost table above, a quiet month still bills the plan fee even though the Actor barely ran.

Compute Units: the Core Meter

Everything about Apify's bill traces back to one definition: 1 compute unit (CU) is 1 GB of RAM running for 1 hour. That single number decides your cost regardless of what the Actor is actually doing, which means three things follow directly from it. First, memory allocation matters as much as runtime: an Actor configured for 2 GB of RAM burns CU twice as fast as one configured for 1 GB, doing identical work. Second, wall-clock time is billed time: a slow page load, a retry, or a rate-limit backoff inside the Actor all burn CU while producing nothing. Third, because the meter has nothing to do with rows returned, two runs that produce byte-identical output can bill differently if one Actor is written more efficiently than the other.

TwitterAPIs has no equivalent unit to reason about. A call costs $0.0008 whether it finishes in 50 milliseconds or 5 seconds, and whether Twitter is fast or having a slow day is our operating problem, never a line item on your invoice.

Apify's billing model

Apify bills by Compute Unit, a blended measure of CPU, RAM and runtime that only makes sense once you have run an Actor and read the invoice line by line. A CU is not a call and it is not a row of data; it is compute-time consumed regardless of whether the run returns one tweet or ten thousand, which is why two runs that pull identical data can bill differently depending on how the Actor is tuned, how many retries the target forced, and how much memory was allocated. That is a reasonable model for a platform selling general-purpose compute across hundreds of different Actors. It is a hard model to forecast against for a team that only wants Twitter data and has no reason to reason about compute allocation at all.

TwitterAPIs prices per call, not per compute-second, so the number on the invoice is the same number you could have predicted before the run: 109 endpoints, each with a fixed x-cost-usd, paid only when a call actually returns data.

Datacenter proxy

A scraping platform without its own IP reputation problem does not exist, and Apify's answer is a proxy marketplace layered on top of Actor runs: datacenter proxies for the cheapest, most block-prone tier, and residential or mobile proxies priced well above the base Compute Unit rate when a target pushes back hard enough to need them. That is a real, often necessary cost for a general scraper hitting an anti-bot wall, and it is billed separately from the compute that runs the Actor itself, which is the detail that turns a plausible CU estimate into a surprising one.

TwitterAPIs has no equivalent line item, because the IP-reputation and rate-limit problem is ours to own on the backend rather than a proxy tier you select and pay for per request. That is the same "who owns the anti-bot wall" split covered above under reliability, restated here specifically because it is where a side-by-side cost estimate most often goes wrong: a fair Apify quote for a Twitter Actor almost always needs a proxy tier added on top of the base CU rate, and a quote that skips that step understates Apify's real cost.

Hidden costs and gotchas

On Apify, the gotcha is usually memory sizing: an Actor left at a default 2 GB allocation to be safe burns CU twice as fast as one tuned to 1 GB, for the same output, and most builders never revisit that setting once a scraper is running. A second one is retries: a flaky target that makes an Actor retry or wait burns billable RAM-time for zero new data, and that cost is invisible until the invoice arrives.

On TwitterAPIs, the equivalent gotcha is tier mismatch rather than compute variance: of our 109 endpoints, 62 bill at the standard $0.0008 rate, 24 are free, and the remaining 23 sit between $0.0016 and $0.01 for heavier operations (writes, article management, and a handful of premium reads). Assuming every call costs the standard rate before checking the specific endpoint's x-cost-usd field in the OpenAPI spec is the mistake that makes an estimate wrong, in either direction.

TL;DR: who each product is for

If you only read one section, read this one. Neither product is trying to beat the other at its own job.

The one-line version: Apify sells a platform for building scrapers, we sell finished Twitter data. If the scraper is the product you want, the rest of this page will not change your mind and should not.

Reliability, rate limits and anti-bot risk

Every product in this category sits behind the same wall: X does not want to be scraped at volume, and it changes the wall regularly. The difference between the two options here is not whether that problem exists, it is who owns it.

On Apify you are running an Actor, and the Actor is code, either yours or a publisher's. When X changes a page structure or tightens detection, the Actor is what breaks, and the fix arrives when its author ships one. That is not a criticism of the model, it is the model: you have the source, so you can also fix it yourself, which is exactly why some teams choose it. It does mean that reliability is a property of the specific Actor you picked rather than of the platform, so check its maintenance history before you depend on it.

On our side that maintenance is the product, and the honest way to say it is that you are trading control for not having to care. You cannot patch our extractor when X moves; we can, and until we do you are waiting. What you get in exchange is that a broken week is our incident rather than your on-call.

Rate limits work differently too. Ours is one flat ceiling, 600 requests a minute, and it does not change with what you pay. On Apify, throughput is a function of how many Actor runs your plan lets you hold concurrently and how much memory each one is allocated, so raising throughput usually means raising the bill in a way that is hard to predict in advance.

The risk both models share, and the one to actually test for, is a run that succeeds and returns less than it should. A scraper that gets a partial page does not always know it. Whichever side you pick, reconcile against a couple of accounts whose real numbers you can check by hand before you trust a pipeline built on either.

MCP server

TwitterAPIs ships a first-party MCP server with tools mapped one-to-one onto the REST endpoints, so an agent using Claude, ChatGPT, or any other MCP client reaches the full Twitter surface, search, timelines, DMs, media upload, monitors, without a custom integration layer in between. That matters specifically for the agentic use case this comparison keeps returning to: an agent choosing calls at run time needs a tool list it can reason over directly, not a scraper it has to shell out to and parse the output of.

Apify's agent story runs through its Actor model instead: an MCP client can reach whichever Actor is wired up as a tool, which works well for the platform's stated pitch of one orchestration layer across many scrapers, but it means the tool surface an agent sees is only as consistent as the specific Actor selected, not a single documented contract the way a first-party API is.

The marketplace problem

Apify's Twitter Actors are built and maintained by third-party developers on the Apify Store, not by Apify itself, which is the same marketplace model that makes the platform genuinely useful across hundreds of unrelated targets. The tradeoff is that quality, maintenance cadence, and how quickly an Actor gets patched after X changes something all vary Actor to Actor, and a run that broke last week because the maintainer has not shipped a fix yet is a support ticket you file with a third party, not with Apify.

TwitterAPIs owns the Twitter integration end to end, so a break in X's own behavior is our incident to fix, not a queue item waiting on an independent maintainer's schedule. That ownership is also why the pricing above can be a fixed per-call rate rather than a compute estimate: we control the whole path from request to response.

Who should use Apify

We would rather name the cases where Apify is the right buy than pretend there are none, because a comparison page that never concedes anything is not worth reading. There are four, and they are common.

• Multi-source pipelines. If you are already pulling LinkedIn, Instagram, Google Maps and Twitter, one platform with one scheduler, one storage layer and one billing relationship is worth real money in operational overhead, and we cannot offer that at any price.
• Custom extraction logic. When you need a field nobody exposes as an endpoint, or a traversal pattern specific to your product, writing an Actor is the direct route. A fixed API is by definition the set of questions someone else decided to answer.
• Heavy, predictable batch work. A monthly plan with included compute is cheaper than metered billing when the meter would run continuously and your runs are well tuned. Predictability is the condition, not volume on its own.
• Teams that want the source. Some organisations will not depend on a black box for a core input, and that is a legitimate engineering position rather than a preference to be argued out of.

Where it goes wrong is the fifth case, which is the one nobody plans for: Twitter is the only source, the volume is small and irregular, and the plan fee bills every month whether the Actor ran or not. That is the shape this comparison exists for.

Check out similar blogs

For more detail than a head-to-head page can carry, two of our posts go deeper on exactly this pair and this category:

• Apify Twitter Scraper vs TwitterAPIs: The Real 2026 Numbers , a 60-minute bake-off you can run yourself, plus latency and failure-mode data this page does not cover.
• Cheapest Twitter API 2026: 8 Providers Ranked by Real Per-1,000-Tweet Cost , where Apify and every vendor mentioned on this page lands once billing traps are priced in, not just the headline rate.

What are the main alternatives to the Twitter/X API?

Beyond TwitterAPIs and Apify, builders getting Twitter/X data generally choose from four shapes of provider: X's own official API (the source of truth, but gated behind developer-account approval and enterprise-tier pricing for serious volume), general scraping platforms like Apify (broad target coverage, usage-based compute pricing), dedicated third-party Twitter/X APIs (first-party endpoint contracts at per-call prices, the category TwitterAPIs is in), and raw-HTML scraping services that hand you a page and leave the parsing to you. Which one wins depends on whether you need one target done well and cheaply, or many unrelated targets under one bill.

We keep a full Twitter API alternatives roundup covering every vendor we have priced in one table, and dedicated head-to-heads against Scrapingdog, Scrape.do and Bright Data if Apify is not the specific comparison you came here for.

How do you migrate from the official X API?

The official X API v2 gates most useful access behind a developer-account application, an app-review process, and Enterprise-tier pricing for real volume, which is the friction that sends builders looking at TwitterAPIs and Apify in the first place. Moving off it is mostly a mapping exercise rather than a rewrite: GET /2/users/by/username/:username becomes our GET /twitter/user/info, GET /2/tweets/search/recent becomes GET /twitter/tweet/advanced_search, and account-activity webhooks map onto the webhook and monitor endpoints described above. The practical difference is the gate at the front: a TwitterAPIs Bearer token issues after a 30-second signup with no developer application and no app review, so the migration's hard part is usually relabeling request shapes in your existing client code, not clearing a new approval process.

Migrating from Apify is a different shape of change: you are moving from Actor-run orchestration (trigger a job, poll for its result, parse whatever shape that Actor returns) to direct typed HTTP calls with a fixed response contract. Most teams find that removes code rather than adding it, since there is no run-status polling loop and no per-Actor response schema to normalize.

Why $0.50 never expires

New TwitterAPIs accounts start with $0.50 in credits and no card on file. That balance sits on the account with no clock attached to it: no billing cycle resets it, no inactivity window burns it, and it is still spendable months later if you sign up, test one call, and come back. Compare that to a platform where unused usage resets every cycle, and the difference is not the dollar amount, it is whether a slow start costs you the credit you were given.

The 38-second production measurement

Most vendors state a webhook or monitoring architecture in the abstract. We measured ours on a real production event after shipping the feature: about 34 seconds to detect a new post on the shared poll interval, then about 3.6 seconds for our signed POST to land on the receiving endpoint, for roughly 38 seconds end to end. That is a real number from one real event, not a marketed ceiling, and it is the number to compare against if you are timing how fast you would actually find out about a new post either way.

One call, one price

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://api.twitterapis.com/twitter/user/tweets?username=jack&count=20"

# $0.0008 for this call, every time.
# The price does not move with response size or run duration.

Other comparisons worth reading

Each vendor loses on a different axis, so the one that matters depends on how you buy. These three cover the rest of the field.

• TwitterAPIs vs Scrapingdog , the 5x Twitter credit multiplier.
• TwitterAPIs vs Scrape.do , raw pages against typed data.
• TwitterAPIs vs SociaVault , credit packs against a flat per-call rate.
• TwitterAPIs vs Bright Data , async webhook delivery against a synchronous call.
• The full Twitter API alternatives roundup , every vendor we have priced, in one table.

Frequently asked questions