The token that dies quietly: wiring social auto-posting that actually stays up

We build systems that post to Facebook and Instagram on their own — an article goes live, and a few hours later the right posts appear on the client’s Page and profile, forever, without anyone touching it. The hard part isn’t the posting. It’s the one credential that stands between “works in the demo” and “works in six months.”

Why the access token is the whole game

Every social platform makes you prove, on every request, that you’re allowed to post. That proof is an access token — a long string the platform hands you after you log in and grant permissions. Get the right one and posting is trivial. Get a subtly-wrong one and you get errors that lie to you, or worse, a system that works today and goes dark next week with no warning.

Meta’s tokens are the fiddliest of the lot, because there isn’t one kind of token — there are several that look identical and behave completely differently. Almost every problem we’ve hit wiring this up comes down to having the wrong flavour of a token that otherwise looks perfect.

The trap that costs everyone an afternoon: user vs Page

Here’s the one that catches people every single time. When you generate a Meta token, the default is a user token — it represents you, the person. But to post to a business Page, you need a Page token — one that represents the Page itself.

The cruel part: a user token can list the Page, read the Page, even show it has full “manage content” permission. Every check you’d think to run passes. Then you try to actually publish a post and get rejected — “requires admin permission on the Page.” You stare at it, because you are an admin, and the token clearly has the permission listed.

The permission being present isn’t the same as holding the kind of token that can use it. A user token carries the right to manage the Page; only the Page token, derived from it, can post as the Page. When you inspect a token, the first thing to check isn’t the permission list — it’s the single word that says Type: User or Type: Page. If it says User and you’re trying to post to a Page, nothing else matters yet.

The other three that ate real time

• The ID in the URL is a decoy. The number sitting in a Page’s browser URL is not the ID the API wants. Use it and you get “object does not exist” — which sends you hunting for a permissions problem that isn’t there. The real ID comes from asking the platform “which Pages do I manage?” and reading it off the answer.
• Instagram hides its real account behind a look-alike. Connecting Instagram, there are two account IDs on offer that both look valid. One is the real business account; the other is a legacy stand-in that fails silently — your posts go into a void with no obvious error. You have to pull the specific “connected business account” field to get the right one.
• The permission has to be switched on before you can even ask for it. Half the permissions you need won’t appear in the list until the app itself is configured to request them. If you can’t find a permission, the problem is one level up, not in the token screen.

The failure that doesn’t announce itself

Now the important one — the reason this is a systems problem, not a setup problem.

A freshly-generated token is often short-lived: it works for about an hour, then expires. If you wire that straight into a live system, the demo post lands, everyone’s happy… and an hour later posting stops. Nothing errors on screen. No alert. The posts just quietly stop appearing, and you find out days later when someone asks why the feed went dead.

The fix is a deliberate step people skip because the short-lived token works when they test it: you exchange it for a long-lived one before you wire anything up. A properly long-lived Page token is effectively non-expiring while you stay an admin and the app stays active.

But “effectively non-expiring” still isn’t immortal. It dies on a password change, a security checkpoint, an admin being removed, or the app being switched off — and it dies the same silent way. So the token is never the whole answer. The whole answer is the token plus a watchdog: a daily check that the newest post isn’t stale, and an alert that emails a human the moment posting stops. We treat that watchdog as part of the build, not an add-on. A system that can fail silently isn’t finished.

The routine, boiled down

Once you know the shape, it’s about five minutes:

• Generate the token with exactly the permissions you need — no more.
• Exchange it for a long-lived one before doing anything else. This is the step that prevents the silent hour-later death.
• Derive the Page token from it, and grab the real IDs from the platform’s own “what do I manage” response — never from a URL.
• Inspect it before trusting it: Type must say Page, the permissions must be present, and the expiry must not say “one hour.”
• Put it somewhere it’s never copied again — straight into the system’s credential store, not a chat, a note, or a commit.
• Prove it with a real post you can see on the actual Page. Saved is not the same as working.

Why we write this stuff down

None of these are hard once you’ve met them. They’re expensive exactly once — the first time, when a lying error message sends you debugging the wrong thing for an hour. The value isn’t knowing the steps; it’s having paid for the gotchas already so the next build is boring.

That’s the pattern behind everything we ship: a system that runs unattended isn’t one that works when you press go — it’s one that tells you the moment it stops. If you’ve got a workflow that should be posting itself and quietly isn’t, that gap is usually a token that died without saying so. The way we build assumes it will, and watches for it.