Automatically publishing on X (Twitter) with n8n and AI

On X, the window between a piece of news and its relevance is measured in hours, not days: a technical thread published the day after a hot topic has already missed the attention spike. It's the platform where automation pays off the most — and where it shows the fastest if poorly designed. This guide builds an n8n pipeline that speeds up drafting with AI without ever publishing without human sign-off, and covers the most common technical trap on X: authentication, which differs depending on whether you're publishing text or attaching an image.

Native X node or HTTP Request: picking the right building block

n8n ships a native X (Formerly Twitter) node with ready-made actions: create a post, delete a tweet, like, retweet, search, send a direct message. Its predefined OAuth2 credential covers the common scopes (tweet.write, tweet.read, users.read, offline.access) and is plenty for a scheduled text post.

The limit shows up on finer needs: polls embedded in a post, precise handling of thread replies, or conditional logic over the request body that the node doesn't natively expose. In those cases, an HTTP Request node doing a POST to https://api.x.com/2/tweets with an Authorization: Bearer <access_token> header reproduces exactly what the native node does, with full control over the JSON payload — the same call we made in our guide to automating LinkedIn posts with n8n, where the API moves faster than a generic node's coverage.

The media upload trap: OAuth2 isn't always enough

This is the point that stalls the most n8n workflows on X: publishing plain text under OAuth2 works without a hitch, but attaching an image often runs into a 403 error on the upload endpoints — including the newer three-step v2 endpoints (/2/media/upload/initialize, /append, /finalize) meant to replace the old v1.1/media/upload.json. Plenty of developers still report this behavior on X's developer forum at the time of writing, with the exact same OAuth2 token publishing text without issue.

The workaround that reliably holds up in practice:

1. Keep the OAuth2 credential on the X node (or HTTP Request) for publishing the post itself (/2/tweets).
2. Create a second OAuth 1.0a credential (classic API key/secret plus access token/secret) dedicated solely to the media upload step.
3. A first HTTP Request node, authenticated with OAuth 1.0a, uploads the file and retrieves the media_id.
4. The publishing node (OAuth2) references that media_id in the post's media.media_ids array.

This asymmetry isn't an n8n configuration bug — it's the current state of the X API, worth re-checking against the official docs since it keeps shifting. Better to plan for both credentials at design time than to discover the block in production.

The four-step pipeline

1. A scheduled trigger and a source of topics

A Schedule Trigger (three times a week, for example) kicks off the workflow. The source can be a topic list prepared in a Notion content calendar — see our guide to a multi-network content calendar with Notion and n8n — or an industry news feed aggregated by an RSS Feed Read node, on the same principle as our AI-powered competitive monitoring guide.

2. Drafting with an AI Agent

An AI Agent node receives the topic and a strict system prompt: target length (280 characters for a single post, a multi-tweet structure for a thread), brand voice, few-shot examples of past posts, and a blocklist of generic phrasing to avoid. This is where the time savings actually show up: X rewards responsiveness, and a draft produced in seconds rather than twenty minutes lets you react to news while it's still hot.

That gain has a documented limit, though. A 2024 study by Radivojevic, Chou, Badillo-Urquiola, and Brenner (University of Notre Dame), which recruited more than 1,000 participants to distinguish human posts from AI-generated ones in social media discussion threads, found that human readers are poor at explicitly identifying this content — yet still register a diffuse sense of unease when reading it, a textual "uncanny valley" effect (Radivojevic et al., 2024). In practice: don't rely on "no one will notice" as a reason to skip human review — the unease is still perceptible even without conscious identification.

3. Mandatory human review before publishing

The draft never goes straight to X. It's sent to Slack for review, reusing the human-in-the-loop pattern detailed in our article on human approval with the Wait node and Slack buttons: a Wait node in On Webhook Call mode pauses the workflow, a Slack message presents the draft with "Publish" / "Edit" / "Reject" buttons, and only an explicit action resumes execution through the resumeUrl. On X more than elsewhere, this step also catches context mistakes an LLM can make about breaking news — a real risk precisely when publishing speed is the whole point.

4. Publishing through the X API

Once approved, the post goes to the /2/tweets endpoint:

POST https://api.x.com/2/tweets
Headers:
  Authorization: Bearer <access_token>
  Content-Type: application/json
Body (JSON):
  {
    "text": "{{ $json.approvedPost }}"
  }

For a thread, each following tweet references the previous one's ID via reply.in_reply_to_tweet_id, which means capturing the id returned by each call before chaining the next one — a natural fit for a Loop Over Items rather than firing calls in parallel, on the same pacing principle described in our guide on AI API rate limits in n8n (X's publishing quotas follow the same sliding-window logic).

Useful variants

• Turning a blog post into a summary thread: the AI Agent receives the full content of an already-published article and generates a 3-to-5-tweet thread summarizing its key points, with a link to the article as the last post.
• Monitoring and fast reaction: the same RSS feed that powers a digest can also trigger a draft post as soon as a news item matches watched keywords, with Slack review as the only gate before publishing.
• Deferred scheduling: instead of a single Schedule Trigger, a Supabase table of pre-approved posts paired with a regular cron lets you spread approved posts across the day from a single review session.

Securing both credentials

Two separate credential sets coexist in this pipeline (OAuth2 for publishing, OAuth 1.0a for media upload): treat them with the same rigor as any sensitive API credential, following the principles in our guide to securing API credentials in n8n — restrict access to only the workflows that need them, and plan for rotation if a leak is ever suspected.

In summary

The pipeline comes down to four building blocks: a Schedule Trigger for pacing, an AI Agent for the first draft, Wait + Slack for human review, and HTTP Request (or the native X node) for publishing — with particular attention to the dual authentication as soon as an image is involved. The AI-assisted generation and human-review patterns built here are the same ones powering the draft workflows in the Inbox AI Pack: once the principle clicks on X, it carries directly over to other channels.