By Sorsa Editorial

Updated: June 17, 2026. Confirmed Make's X (Twitter) integration is still discontinued with no reinstatement since May 2025, and verified the HTTP module setup against the live Make app.

Key Takeaway Make.com removed its native X (Twitter) integration on April 3, 2025, and existing scenarios stopped on May 30, 2025, over X API pricing and policy. It has not returned. To read X data in a Make scenario now, call a third-party REST API from Make's built-in HTTP module.

That third-party API is where Sorsa API, an alternative Twitter/X API, fits the gap Make left. It is read-only and reaches public X data (tweets, search, mentions, followers, profiles) over plain REST, authenticated with one key in an ApiKey header that maps directly onto Make's HTTP API Key Auth. Billing is flat: one call is one request, from $49 for 10,000 requests, with no per-resource charges and no X developer account to apply for.

One distinction decides which half of this guide you need. Posting to X and reading data from X are now two different jobs with two different fixes. Posting is a write action, and after the native app died it belongs to your own X developer app or a social-publishing tool. Reading public data is what the old native triggers like "watch new mentions" used to do, and that is the part nobody replaced cleanly. The same HTTP-call approach covers the other no-code platforms too, in n8n and Zapier.

Contents

What happened to Make's native X (Twitter) integration?

Make discontinued its X (Twitter) app on April 3, 2025. From that date no new scenarios could be built with the X modules, and on May 30, 2025 all existing X scenarios stopped running and began returning errors on execution. Make's stated reason was that X's API pricing and policy made a reasonable integration impossible for its customers.

That wording comes straight from Make's release note, and the help center page carrying it was last updated in January 2026 with no change of course. Unlike Zapier, which removed X support and later restored it under a bring-your-own-key model, Make has not brought the integration back. The native X app is gone, and the official guidance points elsewhere.

The replacements Make itself recommends are revealing: Buffer, Hootsuite, and posting to networks like Bluesky and Mastodon. Every one of those is a publishing tool. None of them reads arbitrary public X data, which is exactly what a large share of the old scenarios actually did.

A small but useful detail: Make's xAI (Grok) app was unaffected, because X and xAI run on separate API policies. So you can still reach Grok inside Make even though you cannot reach X through a native module.

The root cause is cost, and it is worth understanding because it shapes every workaround. The official X API bills per resource, so a platform serving millions of automations cannot absorb a per-post and per-profile charge at scale. We cover the economics in detail in why the X API got so expensive.

Can you still post to X from Make?

Yes, but only through a route you set up yourself or through a dedicated publishing tool. Make no longer offers a native X module, so posting now means either calling X's own API from the HTTP module with your own developer credentials, or connecting a social-media management service that holds the X connection for you.

Tools in the publishing category include Buffer, Hootsuite, Ayrshare, and posting-focused APIs such as XTweetAPI and upload-post. These handle write actions: sending posts, scheduling, replies, and account management. If your scenario only needs to publish to X, one of these is the practical fix, and Make's own help center points to Buffer and Hootsuite first.

There is a catch worth stating plainly. Posting through your own HTTP setup requires an X developer app, OAuth credentials, and X's pay-per-use billing, where standard post creation runs $0.015 per request and a post containing a URL costs $0.20. The convenience tools layer their own subscription on top of that.

Sorsa does not compete here. It is read-only by design and has no posting, liking, following, or DM endpoints. If you need to write to X, use the tools above. If you need to read from X, the rest of this guide is for you.

How to read Twitter/X data into Make without the native app

To read public X data into a Make scenario without the native app, call a read-only REST API from the HTTP module and map its JSON response into your downstream modules. This rebuilds the data-collection jobs the old X triggers handled, with no X developer account and no browser automation to maintain.

This is the lane the publishing tools leave empty. Buffer and Hootsuite cannot watch a competitor's mentions, pull a follower list, or run a keyword search and drop the results into a sheet. Those are read jobs, and a REST data API answers them directly. In running our own API we see these four patterns rebuilt most often.

Monitor mentions of a brand or handle

Mention tracking was one of the most common native-trigger uses, and it is the cleanest to rebuild. A call to the /mentions endpoint returns posts referencing a handle, with filters for minimum likes, replies, retweets, and a date range. Route the results into Slack, a sheet, or an alert. See tracking X mentions through the API for the full setup, or the social listening solution for the wider monitoring picture.

Search tweets by keyword, hashtag, or operator

For topic and hashtag monitoring, /search-tweets accepts a query string with full Twitter advanced-search operators (from:, since:, until:, exact phrases, hashtags) and returns matching posts, about 20 per page, paged with a cursor. There is no result-limit parameter, so volume is controlled by how many pages you request. Our guide to searching tweets via a REST endpoint walks through the operators, and the query builder assembles the syntax for you.

Pull a user's tweets, followers, or following

To watch an account, /user-tweets returns its recent posts. To analyze an audience, /followers and /follows return up to 200 profiles per request, one of the higher per-call yields available. Each profile arrives with full metrics. The walkthrough for pulling follower and following lists covers pagination and field mapping.

Enrich a profile inside a workflow

When a lead or signup arrives, a single /info call returns that account's bio, location, follower and following counts, verification status, and creation date, ready to write back to a CRM row. For bulk passes, /info-batch resolves up to 100 handles in one request, which keeps a high-volume scenario inside a small request budget. To run the same polling logic on a schedule, see scheduled monitoring of X activity, and to land the output, sending the results into Google Sheets.

Configuring Make's HTTP module for a read-only X API

Make's HTTP "Make a request" module sends a request to any URL and parses the response, and it supports API key authentication with the key placed in a header. That is all a read-only X API needs, and the module ships on every plan, including the free one. The configuration below is deliberately UI-light, because the durable part is the request itself, not the buttons around it.

Setting up a Sorsa call in the HTTP module takes six steps:

  1. Add the HTTP > Make a request module to your scenario.
  2. Set the Method. Use GET for profile and follower reads, POST for search.
  3. Set the URL to the endpoint, for example https://api.sorsa.io/v3/search-tweets.
  4. Add a header named ApiKey with your key as the value (or use the module's API Key Auth with header placement). Authentication detail is in the API key header docs.
  5. For a POST, set the body type to Raw, content type to JSON, and supply the request, for example {"query": "from:nasa", "order": "latest"}.
  6. Turn on Parse response so Make maps the JSON fields for downstream modules.

A profile read looks like this:

GET https://api.sorsa.io/v3/info?username=nasa
ApiKey: YOUR_API_KEY

A search reads like this:

POST https://api.sorsa.io/v3/search-tweets
ApiKey: YOUR_API_KEY
Content-Type: application/json

{"query": "from:nasa", "order": "latest"}

Paging is the one part people miss. Endpoints that return lists include a next_cursor field in the response. To collect more than one page, feed that value into the next_cursor of the following request and repeat with a Repeater or Iterator until the cursor comes back empty. The cursor-based pagination reference shows the exact field. When we tested this loop against the live endpoint, the only failure mode was forgetting to stop on an empty cursor, which sends the scenario into an extra idle call. A full request-and-response walkthrough lives in the quickstart.

If you would rather not touch the HTTP module at all, the no-code playground runs the same endpoints from a browser UI and shows the raw JSON, which is a fast way to confirm a query before wiring it into a scenario.

Do you need an X developer account to read X data in Make?

No. Reading X data through a third-party REST API needs only that API's own key, so you skip X's developer portal, the app review queue, OAuth setup, and pay-per-use credits entirely. The X developer account is only required when you talk to X's own endpoints directly, which is the posting route, not the reading route.

This is the practical difference between the two halves of this guide. The native module and any self-hosted posting setup pull you into X's developer flow and its per-resource billing. A read API hands you one key and a base URL, and the setup takes minutes rather than an approval cycle. The wider picture is in getting X data without a developer account.

What does it cost to pull X data into Make?

Cost depends on the data source, not on Make. The official X API bills per resource, scraper actors bill per result returned, and flat-rate REST APIs bill per request regardless of how many items a call returns. For a scenario that reads at any real volume, the billing unit is what decides the bill.

The official X API charges $0.005 per post read and $0.010 per user read on its pay-per-use model, and it authenticates with OAuth 2.0 and a bearer token. Sorsa charges per request at a flat rate and authenticates with a single key in a header. The contrast on a read workload:

Official X APISorsa API
Access modelRead and writeRead-only
Billing unitPer resource fetchedPer request (flat)
Read price$0.005 per post, $0.010 per profileFrom $0.0049 per request ($49 / 10,000)
Rate limitPer-endpoint windowsFlat 20 req/s, every plan
AuthOAuth 2.0 + bearer token, app reviewOne API key in a header, no review
Developer accountRequiredNot required
BatchLimitedUp to 100 tweets or 100 profiles per call

If you need to publish to X or to use first-party and licensed-data features, that is the official API's territory and you should use it. For reading public X data into a Make scenario at a flat, predictable price with a one-key setup, a read-only API like Sorsa is the cheaper and simpler fit, and a tweet response already includes the author's full profile at no extra charge. The full breakdown is in the 2026 X API pricing guide.

Two further line items belong in any honest estimate. Make itself bills in operations, and each HTTP call plus each pagination loop consumes one, so a high-frequency poll needs a paid Make plan to cover the operation count. And general scraper actors that pipe into Make, such as Apify, price per result; a common rate is roughly $0.40 per 1,000 tweets on a paid tier (estimate, varies by actor), and they run as asynchronous jobs you trigger and then poll, which adds steps a direct REST call avoids.

Feeding X data into Make AI Agents

Make AI Agents and Make's MCP support can consume X data fetched through the same HTTP module, so the read pattern above doubles as a data source for an agent step. Pull the posts or profiles, pass the parsed JSON to the agent, and let it summarize, classify, or route.

For agent-native setups, Sorsa also exposes its endpoints for AI workflows directly, which removes the manual field mapping. The approach is described in using the data inside AI agent workflows.

A real rebuild: mention tracking after the integration ended

When Make killed the X app, a roughly 10-person social analytics team we worked with lost a scenario that had watched brand mentions and logged them to a sheet for the client dashboard. The native trigger was gone, and Buffer and Hootsuite could not read mentions, only publish.

The rebuild was a single HTTP module calling /mentions on a schedule, paged with the cursor, writing rows into the existing sheet. The scenario logic barely changed; only the data source did. Because billing moved from per-resource reads to flat per-request calls, the team's data cost for that workload dropped by roughly 30 to 50 times against what the same volume would have cost on the official X API, a property anyone switching a read-heavy workflow off per-resource pricing will see. Teams coming off the official API directly can follow the same path in moving a workflow off the official X API.

Getting started

If your scenario reads X data, the setup is short. Get a key, add one HTTP module, and point it at the endpoint you need. There is no app review and no OAuth, the key drops into an ApiKey header, and the flat 20 req/s limit applies on every plan, so a busy scenario does not hit a per-endpoint window. Plans start at $49 for 10,000 requests; see pricing for the full tiers. Run a query in the playground to confirm it, then wire it into Make.

FAQ

When did Make remove the Twitter (X) integration?

Make removed its native X (Twitter) app integration on April 3, 2025, after which no new scenarios could use the X modules. Existing scenarios kept running until May 30, 2025, then stopped and began returning errors on execution. As of the help center's January 2026 update, the integration has not been reinstated.

Why did Make.com drop the X integration?

Make stated that X's API pricing and policy requirements prevented it from offering a reasonable integration to customers. The official X API bills per resource fetched, so for a platform running large volumes of automations, the per-post and per-profile cost made a sustainable native X module unworkable, which is why Make discontinued it rather than absorbing the price.

Is it still possible to post to X from Make.com?

Yes, but not through a native module. Posting now requires either calling X's own API from the HTTP module with your own developer app and OAuth credentials, or connecting a publishing tool such as Buffer or Hootsuite that holds the X connection. Both routes involve X's pay-per-use write pricing or a separate subscription, since Make no longer brokers the connection.

How do you get X data into Make without the native app?

Call a read-only REST API from Make's HTTP module and parse the JSON into downstream modules. Sorsa, a read-only Twitter/X API, returns tweets, search results, mentions, followers, and profiles over plain REST with a single key in an ApiKey header, which matches Make's HTTP API Key Auth. No X developer account or browser automation is needed.

Is an X developer account required to read X data in Make?

No. A third-party REST API uses its own key, so reading X data through one skips X's developer portal, app review, OAuth setup, and pay-per-use credits. An X developer account is only required when a scenario calls X's own endpoints directly, which applies to posting. For reading public data, one API key and a base URL are enough.

How much does it cost to pull X data into a Make scenario?

Cost depends on the data source. The official X API bills per resource ($0.005 per post, $0.010 per profile). A flat-rate API like Sorsa bills per request, from $0.0049 each at the $49 plan for 10,000 requests, with author profiles included free in tweet responses. Make also bills operations, so each call and pagination loop counts toward your Make plan.

Reviewed by Keksich, founder of Sorsa, marketer and X API researcher.

This guide draws on our hands-on work operating Sorsa's API, the live API and its documentation, and Make's own release note discontinuing the X app. Pricing and dates were verified against Make's help center and our pricing reference on June 17, 2026.