posteyai Postey Ops
The thing this skill exists for
Publishing is asynchronous, and every status short of PUBLISHED means it has not gone out.
DRAFT → SCHEDULED → PUBLISHING → PUBLISHED
A successful schedule_post call means the job was accepted. It says nothing about whether the
platform took the post. A post can sit in PUBLISHING, or reach PUBLISHED on one platform and
fail on another in the same post, because each platform publishes independently.
Never tell the user something published because the call that scheduled it returned success.
Read postey://posts/{post_id}/publish-status and say what it actually says.
Checking a post
postey://posts/{post_id}/publish-status— per platform, not per post.- If a platform is missing from
published_platformswhile listed insocials, that platform did not go out. That is the single most useful signal in the system and the easiest to miss: the post looks published because one platform succeeded. postey://notifications— this skill's half is notifications about posts: publish failures, token expiry, quota. Notifications about people (comments, mentions) belong topostey-engagement.
Common causes, in the order worth checking
| Symptom | Check first |
|---|---|
| one platform missing, others fine | that account's connection — postey://accounts reports needs_attention per platform |
everything stuck in SCHEDULED past its time |
the scheduler worker, not Postey's API |
PUBLISHING for a long time |
a platform accepted the upload and has not confirmed; video is slower |
published but no live_link |
it went out; the link fetch lagged. Not a failure |
| nothing scheduled that the user expected | the schedule was never created, or was created on a different account |
needs_attention on an account is the most common root cause and the cheapest to check. A platform
in RECONNECTION_REQUIRED will fail every publish silently until someone reconnects it, and the
draft looks perfectly healthy.
Reporting
Say per platform, with the status, not "it published". The user cares which ones landed:
post 10168
LINKEDIN PUBLISHED 2026-07-26 17:30 live_link present
X not in published_platforms — the account shows twitter RECONNECTION_REQUIRED
THREADS listed in socials, no publish record
If something failed, say what to do: reconnect the platform, restore the post if it was deleted, or recreate and re-schedule. Do not retry a publish on the user's behalf without asking — a duplicate post is worse than a late one, and the failure may have partially succeeded.
Recovering a deleted post
Read postey://accounts/{account_id}/trash before recreating anything. A post the user deleted by
mistake is still there, and restoring it keeps its id, its per-platform copy and its comment
history — recreating loses all three.
restore_post takes one id; restore_posts takes several. Both return the post to DRAFT, never to
its previous SCHEDULED or PUBLISHED state, so a restored post still needs the user's explicit yes
before it goes anywhere. Say what you found in the trash and let the user pick; do not restore a
batch on the assumption every deletion was accidental.
Cadence
get_schedule and postey://accounts give the queue. When asked to plan cadence, the constraint
is what the account can sustain, not what the platform allows. An empty queue next week is a more
useful thing to report than an optimal posting time.
Scheduling itself is the hub's (schedule.create), and scheduling counts as publishing: it
needs the user's explicit approval, because a scheduled post publishes itself.