Social Media Automation Rules: What Gets AI Agents Banned

The social media automation rules that actually get accounts suspended are not the ones people worry about. I went and read the developer terms for every major platform, and the folk belief that third-party tools are the risky path while doing it yourself is safer turns out to be backwards in writing.

X states it plainly. Using non-API automation, such as scripting the X website, “may result in the permanent suspension of your account.” The browser bot is the thing that gets you banned. The API is the sanctioned route.

Once you read all six documents side by side, the line every platform actually enforces is not publishing versus automation. It is publishing versus engagement. Your agent posting content is fine nearly everywhere. Your agent replying, liking and following is where the suspensions live.

One platform is a genuine exception, and it is the one that quietly rules out the fully autonomous setup most people are building. That is where this starts.

Social Media Automation Rules at a Glance (2026)

I pulled these from each platform’s own developer terms and user agreement, not from summaries.

Platform	Automated publishing	Automated engagement	The clause that governs it
X	Permitted outright	Keyword-triggered replies prohibited	Automation rules, updated April 2026
LinkedIn	Sanctioned via the API	Unauthorized bots driving inauthentic engagement prohibited	User agreement 8.2
YouTube	Permitted with express consent	Requires prior specific and express user consent	Developer policies III.I.2
Meta	No automation clause in the Platform Terms	Frequency limits apply, manual or automated	Platform Terms 3.a plus the spam standard
TikTok	Permitted once your client passes audit	No published engagement policy	Content Posting API
Pinterest	Requires per-item human choice	Prohibited without specific consent	Developer guidelines

The pattern holds across five of the six. Publishing through the official API is the permitted path, and the prohibitions cluster around actions taken toward other users. Pinterest is the one that breaks the pattern, and it breaks it hard.

Start free week →

Free 7-day trial · Cancel anytime

Pinterest Is the Real Exception

If your mental model is “hand it to the agent and walk away,” Pinterest is where that model breaks, and it breaks at the design level rather than the configuration level.

Pinterest’s developer guidelines prohibit “taking actions on behalf of end users without their specific knowledge and consent,” and the enumerated list explicitly includes “creating, saving and editing Pins.” It also prohibits “offering features that enable end users to automatically initiate actions without specifically considering each action.”

Then it gives the example that settles it: “if your app allows end users to schedule Pin publishing, the end user must choose each Pin to be published.”

The end user must choose each Pin. Individually. That is not a rate limit you can pace around or an approval you can apply for. It is a design constraint that rules out a fully autonomous Pinterest agent, because the human has to be in the loop on every single item. An agent that generates a batch of Pins and ships them unattended sits outside the guidelines no matter how well-behaved its request pattern is.

I would be a bad founder if I let you discover that one in production. Keep a human selecting Pins, and treat Pinterest as the platform where your agent drafts and you approve.

The Rule That Catches Builders Off Guard

Here is the one almost nobody has read, and it is the reason I wrote this post.

X’s automation rules, at section II.A of the version updated April 2026, say that a user authorizing your app through OAuth “does not by itself constitute sufficient consent to take automated actions through that user’s account.”

Read that twice if you build multi-tenant software. The consent your agent needs is not the consent your OAuth flow collected. X requires three separate things: you clearly describe the types of automated actions that will occur, you receive express consent for those actions, and you immediately honor an opt-out request. Change what your app does in a substantial way and you have to collect that consent again.

This applies to “any automated action taken through another X user’s account, including posting posts, sending Direct Messages, deleting posts or Direct Messages, or following/unfollowing other accounts.” If you are building a tool where your customers connect their own accounts, your OAuth screen is not the compliance story. The disclosure is.

YouTube writes the same requirement more bluntly. Its developer policies say you “must not automate or trigger views, uploads, comments, likes, dislikes, or other actions without the user’s prior specific and express consent.” Note that uploads are named in that list. Publishing on someone else’s behalf is a consented action on YouTube, not a free one.

Where the Line Sits: Publishing Versus Engagement

X permits automated broadcasting in the affirmative. Its ground rules open with “Do! Build solutions that automatically broadcast helpful information in posts.” That is the platform inviting the exact thing people assume is forbidden.

What it prohibits is automating the reply and mention functions to reach people who did not ask. The rule names the specific failure mode: “sending automated replies to posts based on keyword searches alone is not permitted.” Auto-replies are allowed only where the recipient opted in first, you offer a clear opt-out, and you send one reply per interaction. X adds that a user following your account is not on its own sufficient indication of intent.

LinkedIn is where most people get this wrong, because the clause reads harsher than it is until you notice two words. Section 8.2 prohibits members from using “bots or other unauthorized automated methods to access the Services, add or download contacts, send or redirect messages, create, comment on, like, share, or re-share posts, or otherwise drive inauthentic engagement.”

Commenting, liking, sharing and re-sharing are all named. But the clause bans unauthorized automation that drives inauthentic engagement, and those two words are doing real work. They are precisely what leaves room for the sanctioned path. LinkedIn ships a product called Share on LinkedIn whose w_member_social permission is documented as “Post, comment and like posts on behalf of an authenticated member,” and it sits in the Open Permissions table, meaning any developer can add it self-serve without partner approval. Read those two documents together and the picture is clear. Authorized publishing through the API is something LinkedIn hands out on request. Scripted commenting from a headless browser is what 8.2 is aimed at.

That distinction is the whole post in one line. Automate what you say. Do not automate what you do to other people.

Meta Has No Anti-Automation Rule, and That Surprises People

I expected Meta to be the strict one. It is the opposite.

Meta’s Platform Terms enumerate prohibited practices in section 3.a, and automation is not among them. There is no clause banning bots, no clause banning programmatic posting, no clause banning agents. The document is concerned with data handling, surveillance, reverse engineering and unapproved functionality.

The restriction lives somewhere else entirely, in the Community Standards spam policy, and the wording is worth quoting because it is routinely misread. Meta prohibits “posting, sharing, engaging with content or creating accounts, Groups, Pages, Events or other assets, either manually or automatically, at very high frequencies.”

Two things follow from that phrasing. The operative constraint is frequency, not automation. And the same rule is written to cover manual activity, which means Meta is not policing whether a machine did it. Anyone telling you Meta restricts automated posting as such has not read the source. What Meta restricts is volume, by whatever hand.

Instagram then puts a real number on the publishing side: accounts are limited to 100 API-published posts in a rolling 24-hour window, with carousels counting as one post. I dug into what that cap and the platform-by-platform ceilings do to an always-on queue in does API posting hurt your reach, so I will not repeat the analysis here.

TikTok Gates You on an Audit, Not a Rule

TikTok’s constraint is procedural rather than prohibitive, and it produces the most confusing failure mode in the category.

Unaudited clients can only post to a private account. Your API call succeeds, the video uploads, and nobody can see it. Nothing in the response tells you that you are shipping into a void. That is a documented restriction rather than a bug, and it is the single most common reason a working TikTok integration appears to do nothing.

The Direct Post API reference also documents the enforcement your agent will actually hit. Each user access token is limited to 6 requests per minute. Three error codes tell you which ceiling you crossed:

Error code	What it means
spam_risk_too_many_posts	The daily post cap from the API is reached for the current user
spam_risk_user_banned_from_posting	The user is banned from making new posts
reached_active_user_cap	The daily quota for active publishing users from your client is reached

TikTok’s content sharing guidelines do put a figure on the daily cap, and it is worth reading the exact wording before you design a queue around it: “the upper limit may vary among creators (typically around 15 posts per day/ creator account).” Typically and varies are the operative words. Handle spam_risk_too_many_posts as a real state your agent will hit rather than treating 15 as a fixed ceiling you can schedule against.

Bluesky states the thesis of this entire post more plainly than anyone. Its bot documentation opens with “automated bots that post to an account on an regular interval are welcome,” then draws the same line everyone else draws: “if your bot interacts with other users, please only interact (like, repost, reply, etc.) if the user has tagged the bot account. It must be an opt-in interaction.” Publishing welcomed, engagement opt-in only. It also asks that bot accounts identify themselves with a self-label on the profile, which is the one disclosure requirement in this set that costs you nothing to honor.

Threads is the gap. I could not find a separately published Threads automation policy, and it falls under Meta’s Community Standards, so the frequency rule above is the one to design against.

What This Means for the Agent You Are Building

Four decisions fall out of reading all six documents.

Budget for the approval, not the workaround. The browser bot is usually chosen to skip an API approval queue, which trades a few weeks of waiting for the one method carrying a stated suspension risk. Start the TikTok audit and the Meta app review early and treat them as lead time rather than as an obstacle to route around.

Let the agent publish, keep engagement human. Replies, likes, follows and comments are where the prohibitions concentrate on X, LinkedIn and YouTube. Publishing is broadly permitted. Draw your automation boundary along that seam and you remove the largest category of risk, though content rules, consent and app review all still apply.

If your customers connect their own accounts, build the consent screen. X’s II.A means your OAuth flow is not sufficient on its own. Describe the automated actions, collect express consent, honor opt-outs immediately, and re-collect consent when your product changes materially.

Pace the queue. Meta polices frequency regardless of who is typing. An agent flushing thirty posts at 3am is the exact behavior these thresholds exist to catch, and the fix is a queue with spacing, not a different vendor.

The Honest Pitch: One Social Media API, Nine Platforms

Here is my bias in the open. I built Blotato, so read this section knowing that.

The compliance work above is real, and it is per platform. Six documents, six sets of rules, six OAuth flows, six sets of error semantics, and each one changes without telling you. X updated its automation rules in April 2026. That maintenance never ends, and it is the part nobody budgets for when they estimate the integration.

That is the actual counterfactual worth pricing. Not Blotato against one competitor, but one key against a separate API, a separate approval process and a separate set of terms for every platform you want to reach.

One API. Every social platform.

Blotato publishes to nine platforms through each platform’s real API, not a browser bot, which puts your posting method on the sanctioned side of the rule this post opened with. It does not settle the rest of the compliance question, and I will come back to that below. One call:

curl -X POST https://backend.blotato.com/v2/posts \
  -H "blotato-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "post": {
      "accountId": "YOUR_ACCOUNT_ID",
      "target": { "targetType": "linkedin" },
      "content": {
        "platform": "linkedin",
        "text": "Posted via the Blotato API."
      }
    }
  }'

Two things that will bite you if you skip them. content.platform is a required field, and every example in the docs sets it to the same value as target.targetType, so both read linkedin above. And the call is asynchronous: it returns a postSubmissionId, which is a receipt rather than proof of publication. Poll the post-status endpoint with that ID until it reports a terminal state before you log the post as shipped, and remember a scheduled post sits in scheduled rather than moving straight to published.

You get accountId from GET /users/me/accounts, pageId for Facebook and LinkedIn company pages from GET /users/me/accounts/:accountId/subaccounts, and boardId for the Pinterest flow above from GET /social/pinterest/boards. If you are on MCP you never touch any of them, because the agent lists your accounts and passes the right ID itself. Full reference is at help.blotato.com/api/start.

Blotato runs an MCP server at https://mcp.blotato.com/mcp, so Claude Code, Claude Desktop or any MCP-compatible agent can publish to your accounts without you writing an integration against any platform’s auth flow. In practice that looks like Claude Code drafting a post and shipping it in the same session, or an agent reacting to an event in your own system and publishing the result.

What it does not do is exempt you from the rules. Publishing through Blotato does not grant consent you have not collected, and it will not make a Pinterest agent compliant when Pinterest requires you to choose each Pin. Every platform rule in this post still applies to your workflow. What changes is that you maintain one integration instead of six.

Worth being straight about the trial: it excludes API access, and generating an API key ends it and starts the Starter subscription. If you came here to wire up an agent, plan on starting the subscription rather than trialing it.

Start a free week →

Where I Come Down On This

The category has this exactly backwards. Builders spend weeks engineering around a ban risk that the documents locate somewhere else entirely, then reach for a browser bot because it feels more under their control, which is the one approach carrying an explicit permanent-suspension warning.

I am biased, obviously. But the reason I built Blotato was not that platform APIs are hostile. It is that there are six of them and they each move independently. Read the terms for whichever platforms you are shipping to and draw your line at engagement rather than publishing. That is the decision that removes the most risk on five of the six. On Pinterest it is not enough, because a human has to choose each Pin, and on YouTube publishing on someone else’s behalf still needs their express consent.

Social Media Automation Rules FAQs

Will using an AI agent to post get my social media account banned?

Publishing through a platform’s official API is permitted on most of them. X permits automated broadcasting in its own ground rules, LinkedIn sells API access for programmatic publishing, and Meta’s Platform Terms contain no anti-automation clause. The conditions that still bind are consent on YouTube, per-Pin human selection on Pinterest, and frequency limits everywhere. Suspensions concentrate around automated engagement and around non-API automation like scripting a website.

Is it safer to build my own automation than to use a third-party tool?

The documents point the other way, and X is the most explicit about it. Building your own is fine when you build on the API. What carries the stated suspension risk is the method people reach for when they want to avoid API approval, which is driving the website with a script. The question is not who wrote the tool, it is whether the tool uses the sanctioned interface.

Does my OAuth flow count as user consent to automate their account?

No, and this catches multi-tenant builders constantly. X’s automation rules at II.A state that OAuth authorization “does not by itself constitute sufficient consent to take automated actions through that user’s account.” You must describe the actions, obtain express consent, and honor opt-outs.

Can an AI agent post to Pinterest automatically?

Not fully. Pinterest’s developer guidelines require that where an app schedules Pin publishing, “the end user must choose each Pin to be published.” A human has to select each item, so a Pinterest agent should draft and queue rather than publish unattended.

Why did my TikTok post upload successfully but never appear?

Almost certainly the audit gate. Unaudited clients can only post to a private account, so the request succeeds and the video is invisible. Passing TikTok’s client audit is what changes it, and no code fix will.