Make vs n8n for X automation compliance in 2026

Make.com dropped its native X integration entirely on May 30, 2025, leaving n8n as the default tool for teams that automate posting on X. But n8n carries compliance risks most comparisons skip: its X node has zero built-in rate-limit handling, and since v0.236.0 forced all credentials onto OAuth2, every account in your workspace pools against a single app-level rate cap. An agency running five accounts at 20 posts per day each can hit X's 10,000-post/24h app ceiling before any individual account looks suspicious, with no warning in n8n's interface until a 429 error surfaces mid-run.

Make.com's Native X Integration Died on May 30, 2025

Make.com stopped supporting X entirely. Not deprecated, not degraded: removed. Make blocked new X scenarios on April 3, 2025, and on May 30, 2025 every existing scenario that touched X stopped running. Make's help center notice gives the reason as X's API pricing requirements, and Make has never published a supported replacement. If your automation ran through Make's native X modules, it has been dead for over a year, and the vendor is not planning to revive it.

That resolves most of the Make versus n8n question before the comparison starts. n8n did not win this on rate-limit design or compliance tooling. It won because the other side left. Every article that scores the two tools across a feature matrix is describing a contest with a single participant. The useful question is not which tool is better. It is what n8n does not do for you, and what you now have to build yourself, because nobody is going to build it for you either.

There is a workaround. Make's generic HTTP module can still call the X v2 API directly, and it works. The Make community thread documenting this is the closest thing to migration guidance anyone has published. Make has not endorsed it, has not written official documentation for it, and has not shipped it as a supported path. That distinction sounds like vendor politics. It is not. An endorsed integration carries guardrails: required fields, validation, and prompts that surface obligations you did not know you had. A raw HTTP call carries none of those.

Compliance obligations do not disappear when the integration does. X's developer guidelines require an Automated profile label on the posting account, a bio disclosure identifying the account as automated, and an association with a human-managed account. Those requirements attach to the account, not the tool. X does not care whether the POST /2/tweets request came from a native connector, Make's HTTP module, or a shell script. The API client you use has no bearing on which policy governs the account. Teams rebuilding on the HTTP module frequently port the mechanics and skip the policy surface entirely, because nothing in Make's interface reminds them it exists.

We have a name for this pattern: silent compliance drift. The workflow works. Posts go out, the run history is green, nothing errors. The account is out of policy the whole time and nobody finds out until an enforcement sweep runs. This is worse than a broken integration. A broken integration announces itself immediately and gets fixed. A compliant-looking workflow that quietly violates attribution rules accumulates months of activity before anyone checks, and by then the remedy is not a fix, it is an appeal.

If you built X automation on Make before May 2025, treat the rebuild as a policy migration and not a plumbing migration. Before you turn anything back on, confirm the posting account carries the Automated label, that the bio states the account is automated, and that it is associated with a human-managed account. Then look at what the workflow does rather than just what it posts. Reply behavior, media handling, and any like or follow actions all changed under rules X shipped during 2026, and the rest of this guide covers each of those changes in turn.

A last point about the decommission is worth sitting with. Make removed the integration because X's API pricing made it uneconomical to maintain. That was a vendor deciding the cost and compliance burden of X automation was not worth carrying. When you rebuild on the HTTP module or move to n8n, you are picking up exactly the burden Make put down. Going in with that framing produces better workflows than going in believing you found a clever workaround.

Does n8n Handle X API Rate Limits Automatically?

No. n8n has zero native rate-limit handling for its X node, and n8n's own documentation says so plainly. When a request hits X's rate limit, the node surfaces a 429 and the workflow stops. No pause. No backoff. No retry. Nothing happens automatically unless you designed it to happen. Every piece of rate-limit management runs through Wait nodes, Loop Over Items, and Retry On Fail that you wire up by hand.

The gap most people miss is not the missing backoff. It is the missing visibility. You cannot ask n8n how much quota you have left. Developers who try hit a wall documented in n8n's community forum: querying X's v1.1 rate limit status endpoint from inside a workflow returns a 403, because n8n's credentials are OAuth2 v2-only and the v1.1 introspection endpoint rejects them. In-workflow rate limit introspection is broken by design. Your workflow flies with the fuel gauge disconnected.

The limits themselves are published. Under X's pay-per-use model, POST /2/tweets allows 100 posts per 15 minutes per user and 10,000 posts per 24 hours per developer app, and X enforces the two independently. Most people read those numbers and conclude they have enormous headroom. The per-user number is generous. The per-app number is the one that matters, and n8n's architecture pushes you into it first.

Here is the failure mode from our own data, and it is the reason this section exists. When multiple X accounts run through a single n8n OAuth2 app credential, every post from every account pools against that one app-level cap. A workflow posting for five accounts at 20 posts per day each looks modest from every angle you would normally check. No individual account posts at a volume that would draw attention. The aggregate is what reaches the 10,000 per 24 hours ceiling, and the aggregate is not displayed anywhere in n8n's interface. The first signal you get is a 429 mid-run.

Call it silent pooled-quota exhaustion. What makes it nasty is that the diagnostic instinct is wrong. When the 429 lands, the operator looks at the account that failed, sees low volume, and concludes the limit must be something else, or that X is being arbitrary. The failing account did nothing unusual. It was the last one through the door. Meanwhile the run sits half-finished: some posts sent, some did not, and n8n has no built-in mechanism to tell you which is which after the fact unless you built that logging yourself.

The partial-run problem compounds. A workflow that stops on a 429 leaves the queue in an indeterminate state, and the naive fix, rerunning the workflow, republishes whatever already went out before the failure. We have seen duplicate posting cause more account trouble than the original rate limit did, because duplicate content posted in quick succession is exactly the pattern X's detection systems are tuned for. The rate limit was the small problem. The recovery behavior was the big one.

None of this makes n8n unusable. It makes n8n a toolkit rather than a finished product for this job. The X node gives you the API call and nothing else: no quota accounting, no backoff, no visibility, no multi-account isolation. Treat it as a completed integration and you will be surprised. Treat it as a raw client you are responsible for wrapping, build the guards described later in this guide, and it holds up.

n8n Twitter Automation Collapses Multi-Account Rate Limits into One App Quota

The pooling problem has a specific cause and a specific version number. n8n deprecated OAuth 1.0a for its X node in v0.236.0, forcing every connection onto OAuth2. The change is documented on n8n's Twitter credentials page and presented as routine modernization. For single-account users it is. For anyone running more than one X account through n8n, it quietly rewrote how rate limits apply to their entire setup.

The mechanism is worth understanding rather than memorizing. Under OAuth 1.0a, each connection carried a per-user access token, and X counted requests against that individual user's quota. Each account meant its own bucket. Under n8n's OAuth2 implementation, requests are attributed to the developer app, so every account credential in the workspace draws from the same pool. The per-user granularity did not degrade. It disappeared. n8n's credentials documentation describes the migration, but what it does not spell out is that headroom now compresses in direct proportion to how many accounts you run.

That inversion is the part agencies get wrong. Adding a client to a Make scenario used to be additive: new account, new quota. Adding a client to an n8n workspace on one app credential is subtractive. Every existing client's headroom shrinks. Nothing in the interface communicates this. You add a credential, the node turns green, and the shared ceiling everyone is drawing from gets closer without any indication that it moved.

Money now sits on top of the same ceiling. X closed flat-rate API tiers to new signups on February 6, 2026, and began auto-migrating Basic subscribers to pay-per-use billing on June 1, 2026. Under pay-per-use, a post without a link costs $0.015 and a post with a link costs $0.200. Reads cost $0.005 per post read, capped at 2,000,000 post reads per monthly billing cycle before X requires Enterprise. Put the two write prices side by side, because that spread reshapes workflow design more than any rate limit does. So the 10,000 posts per 24 hours app cap now does double duty: it is a compliance boundary, because crossing it produces 429s and burst behavior that looks like what X flags, and it is a cost ceiling describing the maximum daily spend a single app can generate.

The same round of changes broke something in n8n that nobody gets an error about until runtime. X removed follow and like endpoints from all self-serve plans on April 16, 2026. n8n's X node still exposes like and follow actions in its interface. You can select them, configure them, save the workflow, and see nothing wrong. At runtime the API returns a 403. This is a silent failure mode in the most literal sense: the configuration screen and the API disagree, and only the API is current. If you inherited a workflow built before April 2026, check for like and follow nodes before you check anything else.

There is an architectural way out, and it is not a better n8n workflow. Real-browser automation on a residential IP authenticates each account as an individual user in its own session. Rate limits then apply per-user rather than per-developer-app, which is the arrangement OAuth 1.0a used to give you and OAuth2 took away. In our experience, accounts operating at meaningful posting velocity fare better under local-agent architectures than under n8n's shared-credential model, and the reason is structural rather than clever. There is no shared pool to exhaust.

If you are staying on n8n with multiple accounts, the honest mitigation is a separate developer app per account. It is tedious, it multiplies credential management, and X's developer app approval process is not instant. It also restores the isolation you lost at v0.236.0. The alternative is running every client through one pooled quota and hoping aggregate volume stays under a ceiling you cannot query from inside the workflow.

Build These Rate Limit Guards Before Running n8n Twitter Automation in Production

None of the guards you need ship with n8n. Add a Wait node after every X post action, configure Retry On Fail on every X node, maintain your own quota counter in a Loop Over Items branch, and randomize your intervals. That is the minimum viable wrapper around n8n's X node for production use. n8n's rate-limit documentation names the same node types, which tells you how this is meant to work: the platform supplies the primitives and expects you to assemble the safety yourself.

Start with the Wait node, and specifically with how you configure it. The instinct is a fixed delay: post, wait, post again, always the same gap. Do not do that. X's timing-pattern detection in 2026 is sensitive enough that a schedule firing every 4 hours on the dot can trip velocity flags at volumes nobody would call aggressive. Human posting does not run on a metronome. Operators running local-agent workflows with human-session-mimicking jitter, meaning variable delays drawn from observed human posting distributions rather than a constant, see materially lower flag rates than workflows on deterministic cron intervals. We are not going to put a figure on that gap, because the honest version of the claim is directional. The direction has been consistent.

Retry On Fail comes next, with 3 to 5 attempts and exponential backoff capped at 64 to 128 seconds. Those are community-recommended bounds, and the reason they are community-recommended rather than defaults is that n8n enforces none of them natively on the X node. You set them explicitly, per node, every time. Miss one X node in a branch you rarely test and that node behaves like an unguarded workflow, which means it stops dead on the first 429 it sees.

The counter is the guard people skip, and it is the one that pays for itself. Use a Loop Over Items node with a custom counter tracking posts sent per 15 minutes and per 24 hours at the workflow level, persisted somewhere the workflow can read on its next run. You are rebuilding the introspection X will not give you, because querying the v1.1 rate limit status endpoint from n8n returns a 403 against OAuth2 v2 credentials. A counter you maintain yourself is the only quota visibility available inside an n8n workflow. Build it before you need it, not after your first restriction.

Now the part the guards do not cover. X evaluates interaction velocity relative to account age and follower count, not against a fixed threshold. A new account posting a handful of times a day on a perfect schedule can be flagged long before it approaches any published limit, while an established account doing more volume passes without comment. Operators who tune purely against published ceilings are optimizing against the wrong constraint. The published limits tell you when the API will refuse you. They tell you nothing about when the detection systems will decide you are a bot.

That gap explains a category of problem we see constantly. Someone builds a careful workflow, stays well under 100 posts per 15 minutes, never comes near the app cap, and gets restricted anyway. Nothing in the configuration was wrong by the numbers. The pattern was wrong: same interval, same posting window, same content shape, day after day, on an account with no history to justify it. Rate-limit compliance and detection avoidance are different problems, and only one of them is solved by counting.

Order of operations matters when you deploy this. Put the guards in before the workflow handles real volume, not after. Retrofitting backoff into a workflow that has already triggered a restriction does not help the restricted account, and it does not undo the behavioral history X has already recorded. Build the wrapper first, run it small for a while, and let the account accumulate a boring, human-looking record before you raise the schedule.

What the Make HTTP Module Workaround Gets Wrong About X Compliance

The HTTP module workaround's problem is not that it breaks. It is that it works perfectly while being out of compliance. Make's HTTP module will send a well-formed POST /2/tweets request, return a success, and show you a green run. What it will not do is tell you the account needs an Automated profile label, that the bio needs a disclosure, or that the request body is missing a media attribution parameter X expects. No prompts, no templates, no validation. Every obligation is yours to research.

Compare that to what a native integration does. Whatever else you think of vendor connectors, they encode institutional knowledge: required fields are required, deprecated actions get removed, policy-sensitive parameters appear in the UI where you cannot miss them. Make's community thread on the HTTP module workaround is a technical recipe for making an API call. It is not a compliance guide, it does not claim to be one, and Make has never endorsed it as a supported replacement. Treating a forum post as a migration path means inheriting everything that post did not cover.

The clearest example is the isAIGenerated field. In our own testing, Make's HTTP module workaround silently omits it unless the developer explicitly writes it into the request body. There is no template that includes it, no validation that asks about it, and no warning anywhere in Make's UI when it is absent. Any workflow posting AI-generated images built after the native integration died is likely non-compliant with X's media attribution requirements by default. Not through negligence. Through the total absence of any surface that would tell you the parameter exists.

The attribution requirements are not tool-specific, and this is where a lot of reasoning goes wrong. X's developer guidelines require the Automated profile label, bio disclosure, and human-managed account association for automated accounts, and those requirements attach identically to requests from Make's HTTP module and requests from n8n's native X node. Using a generic HTTP client is not an exemption. It is not even a gray area. X evaluates the account and its behavior, and has no interest in which piece of software constructed the request.

We call the resulting pattern silent compliance drift, and its defining property is that no error surfaces. A broken workflow tells you it is broken. A non-compliant workflow succeeds on every request and builds a clean run history while the account accrues policy exposure. By the time you learn about it you are not debugging, you are appealing. The teams most exposed are often the ones who did the migration well: they got the API calls right quickly, which got them to volume quickly, which accumulated more of the wrong thing.

Reply automation is the sharpest version of this. Make's community documentation on the HTTP module workaround predates and does not address X's February 2026 automated-reply restrictions. Someone rebuilding a reply bot from that thread today builds the exact workflow shape X restricted, ships it, and it runs. The next section covers what changed and which shapes are still permitted. The point here is narrower: the reference material people are migrating from describes an API surface that policy has since moved out from under.

If you are committed to the HTTP module path, write a checklist and treat it as part of the workflow definition rather than as documentation. Account label set. Bio disclosure present. Human-managed account associated. Media posts include isAIGenerated. Reply logic gated on a prior mention. None of that is enforceable inside Make, which is the entire reason it has to live somewhere a human reads before deployment.

X's 'Operation Kill the Bots' Makes Most Automated Reply Workflows Non-Compliant

In February 2026, X restricted automated replies through the POST /2/tweets endpoint under an enforcement push reported as Operation Kill the bots. Automated replies are now permitted only when the original author first mentioned the bot account or quoted its post. Reply to anything else automatically and you are in violation, regardless of how good the reply is. Automated original posts were not affected and remain permitted under applicable tier limits. The restriction is about who starts the conversation.

Audit your own workflow against that right now. If the trigger is a mention of your account, you are probably fine. If the trigger is a quote of your post, probably fine. If the trigger is a keyword search, a hashtag monitor, a competitor-mention watcher, or a list of accounts you want to appear underneath, that workflow is non-compliant today. Growth-loop reply bots are the clearest casualty, because their entire design is replying to people who have not engaged with you. That was the point of them. It is also precisely what the restriction targets.

There is a volume rule stacked on top. X's developer guidelines limit automated accounts to 1 automated reply per user interaction. One. A workflow that replies, then replies to the follow-up, then replies to the follow-up's follow-up, violates the rule even when the first reply was triggered by a legitimate mention. Multi-turn automated conversation is not permitted no matter how helpful the thread reads. If you built a conversational bot, the compliant shape is a single automated response followed by human handoff.

AI-generated replies carry a further requirement that surprises people: they need prior approval from X before deployment. Not a disclosure, not a label, actual approval in advance. X's developer guidelines are explicit that deploying automated AI replies without that approval violates policy even when the content is helpful and non-spammy. Quality is not a defense here. The most common assumption we hear is that thoughtful, on-topic AI replies sit in a safe zone because they are obviously not spam. Policy contains no not-spam exemption.

Put the rules together and the compliant reply workflow is narrow. It fires only on a mention or a quote of your account. It sends at most one automated reply per interaction. If the reply text is model-generated, it does not run at all until X has approved it. Anything wider than that is out of policy, and it makes no difference whether the requests come from n8n's X node or a Make HTTP module call. The rules govern the account's behavior, not the client that sends the request.

Most reply automation built before February 2026 needs modification, and the modification is usually deletion rather than adjustment. A keyword-triggered reply bot cannot be made compliant by slowing it down or improving its copy, because the trigger itself is the violation. That is a harder internal conversation than a rate-limit fix. It is also the one worth having first, because reply behavior is the highest-visibility automation signal an account emits, and it is what enforcement looks at.

One practical note on detection. Automated replies to strangers generate reports from those strangers, and reports are a much faster path to review than any behavioral heuristic. That is part of why X drew the line where it did: the restricted pattern is the one that produces complaints. If you want a single heuristic for reply automation in 2026, use this one. Automate responses to people who came to you. Never automate the approach.

The Automated Label Is Your Best Protection Against X Enforcement Sweeps

The highest-leverage compliance action in this entire guide costs nothing and takes almost no time. Enable the Automated profile label on the posting account. Accounts with the label enabled are explicitly exempt from X's bot-detection enforcement sweeps, which makes it direct suspension-risk mitigation rather than cosmetic disclosure. The exemption applies at the account level. Not per workflow, not per tool, not per API client.

Almost nobody running automation does it. The reasoning we hear is about optics: an Automated tag on the profile supposedly signals low-quality content and depresses engagement. Maybe it does at the margin. Weigh that against the alternative, which is being processed by automated enforcement alongside accounts doing far worse things than yours. A visible label on a working account beats an invisible one on a locked account. That trade is not close.

Timing is where this gets unforgiving, and it is the part we learned by watching it go wrong. The exemption only helps if the label was applied before an enforcement wave begins. Accounts running n8n or Make HTTP module workflows without the label during a sweep get processed by automated enforcement even when posting volume is low, and retroactively adding the label after a lockdown does not reverse the action. There is no credit for good intentions discovered late. The label is insurance, and you cannot buy insurance after the fire.

The label alone is also not the whole requirement. X's developer guidelines specify a set of obligations for automated accounts: the Automated profile label, a bio disclosure identifying the account as automated, and an association with a human-managed account. All of them, not just the first. Teams routinely set the label, skip the bio disclosure because it feels redundant, and never configure the association because it sits somewhere they never look. A partial implementation is a partial defense, and the association requirement in particular is what gives X a human to hold responsible for the account.

None of this depends on which tool you use. Whether requests originate from n8n's native X node, a Make HTTP module call, or something you wrote yourself, the same policy governs the posting account. This is worth repeating because a surprising amount of tool-comparison content implies otherwise, as if picking a well-behaved integration confers compliance. It does not. The tool determines how easy it is to stay inside the rules. The account determines whether you are inside them.

There is a diagnostic benefit too. Setting the label forces a conversation most teams never have: is this account automated or not? Half-automated accounts, where a human posts sometimes and a workflow posts the rest, produce the most confusion internally and the most inconsistent behavioral signals externally. Deciding the account is automated, labeling it, and pointing it at a human-managed account produces a cleaner setup than the ambiguous arrangement teams tend to drift into.

Do this before you touch anything else in this guide. Before the Wait nodes, before the backoff configuration, before the counter. Those guards reduce the probability of triggering a review. The label changes what happens when a sweep runs anyway, and sweeps run on their own schedule regardless of how carefully your workflow behaves. Cheap, fast, permanent. There is no reasonable argument for deferring it.

If Your n8n Twitter Automation Posts AI-Generated Images, This Media Label Requirement Applies

X's Made with AI label is applied through the isAIGenerated field in the twitterOptions object of the POST /2/tweets request body, and its scope is narrower than most people assume. It only affects posts that include media attachments. Text-only posts carry no current labeling obligation under X policy, even when a model wrote every word. If your workflow generates text and posts it without media, there is nothing to set.

That asymmetry catches people in both directions. Some teams add the parameter to every post and assume they have covered AI disclosure, when on text-only posts it does nothing at all. Others reason that since the whole workflow is AI-driven the labeling question must apply everywhere, get overwhelmed, and skip it entirely. The correct read is specific: media attachments, and only media attachments. Generate an image, set the field. Generate a sentence, do not worry about it.

The detail that turns a small mistake into a permanent one is that isAIGenerated cannot be changed after publishing. There is no edit path, no follow-up API call, no support request that adds the label to an existing post. Omit it on a post containing AI-generated images and that post stays permanently unlabeled. This is why it belongs in the workflow template rather than on a reviewer's checklist. Put the parameter in the request body for every media branch and validate it before the post sends, because after the send there is no remedy.

Workflows built through Make's HTTP module are the most exposed here, and it follows directly from the native integration's removal. The HTTP module workaround silently omits isAIGenerated unless the developer explicitly writes it into the request body. Make supplies no default value, no template containing the field, and no warning when it is missing. Anyone who reconstructed X posting from the community thread after May 30, 2025 almost certainly has a request body without it, and their run history looks perfect.

Replies deserve a separate note because the two rules get conflated constantly. Automated AI-generated replies require prior approval from X before deployment, regardless of content type. Setting isAIGenerated to true on a reply does not substitute for that approval, and no combination of labeling parameters converts an unapproved AI reply workflow into a compliant one. Labeling and approval are separate obligations that happen to both involve AI. Satisfying one says nothing about the other.

The forward-looking risk is scope expansion. Right now the field does nothing on text-only posts, which is a reasonable justification for ignoring it in text workflows. If X extends the labeling requirement, workflows that never carried the parameter in their request template will be the slowest to adapt, and posts already published cannot be relabeled. Including the field in your media branches now costs a single line in a request body. It is the cheapest hedge available anywhere in this policy area.

This is where SocialNexis sits, stated plainly, and then we will stop. We build local-agent automation that runs a real browser session per account from a residential IP, so each account authenticates as an individual user and rate limits apply per-user rather than pooling against one developer app. The app-quota exhaustion described earlier in this guide does not occur under that architecture, because there is no shared app quota to exhaust. The labeling and reply rules still apply to us exactly as they apply to everyone else. Nobody is exempt from X's developer guidelines. The difference is which failure modes you have to engineer around.

Frequently asked questions

Does n8n handle X API rate limits automatically or do you have to build that yourself?

You have to build it yourself. n8n has no native rate-limit handling for its X node. When a request hits a rate limit, n8n surfaces a 429 error and the workflow stops. You must manually add Retry On Fail with exponential backoff (3 to 5 attempts, 64 to 128 second max cap), Wait nodes between posts, and a Loop Over Items counter to track quota consumption during the run.

Is the Make.com HTTP module workaround for X compliant with X's developer policies in 2026?

It can be compliant, but only if you manually add every required element that the native integration previously guided you through. That includes setting the Automated profile label on your X account, adding bio disclosure, meeting the human-managed account association requirement, and setting isAIGenerated: true in the request body for any post containing AI-generated media. Make's HTTP module provides none of these as defaults.

What happens to your X account if n8n hits a rate limit and doesn't back off?

The immediate result is that the workflow stops at the 429 and remaining posts in the run do not send. If the rate limit was triggered by a burst of requests, X may flag the account for velocity. Accounts that lack the Automated profile label when an enforcement sweep runs are processed automatically regardless of overall posting volume, and suspension is not reversed by adding the label after the fact.

Does Make.com's HTTP module require the 'Automated' label on X posts?

The label requirement comes from X's developer policy, not from Make's tooling. Whether your API requests come from Make's HTTP module or n8n's native X node, the posting account must have the Automated profile label enabled, include a bio disclosure, and be associated with a human-managed account. Make's HTTP module enforces none of these requirements and provides no reminder to set them.

Can n8n still like or follow accounts on X after the April 2026 endpoint removal?

No. X removed like and follow endpoints from all self-serve API plans on April 16, 2026. However, n8n's X node still exposes these actions in its interface. Workflows configured to perform likes or follows appear correctly set up during configuration but receive a 403 error from the X API at runtime. The failure is silent in n8n's UI until the workflow actually runs.

What is the X API rate limit for posting per 15 minutes in 2026?

The POST /2/tweets endpoint allows 100 posts per 15 minutes per user and 10,000 posts per 24 hours per developer app under X's pay-per-use model. When multiple accounts post through a single n8n OAuth2 app credential, all activity counts against the app-level 10,000/24h cap. An agency running 10 accounts at 50 posts per day each exhausts that cap in two days.

Do you need to label AI-generated content posted to X via n8n or Make?

The labeling requirement depends on content type. Posts that include AI-generated media (images, video) require isAIGenerated: true in the twitterOptions parameter of the API request. Text-only posts have no current labeling obligation under X policy even if the text was AI-generated. The isAIGenerated value cannot be changed after publishing, so it must be included in the workflow before the post sends.

What did X's 'Operation Kill the Bots' change about automated replies for n8n workflows?

From February 2026, Operation Kill the Bots restricts automated replies to situations where the original author first mentioned the bot account or quoted its post. Workflows that reply to general content without that trigger are now in violation. X additionally limits automated accounts to one automated reply per user interaction and requires prior approval before any automated AI-generated replies go live.

Is Twitter automation with n8n safe to use in 2026 without getting banned?

It is functional but carries real suspension risk without deliberate configuration. You must enable the Automated profile label before any enforcement sweep, build manual rate-limit backoff logic, avoid fixed-interval cron schedules that trigger timing-pattern detection, audit whether any like or follow actions in existing workflows now return 403 errors, and confirm your reply workflows comply with Operation Kill the Bots before running them.

Which is better for X automation compliance in 2026, Make or n8n?

Neither tool provides compliance automatically. Make's native X integration is gone as of May 30, 2025, so any Make-based automation requires custom HTTP module requests with no built-in guardrails. n8n's native X node still functions but has no rate-limit handling and still exposes endpoints X removed in April 2026. Compliant operation requires deliberate manual setup in either tool, and local-browser automation carries lower multi-account rate-limit risk than both.

Sources and further reading

• X Automation Rules
• X API Rate Limits
• n8n Rate Limit Handling