Which Social Media Schedulers Integrate With n8n?

What Integrates With n8n Actually Means

When a vendor says they integrate with n8n, they mean one of three things, and the difference decides how much glue code you write. The best case is a dedicated node, official or community-built: it appears in the n8n editor like any other node, holds your credentials, and hides the ugly parts, which for social posting mostly means multipart video uploads and each platform's auth handshake. The middle case is a documented REST API with API keys, which n8n's HTTP Request node can call like any other endpoint; everything a node does is possible here, you just build the requests, headers, and error handling yourself. The third case is neither, and no amount of n8n skill fixes a tool that never exposed its features to code.

Where you run n8n changes which nodes you can install. Self-hosted n8n takes any community node from npm through Settings and then Community Nodes. n8n Cloud is stricter: only nodes accepted into the verified community node registry are available, and the instance owner has to enable them in the admin panel. So a vendor saying they have a community node answers half the question; whether it is verified decides if anyone on n8n Cloud can use it. And hold onto one thing while reading any integrations page: a node saves you writing requests and changes nothing about what the platforms will accept, because every scheduler below posts through the same official platform APIs underneath.

The Map: Who Has a Node, Who Has an API, Who Has Neither

Checked against n8n's community node registry in August 2026. Nodes get built, verified, and abandoned faster than pages like this get updated, so treat the table as a dated snapshot and an npm search for n8n-nodes as the live source.

The Two Problems a Node Does Not Solve

Token expiry is what actually breaks these stacks. Platforms hand out access tokens that die on a schedule: Meta's long-lived tokens last about 60 days no matter what your tool does, and TikTok and Instagram connections commonly drop roughly monthly. When a token dies, every workflow behind it starts failing, quietly if nothing is watching. So the sharpest question to ask any scheduler you are about to wire into n8n is how much of the reconnect it does for you. Some refresh automatically until a password change or security event forces a human back in, some email you after the first failed post, and some leave the queue failing until you notice. Who owns the connection to your accounts, and what happens when it breaks, is the same question that decides whether third-party tools are safe to trust with client accounts.

The second problem is the platform ceilings, which apply to every row of the table equally. Publishing to Instagram through the official API requires a Business or Creator account and allows 50 API-published posts per account in any rolling 24-hour window. TikTok has no official node in n8n core and grants posting scope only to apps that pass its audit, which is why every working TikTok integration routes through some vendor's approved app. None of this is any scheduler's fault, and no scheduler is exempt from it. A vendor whose page implies special access to the platforms has earned your suspicion, not your signup.

Whatever the table says, make the trial prove your exact chain before committing. Schedule a real video to the two or three platforms you genuinely need, through the actual node or API, and watch it publish. It is the same honesty test we recommend in how to choose a scheduler, and it matters double for automation, because you are buying the API surface and the dashboard screenshots tell you nothing about it. If self-hosting is on the shortlist, our guide to self-hosted schedulers covers what becoming the developer of record actually costs before the n8n wiring even starts.

Keep the Queue in n8n, Not in the Scheduler

The setup that survives is an architecture rather than a vendor. Keep n8n as the queue and the source of truth. Hold every planned post as a row in a table you own, a database or even a spreadsheet: platform, media URL, scheduled time, the ID the scheduler hands back, status, a retry-after time, and the last error. n8n creates and validates the job, the scheduler only executes the posting step, and a second workflow writes the outcome back to the row, by webhook where the vendor offers one and by polling where it does not.

That shape pays for itself twice. The scheduler becomes a swappable adapter instead of a dependency, so if your posting tool loses a platform or triples its price you replace one step and the queue, the history, and everything downstream stay put. A practical version is one adapter as the default with a separate path for the platforms it misses, instead of demanding one vendor cover everything forever. And you can see what actually went out: when a posting service has a bad day, an outsourced queue backs up or drops posts and you find out from a client rather than a dashboard, where a status table you own turns that silence into rows marked failed that a retry workflow can walk.

It also answers the stability question honestly. No stack at this layer is babysit-free, because the platforms underneath keep changing tokens, caps, and rules. The realistic goal is a stack where the babysitting takes five minutes, because every failure is visible in one table and the fix is one workflow run, instead of a hunt across four vendors' dashboards.

Where Maeve Fits, Honestly

Maeve does not have an n8n node today. What it has is an ordinary REST API: the whole app surface, content, media, analytics, inbox, grid planner, sits behind versioned JSON endpoints with bearer-token auth, so in n8n you use the HTTP Request node with an API key from workspace settings in the Authorization header. The full surface is described by an OpenAPI 3.x spec generated from the running code and served with an interactive reference in the developer docs, which matters more for HTTP Request wiring than it would for a node, because the spec is where every path and payload shape gets copied from instead of guessed at.

The limits, so you can plan around them instead of discovering them. Rate limits run per workspace per minute: 120 reads, 30 writes, and 15 for expensive calls like publish and retry, answered with a 429 and a Retry-After header when you cross one, which n8n's built-in retry settings handle without drama. And there are no outbound webhooks for post lifecycle yet, so the status-update half of the queue pattern above runs on polling: a scheduled n8n workflow calls the content list with a since timestamp and reconciles your status table. That is the supported route until lifecycle webhooks ship, and the same endpoint already does quieter jobs like per-client CSV exports of the schedule.

If your automation lives somewhere other than n8n, the same backend has two other doors: the maeve-cli is generated from the OpenAPI spec and speaks JSON for shell scripts and cron, and the MCP server exposes a curated toolset to Claude, Cursor, and other AI agents, a route scheduling posts from ChatGPT or Claude covers end to end. All three write to the same audit log as the web app, so a post scheduled by a workflow is a first-class post, on the calendar with its history, and a teammate can see it, edit it, or cancel it like any other.