How social media publishing actually gets automated

Almost every tool in this category shows you a month grid with posts on it, and it is genuinely useful — you can see the gaps, spot the clash, notice that nobody wrote anything for the festival week. But a grid is a record of intent. Something separate has to act on it.

That something is a small program that does one thing on a loop: look for posts whose scheduled time has arrived, and send them. It has to be a separate program rather than part of the website, because nobody is holding a browser open at ten on a Sunday morning. If the thing that publishes only runs while somebody is looking at a page, it does not publish.

Missing a post is embarrassing. Posting the same thing twice to a real audience is worse, because it is public, it looks careless, and you cannot quietly fix it.

It happens two distinct ways, and each needs its own defence.

The first is two copies of the publisher picking up the same post. That is solved by claiming rows in the database in a way that makes a claimed row invisible to everyone else, rather than merely locked — because a lock that makes the second worker wait means it publishes the same post a moment later.

The second is one publisher crashing in the gap between the platform accepting the post and the database recording that it did. No lock helps: the process holding it is gone. The defence is sending a stable identifier with each attempt, so that when the retry arrives the platform recognises it as the same request rather than a new one. Both defences are needed. Either alone leaves a real window.

When a post does not go out, the useful question is not "did it fail?" but "is trying again going to help?"

A rate limit, a timeout, or the platform having a bad minute: try again later. A caption over the character limit, or an image in a format the network refuses: trying again produces the identical refusal, so the post should fail and say what to change. A revoked token is the interesting one — it looks like a failure to communicate, but no amount of waiting fixes it, because a human has to reconnect the account.

Tools that collapse these into one "failed" state either retry forever against a credential that will never work, or give up on a post that only needed sixty seconds. Both are visible to the business as unreliability.

The word "publish" hides how much the networks differ.

A Facebook Page takes the post in one request. Instagram takes two: you create a container holding the image and caption, then publish that container — and if you want several images in one post, each becomes its own container first and a parent ties them together. LinkedIn returns the new post's identifier in a response header rather than the body, and wants an image uploaded to it in three steps before the post can reference it. A self-hosted WordPress site takes a title and body over ordinary HTTP authentication with no app registration at all.

None of that is visible to whoever writes the post, and it should not be. But it does mean "we support eleven platforms" is a claim worth asking about, because supporting a network end to end is eleven separate pieces of work, not one.

This is the honest constraint, and it is not a technical one.

Meta will not let an app post to accounts belonging to people other than its own developers until that app passes App Review and the business behind it is verified. TikTok's documentation states that content posted by an API client which has not passed their audit is restricted to private viewing. Google treats the permission to send mail on your behalf as restricted, and requires a third-party security assessment before an unverified app may ask a stranger for it.

There is one way around the wait, and it is not a trick: you register the app yourself. On your own app you are the developer, so your own accounts are reachable immediately, with no review by anybody. The cost is twenty minutes in a developer dashboard per network. A tool that walks you through that honestly is more useful than one that implies the queue does not exist.

Four questions separate a calendar from a publisher.

Which networks can it actually post to today, as opposed to plan for? The two lists are rarely the same, and the difference should be visible in the product rather than discoverable on the day.

What happens when a post fails? You want to see the attempt, the reason in words you can act on, and whether it will be tried again.

What happens when a token is revoked — which happens every time somebody changes their password? The account should say it needs reconnecting, loudly, rather than silently failing every queued post.

And what happens if the publisher restarts mid-send? If the answer is a shrug, the answer is that it sometimes posts twice.