How to Build an n8n Social Media Workflow With an API

Most n8n social media tutorials stop at “it posted once”. That part takes twenty minutes. The part that takes a week is everything after: posts that fail hours later, time zones that shift under you, and one network rejecting an image the other eight accepted.

This walks through a workflow that reads content from a spreadsheet, schedules it across every connected account, and tells you when something broke. It uses SchedPilot as the worked example because its API is on the $21 entry plan rather than reserved for an agency tier, but the shape is identical on any scheduler — swap the endpoint paths for the ones in your provider’s docs.

What you need first

Connect your social accounts inside the scheduler’s own app before you touch n8n. The scheduler holds the OAuth tokens and handles refreshing them, which is most of the reason you are paying it rather than integrating with Meta and LinkedIn yourself.

Then generate an API key from the scheduler’s settings, and have somewhere for content to live. A Google Sheet or Airtable table with columns for text, image URL, target accounts and publish time is enough, and it means a non-technical person can queue content without opening n8n.

Step 1: store the key as a credential, not in the node

In n8n, create a new Header Auth credential. Set the name to Authorization and the value to Bearer YOUR_API_KEY. Every HTTP Request node then selects that credential instead of carrying the key.

This is worth the extra minute. A key pasted into a node header ends up in workflow exports, in version history, and in whatever you paste into a support chat when something breaks.

Step 2: get your account IDs once

You post to account IDs, not handles. Add an HTTP Request node, GET the accounts endpoint, and run it manually once.

GET https://api.your-scheduler.com/v1/accounts
Authorization: Bearer YOUR_API_KEY

Copy the IDs into your spreadsheet as a reference column. They do not change, so there is no reason to call this endpoint on every run — and one fewer call per execution matters once this is firing hourly.

Step 3: pick the trigger

Three sensible options, and the choice shapes everything downstream.

Schedule Trigger runs every hour, reads rows marked ready, and schedules them. This is the one to build first. It is easy to reason about and easy to re-run when something fails.

Webhook fires when your CMS publishes something, so a new blog post becomes social posts immediately. Good, but you lose the natural batching and you need the webhook to be reliable.

Google Sheets trigger fires on row changes. Convenient and the least predictable of the three, because a stray edit re-triggers it.

Whichever you choose, add a status column and write back to it. A workflow that cannot tell which rows it has already processed will eventually post everything twice, and duplicate publishing is the failure your clients notice.

Step 4: upload media before you reference it

If a post has an image or video, upload it as its own step and keep the returned media ID. Most scheduler APIs reject a post whose media is still processing, and video processing takes minutes rather than seconds.

In practice: HTTP Request node, POST the file to the media endpoint, then pass {{ $json.media_id }} into the next node. For video, add a Wait node of thirty to sixty seconds, or poll the media status until it reports ready. Skipping this is the most common reason a workflow that passes manual testing fails on real content — your test image was 40KB and the real one is a 60MB Reel.

Step 5: create the post

One HTTP Request node, POST, JSON body. Field names differ between providers but the shape does not.

POST https://api.your-scheduler.com/v1/posts
Content-Type: application/json

{
  "accounts": ["acc_instagram_123", "acc_linkedin_456"],
  "text": "{{ $json.caption }}",
  "media": ["{{ $json.media_id }}"],
  "scheduled_at": "{{ DateTime.fromISO($json.publish_time).toUTC().toISO() }}"
}

That toUTC() is not decoration. Send UTC and convert on your side, because a scheduler that silently applies a workspace time zone will publish an hour early after a daylight saving change, and nobody notices until a client does. n8n ships Luxon for exactly this, so use it rather than string-concatenating a timestamp.

Step 6: the part tutorials skip

A 200 response means the scheduler accepted your post. It does not mean the post published. That happens later, when the network either takes it or rejects it, and a workflow that stops at the 200 is blind to the half of the failures that matter.

Two things to add. First, check status per account rather than per post: the same request can succeed for LinkedIn and fail for Instagram over an image aspect ratio, so read the per-account result array and branch on it with an IF node. Second, either subscribe to the scheduler’s webhook for post status, or add a second Schedule Trigger workflow that runs a few hours later and polls anything still pending.

Then route failures somewhere a person looks. An Error Trigger workflow posting into Slack with the row number and the scheduler’s error message turns a silent failure into a thirty-second fix. Without it you are relying on noticing an absence, which nobody does.

Step 7: the agent variant

Everything above is deterministic: you built a branch per operation and it does exactly that. The alternative is n8n’s AI Agent node with an MCP Client Tool pointed at the scheduler’s MCP server.

With that, the agent gets the whole product as callable actions and no HTTP Request nodes at all. You describe the outcome in the prompt and it works out which calls to make, including operations you did not anticipate when you built the workflow. SchedPilot is currently the only tool in this directory with a native MCP server; for anything else you would go through a gateway or write the wrapper yourself, which the MCP server round-up covers.

The trade is that you have given up knowing exactly what will happen. That is fine for drafting and triage and bad for publishing. The configuration worth running is an agent that drafts into an approval queue and has no publish tool at all — on SchedPilot the queue is on the $79 Enterprise plan, which is the honest catch.

What to leave out of the workflow

Automating the writing is where these projects usually go wrong. A workflow that generates captions from a template and posts them on a schedule produces a feed that is technically active and visibly automated, and the engagement reflects that.

The automation worth building handles the mechanical parts: formatting one idea for nine networks, uploading media, converting time zones, retrying failures, writing results back. Keep a human on the sentence. If the problem you are actually trying to solve is knowing what to write, working from posts that already performed is the more direct route than generating more of them.

Also leave out anything time-sensitive on a first build. Launches and events want an owned timestamp and a person watching, not a queue.

Common failures and what causes them

Symptom	Usual cause
Posts an hour early or late	Local time sent instead of UTC, or the workspace time zone applied on top
Everything posted twice	No status column written back, so the trigger reprocessed the same rows
Succeeds for text, fails for video	Media referenced before processing finished; add a wait or poll
Eight networks fine, one rejected	Per-network media rules; check the per-account result, not the post
Reported success, nothing published	Only the 200 was checked; the network rejected it later
Worked in testing, fails live	Rate limits, or real media much larger than test media

If you are still choosing a scheduler to build this on, our scheduler API comparison covers eight of them on price and capability, and SchedPilot vs Buffer for automation is the head-to-head if those are your two candidates.

Frequently asked questions

Does n8n have a node for social media scheduling?

n8n has nodes for some networks directly, but no first-party node for the major schedulers, so you build on the HTTP Request node. Check the community nodes before starting from scratch, since someone may have packaged the one you need.

Can I post to Instagram from n8n without a scheduler?

Technically yes, through Meta’s Graph API. You will need App Review and business verification before you can reach any account but your own, which commonly runs past a month, plus token refresh roughly every sixty days. For most teams that is more expensive than paying a scheduler.

How do I avoid duplicate posts?

Write a status back to the source row as soon as the scheduler accepts the post, and filter on that status in the trigger. Do it in the same execution rather than at the end, so a workflow that dies halfway does not re-queue what it already sent.

Should the workflow or the scheduler decide the publish time?

Let the scheduler handle it for evergreen content by adding posts to a queue, which means one less thing in your workflow. Own the timestamp for anything time-bound like a launch, where the exact minute matters.

Can n8n call an MCP server?

Yes, through the MCP Client Tool attached to an AI Agent node. The agent then discovers the available actions itself instead of you wiring an HTTP Request node per endpoint.

Is self-hosted or cloud n8n better for this?

Either works. Self-hosting is cheaper once you are running thousands of executions and means the API keys stay on your own infrastructure. Cloud is one less thing to keep patched. Neither changes how the workflow is built.