Make.com Pricing in 2026: Plans, Credits and What a Twitter (X) Workflow Really Costs

Make has one free plan, three self-serve paid plans and Enterprise. All paid plans share the same model: you pick a monthly credit tier, and the price follows the tier. The lowest entry point on each plan is the 10,000-credit tier.

What the paid plans add, per Make's comparison table. Core: unlimited active scenarios, scheduling down to 1 minute, access to the Make API (60 calls a minute), 40-minute maximum scenario run time, 100 MB files, 30-day execution logs. Pro adds high-priority execution, custom variables, full-text execution log search, 250 MB files and 120 API calls a minute. Teams adds teams and team roles, shareable scenario templates, 500 MB files and 240 API calls a minute. Enterprise adds custom functions, enterprise apps, overage protection, 24/7 support, 1,000 MB files, 60-day logs and 1,000 API calls a minute.

What Free leaves out. The Free plan allows 2 active scenarios, a 15-minute minimum interval between scheduled runs, a 5-minute maximum run time, 5 MB files, 7-day logs and no Make API. The 15-minute floor and the 1,000-credit allowance are the two limits that matter most for any polling workflow, as the study below shows.

Code and AI. The Make Code app (JavaScript or Python inside a scenario) is listed on every paid plan at 2 credits per 1 second of code execution time. Make AI Agents and the AI Toolkit can run on Make's AI Provider on all plans, where credits are based on tokens and operations; bringing your own LLM key is marked Pro and above on the single-plan version of the table, and Make's November 6, 2025 plan adjustment opened custom AI provider connections to all paid plans.

The slider on Make's pricing page walks through these tiers. Monthly billing gives you that many credits every month. Yearly billing works differently by plan: Core keeps a monthly allowance even on a yearly subscription, while Pro and Teams on yearly billing get one annual pool (for example 120,000 credits for the year) that you can spend unevenly across months, per Make's help article on monthly and annual subscriptions.

Pro and Teams yearly pools. Pro yearly runs from 120,000 credits for $252 to 96 million credits for $75,060 a year; Teams yearly from 120,000 credits for $456 to 96 million for $128,400 a year. Per credit, Pro 10K monthly works out to $0.0028 and Pro 120K yearly to $0.0021, both as returned in the pricePerCredit field of Make's price list.

Outside the US the list changes above 20,000 credits. The default list returned for a non-US country (we asked for Germany) has the same 10K and 20K prices, then drops faster: Core 40K $46 instead of $51, Core 300K $236 instead of $321, Pro 1M $969 instead of $1,321. All amounts on both lists are in USD.

India and Australia see one plan. For those countries Make's page code requests the single-plan variant, which returned a 'Make Plan' from $10.59/month for 5,000 credits ($18.82/month for 10,000) and $108 a year for 60,000 credits. Its card lists unlimited active scenarios, credit usage flexibility, 300+ Make API endpoints, high-priority execution, custom variables, log search, teams and roles and enterprise apps in one plan, with Enterprise above it.

Why third-party articles quote $9. Many pricing write-ups still list Core at $9/month, Pro $16 and Teams $29 for 10,000 credits on yearly billing. Make's own extra-credits help article still uses a '$9 plan with 10,000 credits' as its worked example. Those figures did not match the price list Make's pricing page loaded this session, so check the slider for your country before you budget.

Credits replaced operations as Make's billing unit; Make's pricing FAQ dates the switch to August 27, and its credits article says existing plans and prices did not change with the rename. For non-AI apps, 1 operation equals 1 credit, so 'make pricing operations' and 'make.com credits' are now the same question.

An operation is one module run. Make's operations article: each module runs once per bundle it processes, so a module that sends 5 emails is 5 operations. Bundles multiply down the scenario: if the first module returns 10 items, every later module runs 10 times.

Triggers are the exception, and the trap. A trigger runs once per check, regardless of how many bundles it returns, and it still runs when there is nothing new. Make's own example: Google Sheets Watch New Rows checking for new rows is 1 operation per check. That is why a schedule, not your data volume, sets the minimum bill.

What uses more than 1 credit. Modules on Make's AI Provider use credits based on tokens and operations; some AI Content Extractor modules use 2 or 10 credits per operation and are tagged in the editor; the Code app uses 2 credits per second of execution time. Third-party AI apps (OpenAI, Anthropic Claude, Gemini) on your own connection count 1 credit per operation.

What uses no credits. Make's pricing FAQ lists routers and the error-handler directives (Rollback, Break, Resume, Commit, Ignore) as free. Filters between modules decide whether the next module runs; the next module only costs a credit if it runs.

Running out, extra credits and the 25% surcharge. When a plan's credits run out, Make stops running scenarios until you add credits; incoming webhooks queue up to your queue limit, and polling triggers pick up records since their last successful run. You can upgrade the tier, buy extra credits in bundles of 1,000 or 10,000, or turn on auto-purchasing of 10,000 credits (Core, Pro and Teams only, limited to the number of credits in your subscription). Since Make's November 6, 2025 adjustment, manual and automatic extra credits both include a 25% additional cost over your plan's per-credit price (auto-purchase used to carry 30%, manual top-ups none). On Core 10K at $16/month a credit costs $0.0016, so an extra 10,000-credit bundle costs about $20, more than the plan itself; Make's own advice is to move up a tier if you top up regularly.

Expiry and discounts. Plan credits expire at the end of the term. Extra credits expire after one month on monthly billing, or at the end of the year on yearly Pro and Teams. On a downgrade, unused credits carry over for one month or one year depending on the billing cycle. Yearly prepayment is cheaper than monthly (US list: Core 10K $144 a year vs 12 x $16 = $192). Companies under 20 employees can apply for the Start-up Plan, which Make advertises as 50% off its Business offer; nonprofits are asked to contact Make.

Allowances that scale with credits. Every 10,000 licensed credits a month entitles you to 5 GB of data transfer, 10 MB of data storage, 10 MB of incomplete-execution storage and a 667-item webhook queue (10,000 items maximum). Running out of data transfer can trigger an extra-credit auto-purchase even when credits remain, per Make's extra-credits article.

The credit rules above make one prediction: for a scheduled scenario, the schedule matters more than the data. We tested that on a real workload. A common Make job is to watch an X (Twitter) account and copy each new post into Google Sheets or Slack. The scenario is a schedule, an HTTP module that asks an X data API for posts since the last run, an Iterator that splits the response into posts, and one action module per post.

We pulled the recent timelines of 10 public organization accounts with very different posting rates, from Make's own @make_hq to @Reuters, kept original posts (a from: search skips reposts), and replayed them against 1, 5, 15 and 60-minute schedules. Per run the scenario costs 1 credit for HTTP, 1 for the Iterator and 1 per post for the action. At 15 minutes the results were:

The floor dominates. Nine of ten accounts cost between 5,771 and 6,321 credits at 15 minutes, and 5,760 of those are the fixed 2 credits on each of 2,880 runs. For the median account, 97.6% of the credits went to runs that found nothing new. Only @Reuters, at 264.32 original posts a day in our window, pushes past Core 10K, to 13,693 credits.

Free is out even hourly. An hourly schedule costs 1,440 fixed credits a month, above the Free plan's 1,000, and Free cannot schedule more often than every 15 minutes anyway. Every account in the study needs a paid plan for any schedule we tested.

One minute is a different plan. At a 1-minute schedule every account needs about 86,400 credits or more a month, the Core 150K tier at $175/month, for the same posts that a 15-minute schedule picks up a few minutes later. @Reuters reaches 94,287 credits there.

A second action doubles only the variable part. Adding a Slack message after the Sheets row adds 1 credit per post: @espn goes from 6,321 to 6,881 credits at 15 minutes, still Core 10K; @Reuters goes from 13,693 to 21,625, which needs Core 40K.

Use the formula from the study: credits per 30 days = runs x (modules that run every time) + posts x (modules that run per post). Runs per 30 days are 43,200 at 1 minute, 8,640 at 5 minutes, 2,880 at 15 minutes and 720 hourly.

Merge watches into one scenario. Every scenario pays its own fixed floor. One HTTP call with from:make_hq OR from:zapier OR from:n8n_io ... returns the posts of all ten accounts in one response, so the floor is paid once: about 14,900 credits instead of 66,800, a drop from Core 80K to Core 20K.

Pick the slowest schedule your use case tolerates. Going from 5 to 15 minutes cuts the fixed part from 17,280 to 5,760 credits. For a daily digest, hourly is enough; for a support or brand-monitoring inbox, 15 minutes is usually the trade-off point on Core 10K.

Let the data come to Make instead. A Make custom webhook is an instant trigger: Make's webhooks article says the scenario runs when the webhook URL receives a request, so there are no empty scheduled runs to pay for. On the X side, a TwitterAPI.io filter rule (/oapi/tweet_filter/add_rule, then update_rule to activate it, checked every interval_seconds) can push matching posts to a webhook URL; point it at the Make webhook and the Make bill becomes roughly 1 credit per delivery plus your action modules. See the pricing page for how rule checks are billed on the X data side.

Budget a little headroom. A tier that fits by a few hundred credits will tip into extra credits (25% surcharge) in a busy month. @Reuters at 15 minutes with two actions lands at about 21,600 credits, just over Core 20K; buy the 40K tier or drop the Slack step.

Make's credits pay for running the scenario, not for the X data it reads. Make's HTTP module calls whichever X data source you choose, and that source bills separately. Two options are common: the official X API on its pay-per-usage rate card, and a third-party X data API such as TwitterAPI.io.

The rates. The official X API charges $0.005 per post read, $0.010 per user read and $0.015 per post created ($0.20 with a URL) on pay-per-usage, capped at 3 million post reads a month before Enterprise, with $20 of credits on a first card purchase and an auto-recharge match up to $50 (docs.x.com/x-api/getting-started/pricing). TwitterAPI.io charges 15 credits per tweet returned, $0.15 per 1,000 tweets; a search that finds nothing still costs the 15-credit minimum, $0.00015. Per 1,000 tweets that is $5 vs $0.15, about 33x apart on those two rate cards.

Projected from the study at a 15-minute schedule, for the busier accounts:

Where the money goes. For a single quiet account, both data bills stay under $1/month and the Make plan is the larger number. As soon as a scenario reads real volume (a news account, a keyword, a list of competitors), the data bill grows per post and the rate card matters more than the Make tier: @Reuters alone is $1.19/month vs $39.66/month.

Polling floor on the data side. With TwitterAPI.io, a check that finds nothing costs $0.00015, so polling every 60 seconds for a month (43,200 checks) is at most $6.48 of empty checks and every 5 minutes $1.30; at 15 minutes the floor is $0.43. Reads need no X account and no X developer approval.

Getting started. New TwitterAPI.io accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days), which covers the one-scenario 10-account feed above for a month. Purchased credits never expire. Paid plans run from Starter $29/month to Business $1,499/month; the request rate is 0.2 per second before the first payment and 20 per second once paid, far above what a Make schedule needs.

Make's HTTP 'Make a request' module is all you need; the full scenario, including the Iterator, Google Sheets and Slack modules and an importable blueprint, is in our Make.com Twitter integration guide. The settings that drive the credit count are the URL, the query and the schedule.

One request per run. Use the search endpoint with a time cursor so each run returns only new posts: query=from:make_hq OR from:zapier since_time:<unix seconds of the last run> and queryType=Latest. A results page holds up to 20 posts; when a run returns more, follow next_cursor while has_next_page is true, and each extra page is 1 more HTTP credit and 1 more Iterator credit in Make.

Auth is a header. Add X-API-Key with your key in the module's headers. No OAuth app or X developer account is involved for reads.

Iterate over tweets. The response's top-level tweets[] array is what the Iterator splits; map text, url, createdAt, likeCount and author.userName into your Sheets or Slack module.

AI agents instead of a scenario. If you are building an agent rather than a fixed workflow, our hosted MCP server exposes the same X endpoints as tools at https://mcp.twitterapi.io/mcp with an Authorization: Bearer <your key> header; the trade-offs against Make, n8n and Zapier are in our MCP server workflow automation comparison.

Question. Which Make plan and credit tier does a scenario that watches an X account need, and how much of the bill comes from runs that find nothing?

Accounts. 10 public organization accounts: @make_hq, @zapier, @n8n_io, @github, @vercel, @NASA, @Reuters, @BBCBreaking, @espn and @nytimes. We read up to 160 recent timeline posts each through /twitter/user/last_tweets (1,440 posts, 74 requests, about $0.22 of API credits), collected in 2026, and kept original posts only, because a from: search skips reposts.

Window. Each account's window runs from its oldest to its newest post in the sample, so it varies: about 14 hours for @Reuters, about a week for @espn and @nytimes, several months for the quieter brand accounts. We replayed the posts against 1, 5, 15 and 60-minute schedule grids and scaled each to 30 days.

Credit model. From Make's operations and credits articles: per run, 1 credit for the HTTP module and 1 for the Iterator (plus 1 each per extra 20-post page), and 1 credit per post for each action module. Tier prices are Make's US price list, Core monthly billing, read from the price API that Make's pricing page uses. X data costs use the TwitterAPI.io and official X API rates quoted above.

What the sample cannot show. Posting rates change with news cycles and campaigns, so a short window (Reuters) or a quiet stretch (Vercel) may not represent a full month. Real scenarios add filters, routers, error handlers and retries, and a scenario that watches a keyword rather than an account sees very different volume. Make prices differ by country and may change after we read them.

Privacy. Aggregates only, organization accounts only; no reposted or quoted authors were analyzed, and the de-identified sample file keeps no IDs, URLs or text.

If you are pricing Make, you are probably pricing its two neighbors as well. They bill different units, which changes how a polling workflow scales:

Make's model rewards few, busy runs. Because every module run is a credit, Make is efficient when each run does real work (one call returns many posts) and wasteful when a schedule fires often for nothing. Merging watches and slowing schedules, as shown above, is where most of the saving is.

Whichever tool runs the workflow, the X data bill in the previous section comes on top, because the automation tool only pays for running steps, not for the posts it reads. For the two-way comparison between n8n and Zapier, see our n8n vs Zapier page.