Integrations

The request every platform is making

Whatever the interface calls its fields, this is the call underneath. Get this working in a terminal first, then reproduce the same four parts in the platform: method, URL, query parameter, header.

GET https://api.twitterapis.com/twitter/user/info?username=naval
Authorization: Bearer YOUR_API_KEY

# or, if the platform prefers a named key header
x-api-key: YOUR_API_KEY

About X, formerly Twitter, and what its API returns

X, formerly Twitter, exposes its data through an official API whose read access is priced and rate-limited for a different kind of buyer than a workflow automation. This API sits in front of it and hands your workflow ordinary JSON over ordinary HTTPS, so what matters on this page is not the platform you are wiring but which of the 109 endpoints the step is going to call.

65 of the 109 are reads and 44 are writes, and every one of them is a plain GET or POST with a single authorization header, which is the only reason a no-code HTTP step is enough. There is no OAuth handshake to complete inside the platform, no callback URL to host and no app to register with X, because your workflow is calling us rather than calling X.

The one shape worth learning before you build is the cursor. Anything that returns a list returns one page plus a next_cursor, and a workflow that wants the whole list has to loop. Two things bite there. Billing is per CALL rather than per record, so an unbounded loop over a sparse query is the one way to spend more than you planned. And the loop needs BOTH exits, because the two endpoint families fail in opposite directions. Search and list endpoints hand back a null cursor on a page that is still full, so stopping only when the page comes back empty drops that last page, and omitting the cursor on the next call restarts you at page one. Follower-graph endpoints do the reverse and keep returning a non-null cursor after the last real page, so stopping only when the cursor goes null never stops at all. Check the empty collection AND the spent cursor, cap the loop by calls, and keep the cursors you have already seen so a cursor that stops advancing raises instead of billing. Working clients for six languages are on the SDK page.

What a run actually costs, measured

Because billing is per call, the number that decides a scheduled workflow's monthly bill is how many records a call returns on average, not the page size you asked for. We measured ours rather than estimating it: across 396,817 successful read calls on our own billing logs over successful tweet-returning reads, 13 to 17 August 2026, a timeline read returned 18.78 tweets on average, bulk reads excluding tweet/detail returned 12.96, and a search read returned 7.62, with 29.5% of search calls returning nothing at all and still counting as a call.

Put that through a schedule and the arithmetic is short, but read the yield figures carefully, because they are RECORDS PER CALL and not new posts per day. A workflow polling one account's timeline every fifteen minutes makes 96 calls a day, which is $2.30 a month at $0.0008 a call. What it does NOT get is 96 times 18.78 posts: each call returns the same recent timeline, so the distinct new posts you actually collect is however many that account published, which for most accounts is a handful a day. You are paying 96 times to notice three things. That is the whole argument for the webhook trigger below, and it is why a search-driven workflow costs the same per call while returning nothing at all on nearly a third of them.

New accounts start with $0.50 of credit, about 625 read calls and no card, which is enough to run the real workflow on real data before you decide whether the schedule is right.

Stop polling: trigger the workflow when the post appears

Almost every workflow built on this page starts the same way: a schedule trigger, a read call, and a filter that throws away everything already seen. It works, and it is the expensive way to do it. A five-minute schedule is 288 calls a day whether or not the account posted, and the account you are watching probably posts three times. You are paying for the silence.

The alternative is to invert it. Register a webhook destination, point a monitor at the account, and the request arrives at your workflow the moment there is something to process, subject to the shared poll interval the monitor runs on rather than instantly. Three of the four platforms here can receive one: n8n has a Webhook trigger node, Make has a custom webhook module, and Zapier has Catch Hook. Composio is the exception, for the reason its section above gives, no generic HTTP action with a headers field, so point the monitor at one of the other three or at your own endpoint. The workflow you already built stays the same from step two onward. Only the trigger changes, from a clock to an event.

Three things are worth knowing before you switch. Creating and managing monitors and webhook destinations is free, so the cost of the watching itself is zero and you pay only for what you then read. Deliveries are signed, so your workflow can reject anything that did not come from us rather than trusting whatever posts to the URL. And every monitor exposes its own delivery health, which matters more than it sounds: a webhook that silently stops is indistinguishable from an account that simply went quiet, and that is the failure mode nobody notices for a week.

Polling is still the right answer for some jobs. A nightly export, a backfill, or anything that reads a whole follower list is a scheduled read by nature and there is no event to wait for. The rule of thumb is which question the workflow is asking: "what happened since I last looked" wants a webhook, and "give me all of it" wants a schedule and a cursor loop.

For agents rather than workflows

A workflow platform is the right tool when the steps are fixed and the schedule is known. When the consumer is an AI assistant deciding what to fetch as it goes, the MCP server is the better fit: it exposes 109 tools an assistant calls by name, so there is no URL to build and no header to remember. n8n, Make and Zapier each now ship a client that can connect to a remote MCP server as well, and each of those vendors labels its own client a beta feature at the time of writing, so treat that route as promising rather than settled.

If you would rather write the integration yourself, the language clients page carries a working client for six languages, the quickstart gets a first response back in about a minute, and the REST API reference covers paging and the error contract your retry step will branch on.