Social agents need a reconnect state
A social scheduler should tell the agent when a channel needs OAuth attention before the agent writes another post nobody can publish.
The most useful error in a social automation stack is the one that stops the draft before it exists.
I mean the boring OAuth one. The channel needs reconnecting. The access token expired. The provider revoked a scope. The account is still listed in the scheduler, but the next publish attempt is going to fail unless a human re-authorizes it.
Postiz documents this failure plainly: failed posts often come from channels that need reconnecting, platform-rule violations, or provider rejections. Its public API also treats a connected account as an integration with an ID, display name, provider identifier, disabled flag, and profile handle. That is enough shape for a better agent rule: do not write the post first and discover the channel is sick later.
Sources: Postiz troubleshooting overview, Postiz public API list integrations, Postiz trigger integration tool endpoint, Postiz MCP tools reference.
The reconnect state belongs at the top
Most publishing agents treat provider health as a final check. Draft the post, trim it for the platform, schedule it, then inspect the result.
That order wastes time.
If a channel needs reconnecting, the agent does not need a better caption. It needs to stop. The correct output is a small report that says which integration is blocked, what provider owns it, and what human action is required. Anything else is theatre with a postId at the end.
This is where a visible reconnect state changes the workflow. It moves OAuth health from an afterthought to an input.
A social job should begin with something like this:
integration_id: <exact channel> provider: linkedin / threads / x / ... disabled: true / false refresh_needed: true / false, if the scheduler exposes it last_successful_publish: <timestamp or unknown> last_error: <provider message, redacted> allowed_action: draft / schedule / stop-and-report
That is not a dashboard nicety. It is the difference between automation and wishful thinking.
Disabled is not the only danger
The public integrations endpoint returns a disabled boolean. Good. Use it.
But a channel can look present and still be unusable. OAuth tokens expire. Provider apps lose scopes. A Meta, LinkedIn, or X account can reject a fetch even when the local row still has an ID and a profile picture. Postiz's troubleshooting page names reconnecting as the first common cause for failed publishes, which matches the failure shape I care about: the scheduler knows the channel exists, but the provider will not accept the work.
For an agent, that means "integration exists" is the wrong acceptance test.
The better test is narrower:
- Is this the exact account I intended to use?
- Is it disabled?
- Does the scheduler or local state say it needs reconnecting?
- Does the platform schema still allow the post shape I am about to create?
- Has this integration published successfully recently?
If those checks fail, the agent should not improvise. It should report the blocker and leave the content queue untouched.
The product choice is friction
There is a small UX decision hiding here. A scheduler can make reconnect problems quiet or loud.
Quiet reconnect problems feel polite until agents enter the system. Humans can notice the red marker in the sidebar. Agents do not have eyeballs on the sidebar unless we make that state available in the workflow. They need a machine-readable stop sign.
I would rather have a job skip one good post than create five queued rows for a dead channel. The first failure is honest. The second creates cleanup work and false confidence.
This is also why exact integration IDs matter. "Post to LinkedIn" is a request. linkedin / Diaa Asha / <integration id> is an operating target. Once the target is explicit, the health check can be explicit too.
The report should be useful without opening Postiz
When a reconnect gate blocks a post, the report should not say "publishing failed" and disappear.
It should say:
Skipped: LinkedIn personal Reason: channel needs reconnecting Action: re-authorize the channel in Postiz Draft created: no Queued rows created: no Retry condition: integration health returns OK
That kind of report is boring in the best way. It tells the human exactly what changed, and it prevents the agent from turning one OAuth problem into a content-quality problem.
The pattern generalizes beyond Postiz. Any agent that writes to an external system needs a reconnect state before the creative work begins. If the pipe is broken, do not polish the water.