Zapier X (Twitter) integration status in 2026: what is actually live, what it costs, and the no-API workaround

The timeline matters more than the headline

The reason a status page is useful at all is that this integration has moved four times in 33 months. In August 2023, Zapier removed the Twitter app after X changed its API policy and pricing. From August 2023 through early 2026, the only workable paths were paid third party wrappers, custom scripts against the new paid X API, or browser automation. On February 16, 2026, Zapier restored the X integration under a new model. In early March 2026, the integration went down briefly again after X said the workflow was not a supported use case under their developer program. By mid-March 2026, it was back, with the same bring-your-own-credentials shape that shipped in February. That shape has held through May 2026.

If you set up a zap on February 17, it probably broke in early March and asked you to reconnect. If you set one up in late March or after, it should still be running. The reconnect step is the same either way: you point Zapier at a real X Developer App that you own.

The cost math no one in the announcement posts wants to do

Zapier counts each Create Post action as one task on your Zapier plan. That is the part most write-ups stop at. The part they skip is what X itself charges, because the integration is now BYOK and X bills per call. As of April 20, 2026, X's public pricing for new pay-per-use developers is $0.015 per standard text or media post, $0.20 per post that contains a URL, and $0.001 per owned read of your own posts, bookmarks, followers, or lists, capped at 2 million reads per month.

A single daily zap that announces a new blog post is a Create Post with a URL in the body, which is the surcharge case. That is about $6 per month on X's side, before your Zapier plan. A daily mentions monitor that reads your own mentions and posts an internal notification when a new one lands is mostly owned reads, which fits comfortably inside the per-resource fraction-of-a-cent rate. A zap that posts an inline link to a curated tweet 200 times a month is $40 a month on X's side, again before Zapier. The shape of the surcharge means link-heavy automations are the ones that hurt.

What the bring-your-own auth flow actually looks like

Standing up a Developer App is its own pre-step before you even open Zapier. It is not hard, but it is not the one-click OAuth most people remember from the pre-2023 era.

The meter step is the one to internalize. Zapier is the orchestrator, but the dollar amount per call is on X. If your zap polls a query every five minutes for new posts, that is 288 polls per day, each counted as a read on the X side.

Why this is its own problem class

Before August 2023, Zapier's Twitter app was the canonical example of a no-cost glue between two SaaS products. You connected your account, you picked a trigger, you picked an action, you shipped. The cost lived inside your Zapier seat. After February 2026, that mental model is wrong in two places. First, the cost structure is split: Zapier task counts plus X API meter, and you can run out of either one. Second, the configuration burden is split: you now own a Developer App on X, which means you also own the rate limits, the scope review, and the platform policy compliance for that App.

For a one-person operation posting a tweet a day, the practical question becomes whether the dollar amount and the App ownership burden are worth paying for a true API path, or whether the same outcome is reachable by driving the browser you already use to post tweets manually.

The no-API route: drive your real logged-in X session

The other path is to skip the X API entirely and have an agent click around in the same browser you would use yourself. There are two flavors of this. Headless browsers (Playwright, Puppeteer) are fingerprintable, and X actively flags traffic that looks scripted in a headless engine. Driving the user's real, logged-in Chrome through the operating system's accessibility tree avoids most of that, because every page X serves you sees an authenticated session that already passed all the device-trust checks the day you signed in.

This is the path the social-autoposter skill bundled inside Fazm takes. The relevant file is Desktop/Sources/BundledSkills/social-autoposter.skill.md in the open-source repo at github.com/m13v/fazm. Under the X/Twitter section it instructs the agent to navigate to a tweet, find the reply box, type, click Reply, verify, and capture the resulting URL. Under Phase C: X/Twitter replies it tells the agent to navigate to https://x.com/notifications/mentions, find substantive replies to the handle configured in config.json, respond to at most 5 per run, and log each one to a local SQLite replies table. The browser targeting goes through macOS accessibility APIs, so the click on the Post button resolves to the element with the right role and label, not a guessed pixel position.

The cost on X's side is zero, because there is no API call. The cost on your side is whatever it costs to keep a Chrome window alive and logged in, which is the same Chrome you would have open anyway.

When the Zapier BYOK route is still the right call

There are real cases where the API path wins. If you need server-side reliability with no Chrome window in the loop, the API is what you want; a browser agent that depends on a Mac staying awake is not the right shape for production-grade webhooks. If your zap needs to react to events the browser cannot see (such as another SaaS firing a webhook into Zapier that then needs to post to X within seconds), the API path is the cleaner one. If you are already on a legacy Basic or Pro tier with X, the marginal cost per post is close to nothing, and the BYOK shape is just a small auth ceremony you do once.

The cases where the browser path wins are mostly the ones where you would be paying X for the privilege of posting your own content from your own account, on your own Mac, where you are the only human in the loop. That is most independent operators, most agencies posting on behalf of a client, and most marketing teams that already had someone hitting Post manually before automating it.

What to verify before you commit either way

For the Zapier route, confirm three things in the X Developer portal: the App scopes include the writes you plan to do, the pay-per-use plan is the one attached to the App (rather than a legacy plan you no longer have access to top up), and the billing card on file is current. Reconnect the X account inside Zapier any time the Developer App is rotated.

For the browser route, confirm two things on macOS: Chrome has accessibility permission granted under System Settings, Privacy and Security, Accessibility, and the agent has Screen Recording permission if you also want it to read post text back from rendered tweets rather than just from the accessibility tree. After that, the agent inherits whatever your X session is allowed to do, which is everything a human user can do in the same browser.