get_post_status

pro.aicut/aicut · Verify this server

Returns what the PLATFORM says happened to a post, plus `post_id` once the post is live and `fail_reason` when it is not. The statuses are `prepared` (staged, nothing sent), `scheduled` (due at `scheduled_at`; `schedule_custody` says whether aicut or the platform is holding it), `submitted` (handed to aicut's YouTube or Instagram poster, nothing confirmed), `publishing` (TikTok took the job and is fetching the file), `posted`, `failed`, and `unconfirmed`. `unconfirmed` MEANS WE DO NOT KNOW, and it is terminal. The post was sent and its outcome was never learned, so it may be live under the user's name. Tell them to check the account; do not try to publish it again, because that could double-post. WHEN: after `publish_post`, to find out whether the post actually went out. `posted` is reported only when the platform confirms the post exists - a post that is still `publishing` or `submitted` has not gone out yet, however long it has been. TIMING: TikTok downloads the video itself, usually well under a minute. YouTube and Instagram uploads run inside aicut's poster and commonly take one to five minutes. Poll every 10 seconds or so; do not spawn timers or background shells, and do not assume a failure before then. REFUSALS you act on: 403 `insufficient_scope` = THE USER'S CONNECTION CANNOT POST, and this is the common one. Publishing needs the `social:publish` permission, which a connection approved before aicut added it never carries, so a connection that generates videos perfectly well can still be refused here. It is not an outage, not a bad `video_id` or `account_id`, and not something a retry, a different account or a different video fixes. Tell the user, in these terms: aicut can post, but this connection was never given permission to; they disconnect aicut at https://www.aicut.pro/account/settings#connections, connect it again in the app they are using, and approve "Post your videos to your connected social accounts" on the aicut consent screen. Say that disconnecting stops the connection at once, so generating will not work either until they have reconnected - it is a minute of downtime, not a background task. Then STOP; nothing here works again until they have done it. A 403 here says nothing about the POST - reading a post's status takes the same publishing permission as making one, so a post that already went out stays live and simply cannot be read back until the user reconnects. This tool only READS; it posts nothing. OUTPUT: this returns JSON for you to read. When you report back to the user, give them the media URL plus a one-line summary. Do not paste the raw JSON, job ids, or internal field names into the conversation.