Make.com social media automation: the templates, and where they break

Make.com is one of the fastest ways to get a social post out of a spreadsheet and onto a timeline. The template gallery makes it look solved: pick a blueprint, connect an account, switch the scenario on. Then you count the platforms, and the gaps start showing. The X app was removed from Make in 2025. The TikTok app manages ad campaigns and cannot publish a video. Instagram can post a photo, a reel and a carousel, but not a story.

So this is the version of the guide with the gaps filled in: the publishing modules that genuinely exist today, a scenario you can copy and run this afternoon, the four places it breaks, and the one-HTTP-module pattern that collapses a nine-module fan-out into a single request.

Every module name and limit below was checked on 1 October 2026 against Make's own app documentation, and the links go to the pages I read. Module catalogues move; re-check before you build.

What you can actually automate in Make.com today

Make's social media category is narrower than the marketing around it. Here is what the native publishing modules do, app by app:

Read that table as a scope decision, not a feature list. If your posting set is Facebook, Instagram, LinkedIn and YouTube, the native modules will carry you a long way. If it includes X, TikTok or Threads — and for most brands in 2026 it does — the native modules cover part of your problem and you need a second mechanism for the rest.

A working scenario, start to finish

Here is the shape that actually survives contact with a content calendar: one trigger, one source of truth, one router, one module per destination.

1. Trigger — `Schedule` (built in). Set *Run scenario* to At regular intervals, 15 minutes. Do not use a webhook from your CMS unless you want publishing failures to surface in your CMS.

2. Source — Google Sheets › `Search Rows`. Sheet columns: publish_at, copy, image_url, platforms, status. Filter: status equals queued. Set *Maximum number of returned rows* to 10 so a bad formula cannot fan out across your whole calendar.

3. Gate — a filter on the connection out of the Sheets module. Condition: publish_at → Earlier than or equal to → {{now}}. This is the piece people leave out, and it is why scenarios post everything at once the first time they run.

4. Fan-out — `Router`, then one publishing module per branch, each with its own filter on the platforms column:

• LinkedIn › *Create a Company Text Post* — *Author* = your organisation, *Text* = {{2.copy}}, *Visibility* = PUBLIC
• Facebook Pages › *Create a Post with Photos* — *Page* = your Page, *Message* = {{2.copy}}, *Photos* → *URL* = {{2.image_url}}
• Instagram for Business › *Create a photo post* — *Image URL* = {{2.image_url}}, *Caption* = {{2.copy}}

5. Write back — Google Sheets › `Update a Row`, setting status to posted. Without this the next run re-posts every row.

That scenario works. Run it, and it will publish. The problem is what happens when you add the fifth platform.

Where the native modules run out

Apps get removed, and your scenario stops

Make discontinued the X (formerly Twitter) integration because, in Make's words, X's "API policy requirements and pricing prevent us from providing a reasonable integration to our customers." The timeline was: from 3 April 2025 you could no longer create new scenarios using the X app, and on 30 May 2025 existing X scenarios stopped working. They remain visible, and they fail on execution.

That is the real risk with a no-code social stack, and it is not a hypothetical. Your publishing path depends on a commercial relationship between two companies you are not party to. When it ends, your scenario does not degrade — it errors.

Apps exist but do not publish

The TikTok app is the clean example. It is listed in Make's social media category, it has twenty modules, and not one of them posts a video. If your plan was "automate TikTok in Make," there is nothing to automate against: you are writing HTTP calls to TikTok's Content Posting API yourself, with its direct-post audit and its unaudited-app restrictions — forced SELF_ONLY visibility and a cap of five distinct creators per 24 hours.

Nothing tells you a token died

Every social platform expires tokens, and they expire on their own schedules. Make has no module that fires when a connection goes stale. You discover it when a scenario run fails, which is after the post did not go out. If nobody is watching the execution history, the gap between "broken" and "noticed" is however long it takes someone to ask why the LinkedIn posts stopped.

Every destination is another module on every run

Make bills by operation, and in a fan-out each publishing module is another operation on each run. Nine destinations is nine modules to configure, nine sets of credentials to keep alive, nine filters to keep consistent, and nine places for the copy to drift. There is also no single view of "what happened to this post on each platform" — you reconstruct it from the run log, bundle by bundle.

The one-HTTP-module pattern

The alternative is to stop treating each platform as a separate integration. Keep the trigger, the sheet, the filter and the write-back; delete the router and the per-platform modules; replace all of them with one HTTP › Make a request module pointed at a unified publishing API.

Configure the module like this:

• URL — https://api.outstand.so/v1/posts/
• Method — POST
• Headers — one item: *Name* Authorization, *Value* Bearer YOUR_API_KEY
• Body content type — application/json
• Body input method — Raw
• Request content — the JSON below
• Parse response — Yes
• Return error if HTTP request fails — Yes (leave this on; you want failures to be failures)

The payload is one object. One call, every destination:

1{
2  "containers": [
3    {
4      "content": "{{2.copy}}",
5      "media": [
6        { "url": "{{2.image_url}}", "filename": "card.jpg" }
7      ]
8    }
9  ],
10  "accounts": ["Kx7vQ", "Tm2bN", "9pLwR"],
11  "scheduledAt": "{{formatDate(2.publish_at; \"YYYY-MM-DDTHH:mm:ss\")}}Z"
12}

Three things about that payload that will cost you an afternoon if you skip them:

1. `accounts` takes account identifiers, not network names. Each entry is the opaque id of a connected account, from GET /v1/social-accounts. "linkedin" is not an identifier and does not resolve. Call the list endpoint once, paste the IDs into the module, and treat them as opaque strings — never construct one.
2. Unresolvable entries are dropped silently. The request only fails if *none* of the identifiers resolve. ["Kx7vQ", "linkedin"] returns success: true and publishes to Kx7vQ alone. So check post.socialAccounts in the parsed response against what you asked for, rather than trusting the 200.
3. `scheduledAt` is capped at 30 days out. Omit it, or pass a past timestamp, and the post publishes immediately. A timestamp further than 30 days ahead is rejected with a 400 and nothing is created — which is why the Schedule trigger and the publish_at filter in step 3 stay in the scenario. The sheet is your long calendar; the API is the next 30 days of it.

Each extra destination now costs you one more string in an array. The platforms with no Make app — X, TikTok, Threads, Bluesky — go in the same array as the ones that have one, because the fan-out happens server-side rather than in your scenario.

Error handling you will need either way

Whichever route you take, publishing is a network call to someone else's rate-limited service, so plan for it to fail.

In Make: right-click any module and add an error handler route. Make's error handlers are *Retry* (store the run as an incomplete execution and retry it, automatically or by hand), *Resume* (substitute a value and carry on), *Ignore* (treat the failed bundle as resolved and keep processing the rest), *Commit* (stop, keep the changes) and *Rollback* (stop, revert). For a publishing module, *Retry* is almost always the one you want: a rate-limit error is temporary, and an incomplete execution you can replay is better than a post that silently never went out.

Set `status` to `failed`, not `posted`, on the error route. The most common bug in scenarios like this is a write-back that runs regardless of outcome, which marks a failed post as published and guarantees nobody ever retries it.

For token expiry, subscribe rather than poll. If you are going through a unified API, Outstand emits webhooks for account.token_expired, post.published and post.error — point them at a Make webhook trigger in a second, tiny scenario that posts to your team's Slack. That turns a silent expiry into a message. The payloads are signed with HMAC-SHA256 in an X-Outstand-Signature header, so verify it before you trust the body.

Read outcomes per account, not per post. A fan-out publish is not binary. Each target account carries its own status (pending, published, failed), its own error string, and its own platformPostId once it lands. A post where four platforms succeeded and one hit a media error is the normal case, and "did the post work?" is the wrong question to build your alerting on.

When Make.com is the wrong tool

Make is good at what it is for: gluing systems together where a human owns the process and a 15-minute delay is fine. If that is your situation, the scenario above plus a retry handler is a solid place to stop.

It is the wrong tool in three cases, and it is worth saying so plainly:

• Publishing is in your product's critical path. If your users press a button and expect a post, you do not want a Make scenario in that path. You want an HTTP call from your own code, synchronous, with your own error handling — see our practical guide to social posting APIs for what that looks like end to end.
• You need the automation under version control. A scenario is a diagram in someone's account. There is no diff, no code review, and no staging copy that is guaranteed to match production.
• You are self-hosting or you want the workflow in a repo. That is the n8n case, not the Make case — same one-node pattern, different runtime.

If you are building a scheduler rather than automating your own posting, skip the no-code layer entirely: start from how to build a social media scheduler and the comparison of unified social media APIs. Still choosing a category — scheduler, workflow platform, or API? We have compared the social media automation tools on exactly that axis.

One call, twelve networks, and the platforms Make never shipped a module for. Outstand is free to start, and the HTTP module above is the whole integration.