uplika

Reviewed Jan 1, 2000.

• tools: 61 tools scanned
• metadata: scanned

No findings.

Tools (61)

• list_accounts

  Connected social accounts. **Call this before publishing anything.** Each item has id, platform (threads etc.), handle and status. The accountIds you pass to publish are these ids, and only "active" ones publish. If the person did not name a channel, target every active account. If the list is empty, no channel is connected yet. Send the person to https://uplika.com/dashboard/connections.

• select_channels

  Pick which connected channels to post to. **Call this before publish and show the result to the person.** Leave scope empty to get the candidate list and let them choose. Use scope: "all" for every active channel, or an array mixing platform names ("threads"), handles ("@vibe.trender") and account ids. Duplicates are folded, expired and not-yet-live channels are dropped into `skipped` with a reason, a sentence you can read to the person, and a link to reconnect. Pass the returned accountIds to publish unchanged. `limits` is the tightest rule across the chosen channels, so write to that. If both accountIds and candidates come back empty, nothing is connected yet. Send the person to https://uplika.com/dashboard/connections to connect a channel, then call this again. When a Naver Blog account is selected the response carries bridge with state (online, offline, logged_out, login_needed), userMessage to relay to the person, and queued; if state is not online, tell the person before publishi

• list_platforms

  Every channel and its rules: character limit, whether media is required, image and video limits, and what state the channel is in. Read this instead of guessing a platform's limits. status says who can connect: live means anyone; beta means the channel is in platform review and only accounts registered as testers on our app can connect yet, though publishing works normally for those accounts; bridge means it needs the user's browser extension running; soon means it is not connectable at all. charCount tells you how that channel counts a character, so you can check the length before calling publish instead of after it fails. options is the JSON Schema of what options.<channel> takes on publish: which fields exist, which are required, and the allowed values. Read it instead of guessing a channel's settings.

• get_help

  Uplika's troubleshooting answers: why something did not work and what the person can do about it. Call it with the error code you got (code), or with a short question in any language (query), when a call fails, when an automation did not react or a DM did not arrive, or when the person asks why something happened. Without arguments it lists every question with its id; pass id for one answer in full. Each answer has the steps, links and a url to the same answer on uplika.com that you can give the person.

• list_posts

  Recent publishes made through us and the per-target status of each, scheduled and draft posts included (their status says so and scheduledAt says when). Newest first, 20 by default. Pass limit for more or fewer, up to 100. hasMore means the list was cut short; pass the returned nextBefore as before to keep going. To answer "what is scheduled this week", pass status scheduled with since and until and sort scheduled. Posts that already existed on the channel are not here. Use list_channel_posts for those.

• list_channel_posts

  What is actually on the channel right now, including posts written in the channel's own app. Use this to find a post when you do not have its link. Each item carries a permalink you can pass straight to open_post, reply or delete_post. An empty list does not always mean the account has no posts: on TikTok this reads public videos only, so videos set to Only me, videos still waiting in the creator's TikTok inbox, and videos posted before Uplika passed TikTok's audit (2026-10-09) do not appear. If the response carries `bridge`, `bridge.nextStep` says what is needed: `run_wake` means Chrome with the extension is closed, so tell the person `bridge.userMessage` with the `bridge.wake` command for their OS and retry once after they say Chrome is open; `ask_user_login` / `ask_user_update` mean tell the person `bridge.userMessage`. Do not retry more than twice.

• publish

  Post to social channels. Channels open today: threads, instagram, youtube, facebook, bluesky, telegram, naver_blog, tiktok. Get accountIds from select_channels — do not guess which channel the person meant. Naver Blog caps how many posts one ID publishes; when it does, this returns 429 naver_rate_limited with retryAfterSeconds. Do not call again before that, the draft is already in Naver. Naver Blog asks which form to publish with, every post: if options.naver_blog.form is missing this returns 400 naver_form_required with forms (id, name, when). The form is the house style to use when the person has no style of their own, so read the conversation first. If they dictated the structure or you laid it out yourself, pass options.naver_blog.layout: "as-is" and the markdown goes out unchanged. Otherwise show them the forms (naver_layout with forms: "all" lays every one out side by side) and call again with the one they pick. Do not pick for them. Naver Blog goes out through the user's browse

• open_post

  Everything about one post in a single call: the text, the whole reply thread, and its metrics. This is the right tool when someone hands you a post link. Replies or metrics can come back null if the platform refused just that part. If the response carries `bridge`, `bridge.nextStep` says what is needed: `run_wake` means Chrome with the extension is closed, so tell the person `bridge.userMessage` with the `bridge.wake` command for their OS and retry once after they say Chrome is open; `ask_user_login` / `ask_user_update` mean tell the person `bridge.userMessage`. Do not retry more than twice.

• get_post

  One publish: per-target status and the reason any target failed. For a post link you probably want open_post instead. A target whose account was disconnected keeps its status and link, with connectionId null and accountHandle set to that account's handle; editing, deleting or retrying the post then returns 409 account_disconnected until the same account is reconnected, and the same post id comes back with it. If the response carries `bridge`, `bridge.nextStep` says what is needed: `run_wake` means Chrome with the extension is closed, so tell the person `bridge.userMessage` with the `bridge.wake` command for their OS and retry once after they say Chrome is open; `ask_user_login` / `ask_user_update` mean tell the person `bridge.userMessage`. Do not retry more than twice.

• retry_post

  Retry the targets that failed on a publish. Targets that already went out are left alone. Naver Blog caps how many posts one ID publishes; when it does, this returns 429 naver_rate_limited with retryAfterSeconds. Do not call again before that, the draft is already in Naver. Naver Blog asks which form to publish with, every post: if options.naver_blog.form is missing this returns 400 naver_form_required with forms (id, name, when). The form is the house style to use when the person has no style of their own, so read the conversation first. If they dictated the structure or you laid it out yourself, pass options.naver_blog.layout: "as-is" and the markdown goes out unchanged. Otherwise show them the forms (naver_layout with forms: "all" lays every one out side by side) and call again with the one they pick. Do not pick for them. If a Naver target stopped right after Save as draft (errorCode naver_draft_unknown), this returns 409 naver_draft_unknown and retries nothing; check list_naver_dr

• update_post

  Change a scheduled or draft post before it goes out, or edit a post that is already live on a channel that supports editing (list_platforms features: today Naver Blog, YouTube and some Facebook posts). Fields: content, mediaIds, accountIds, options, scheduledAt or draft. Fields you leave out keep their current value (on a Naver Blog post, see media below); options you pass replace the whole options object (on a post written directly on the channel they are merged per channel key instead). scheduledAt moves the send time (same rules as publish), null turns it into a draft, and draft: true does the same. A thread (chain) can be changed too while it is scheduled or a draft: content replaces the first item and keeps the later items; threadItems replaces the whole chain (one item collapses it to a single post); passing threadItems to a single post turns it into a chain. Pass id of the first item — later items return 409 thread_piece with rootId. Posts that already went out return post_not_e

• publish_now

  Send a scheduled or draft post right now instead of waiting. Returns while it is still publishing, like publish; pass wait: true to hold for the result. A draft needs at least one target account first. Posts that already went out return post_not_editable.

• delete_post

  Delete a post from the channel for good. This is not reversible, so confirm with the person first. Daily delete limits differ per channel: Threads 100 a day, Instagram only on accounts connected via Facebook, with no documented daily cap, YouTube 20 a day, Facebook 50 a day, Bluesky 35000 a day, Telegram only within 48 hours of publishing, with no documented daily cap, Naver Blog through the browser extension, with no documented daily cap, TikTok has no delete API; posts can only be removed in the app. On a scheduled or draft post nothing is on any channel yet, so this simply cancels it and removes our record. A Naver draft (target externalId starting with draft:) is only in Naver's draft box: this cancels our record and, with extension 0.7.2 or later, removes that draft too. On Threads and YouTube this also works on posts written in the channel's own app, given the link. Instagram only lets us delete on accounts connected via Facebook: an account connected with Instagram login cannot

• list_replies

  The whole reply thread under a post, nested replies included. `truncated` tells you we stopped before the end. The count here can differ from the replies metric in get_insights, which is normal. If the response carries `bridge`, `bridge.nextStep` says what is needed: `run_wake` means Chrome with the extension is closed, so tell the person `bridge.userMessage` with the `bridge.wake` command for their OS and retry once after they say Chrome is open; `ask_user_login` / `ask_user_update` mean tell the person `bridge.userMessage`. Do not retry more than twice.

• reply

  Reply to a post or to a reply. Leave replyTo empty to reply to the post itself; pass a reply id from list_replies to nest a reply under that reply. Like publish, this returns before the reply is live unless you pass wait: true, which holds the response until it is out (up to 10 seconds). Otherwise call get_post with the returned id to see the final status and link. If the response carries `bridge`, `bridge.nextStep` says what is needed: `run_wake` means Chrome with the extension is closed, so tell the person `bridge.userMessage` with the `bridge.wake` command for their OS and retry once after they say Chrome is open; `ask_user_login` / `ask_user_update` mean tell the person `bridge.userMessage`. Do not retry more than twice.

• like

  Like a post — or a comment: pass replyTo (a reply id from list_replies) to like that comment instead of the post. Idempotent: if it is already liked the call succeeds with already: true and nothing is toggled. There is no unlike. Works on Naver Blog and on Instagram accounts connected through Facebook that hold the like permission; any other Instagram account and every other channel answer not_supported. A Facebook-connected Instagram account without that permission answers feature_in_review while the permission is in Meta app review (list_platforms shows the state), and reconsent_required once it can be granted by reconnecting. On Naver Blog the post can belong to another blog: pass its link and we act as the connected account. Naver ignores liking your own post, and that comes back as naver_not_allowed rather than a fake success. On Naver Blog a secret comment, a comment hidden by Cleanbot or by the blog's blocked keywords, and every comment on a blog that turned comment likes off ha

• follow

  Follow an account on the channel. Naver Blog only today: adds the blog as a neighbor. mutual: true sends a mutual-neighbor request that the other blog has to accept, so the result is pending until they do; without it the blog is added as a plain neighbor right away. Already a neighbor comes back as already. There is no unfollow. If the response carries `bridge`, `bridge.nextStep` says what is needed: `run_wake` means Chrome with the extension is closed, so tell the person `bridge.userMessage` with the `bridge.wake` command for their OS and retry once after they say Chrome is open; `ask_user_login` / `ask_user_update` mean tell the person `bridge.userMessage`. Do not retry more than twice.

• hide_reply

  Hide a reply on the channel, or show it again with hide: false. The reply id comes from list_replies, and postId is the publish it belongs to.

• delete_reply

  Delete a comment for good. This is not hide_reply: it cannot be undone. What it reaches differs by channel and list_platforms says which ones support it at all. On Instagram and Facebook it removes anyone's comment on your post; on Threads and Bluesky a reply is itself a post, so it only removes replies the connected account wrote. Prefer hide_reply when the person just wants it out of sight.

• get_insights

  Views, likes, replies, reposts, quotes and shares for one publish. Views and shares can be null when the platform does not report them yet — null is not zero. If the response carries `bridge`, `bridge.nextStep` says what is needed: `run_wake` means Chrome with the extension is closed, so tell the person `bridge.userMessage` with the `bridge.wake` command for their OS and retry once after they say Chrome is open; `ask_user_login` / `ask_user_update` mean tell the person `bridge.userMessage`. Do not retry more than twice.

• describe_grammar

  How to write the body for a channel that has its own markup. Naver Blog has one; every other platform returns not_supported, which is not an error to work around. Call this before writing a Naver Blog body for the first time, or whenever you want something the basics do not cover: highlighting a phrase, a styled table, a collage, an event block, a map with several places. Without a topic you get an overview and the list of topics; with one you get that section in full, including the mistakes that fail silently. The values come from the same grammar the publisher validates against, so what this returns is what publish accepts.

• naver_layout

  Naver Blog only. Shows how publish will lay the body out before anything goes out. By default (layout: template) publish reshapes the markdown into the blog's house form: #/## titles become underlined quote headings, a thin rule sits between sections, photos you did not place with media: references go one per section and the rest pair up at the end. Text never changes. Call this with the same content and mediaIds you will publish, show the person the result if they care about structure, then publish (it applies the same layout) or pass options.naver_blog.layout: "as-is" to publish exactly what you wrote. To let the person choose a form, pass forms: "all" (or a list of ids): you get every preset laid out side by side with its name, when to use it and a summary (sections, photos). Show them, let the person pick, then publish with options.naver_blog.form set to the chosen id. The server never picks for you.

• bridge_status

  Naver Blog only. Posts to Naver Blog are written by the uplika browser extension inside the user's own Chrome, so nothing goes out while that Chrome is closed. Call this before publishing to Naver Blog. If online is false, the response carries wake commands per OS that open Chrome on the user's computer in the profile that has the extension (found by extension id), for the person to run. Once Chrome is open the extension reconnects within about a minute and queued posts go out; call this again or get_post to check. publish also returns the same bridge object when the extension is offline. state is one of online, offline, logged_out (Chrome is on but not logged in to Naver), login_needed (the Naver login saved for that blog in that Chrome is signed out; its posts wait until the person logs in again from the dashboard). userMessage is a sentence in the person's language to relay as it is. queued is how many posts wait for the extension; delete_post cancels them and update_post rewrites t

• list_naver_drafts

  Naver Blog only. Lists the drafts (temp-saved posts) sitting in the blog's draft box: logNo, title and the last-saved time, newest first. A post you published with options.naver_blog.draftOnly is one of them, and so is anything the person saved by hand in the Naver editor. Pass a logNo from here to publish_naver_draft. Needs the extension 0.7.2 or later in the person's Chrome; otherwise you get extension_outdated. If the response carries `bridge`, `bridge.nextStep` says what is needed: `run_wake` means Chrome with the extension is closed, so tell the person `bridge.userMessage` with the `bridge.wake` command for their OS and retry once after they say Chrome is open; `ask_user_login` / `ask_user_update` mean tell the person `bridge.userMessage`. Do not retry more than twice.

• publish_naver_draft

  Naver Blog only. Publishes a draft from the blog's draft box exactly as it is in Naver: the extension loads that draft in the editor and presses publish, so edits the person made by hand in Naver are kept. Do not send content. Category, tags and openType are taken from the draft unless you pass them. Returns the same shape as publish (202 with a target that resolves to published, or the bridge object when the extension is offline; wait: true holds until it settles). If that draft was made through uplika (a target whose externalId starts with draft:), the same post record flips to published instead of a second one appearing. To publish uplika's own copy of the text rather than what is in Naver, use update_post on that post instead. If the response carries `bridge`, `bridge.nextStep` says what is needed: `run_wake` means Chrome with the extension is closed, so tell the person `bridge.userMessage` with the `bridge.wake` command for their OS and retry once after they say Chrome is open; `a

• diagnose_naver_blog

  Naver Blog only. Reads a blog's public RSS feed (its latest posts, at most 50) and says whether the titles are written for search: the share of titles carrying a search intent word (price, how to, review), how many start with a date or episode label, posts per month, the categories, and the words the blog repeats in titles (seedCandidates: candidates to research, not proven keywords). summary.oldest and summary.newest say which dates it read, so a quiet blog's 50 posts are not everything; summary.capped is true at 50. flags and thresholds carry the judgement (lowIntent when the intent share is under thresholds.lowIntentPct). Works for any public blog, not only connected ones, and needs no Naver keys. Cached 24 hours; a cache miss spends one of 20 diagnoses per person per day (quota in the response). Returns 403 research_tool_disabled with enableUrl if the person has not turned this tool on for connectors. Tell them once and do not call it again until they say it is on.

• expand_naver_keywords

  Naver Blog only. Expands seed keywords one level through Naver autocomplete and returns every word found with the seed it came from (found[].from is seed or L1:<seed>). These are candidates to measure with research_naver_keywords, not proven keywords. The person's uplika Chrome extension looks them up in the background when it is on (no window opens); otherwise our server does, and via says which path answered each seed. Up to 10 seeds. Cached seven days. There is no daily cap: the extension path has no wait, and when our server answers, each person gets one expansion every 60 seconds (naver_autocomplete_busy says how long to wait). When the answer is naver_autocomplete_unavailable, neither path could run: pass your own keyword list to research_naver_keywords instead. naver_autocomplete_paused and naver_autocomplete_busy carry retryAfterSeconds. Returns 403 research_tool_disabled with enableUrl if the person has not turned this tool on for connectors. Tell them once and do not call it

• research_naver_keywords

  Naver Blog only. Measures keywords (monthly searches from Search Ad, blog document count and posts per month from API HUB), judges each one (best, possible, hard, wall, hot, saturated, phantom and so on, with why), and groups them into sets for one post: a main keyword plus two to five subs with the same search intent. Every set carries prompt, a ready-to-paste Korean brief for writing the skeleton of that post. Up to 60 keywords. Measurements are cached seven days across users; new ones run against a time budget, so partial: true with unmeasured[] means the budget ran out and calling again with the same keywords finishes the rest from cache. Each call is saved as a report (reportId) unless the same keyword set was saved in the last ten minutes, which returns that report's id instead. Every set also carries draftPrompt, a brief for writing the whole post (title, subheadings, body, and bracketed photo placeholders for the person to fill); pass topic to put the post's subject in it. Retu

• list_naver_keyword_reports

  Lists the person's saved keyword research (from research_naver_keywords or the dashboard), newest first: when, what they typed, the first set's main and sub keywords, and every set with its prompt. Reports belong to the person, not a workspace. Returns 403 research_tool_disabled with enableUrl if the person has not turned this tool on for connectors. Tell them once and do not call it again until they say it is on.

• get_naver_keyword_history

  The measurement history of one keyword: one point per day it was actually measured, newest first, with search volume, document count and posts per month. Shows whether a keyword is rising or cooling. An empty list means nobody has measured it here yet. Returns 403 research_tool_disabled with enableUrl if the person has not turned this tool on for connectors. Tell them once and do not call it again until they say it is on.

• search_youtube_videos

  Searches YouTube for a keyword and returns the top videos with views, subscribers, duration and publish date as YouTube gives them, plus two values uplika calculates from them that are not YouTube metrics (dataNotes says so): the views-to-subscribers ratio (above 1 means the title and topic pulled more people than the channel has) and Shorts or long-form (60 seconds or less counts as a Short). order is viewCount, date or relevance; period 7d, 1m, 3m, 6m or 1y; format all, shorts or long; max 1-50 (default 25). The same search is cached 24 hours and does not count; a new one spends one of the person's daily searches (quota in the response) and shared YouTube Data API units (youtube_quota_exhausted when today's are gone). Carries prompt, a brief in the person's Uplika language (Korean or English) that turns the table into title and hook ideas; pass topic to fill it in. Saved to the person's search history (reportId). Returns 403 research_tool_disabled with enableUrl if the person has not

• get_publish_options

  TikTok only. Do not call it for any other channel: every other channel returns not_supported, which is not an error to work around. For TikTok it returns the creator nickname the post will go out as, the privacy levels this account may use right now, whether it can post at all, and its video length limit. Call it before every TikTok publish: the values are per account and change when the person edits their TikTok settings. options.tiktok.privacyLevel is required and has no default, so this is where you get the value to pass.

• get_quota

  How much of the 24 hour allowance is already used for posts, replies and deletes. Check this before a burst of publishing. This is live usage from the platform, not the static limits in list_platforms. We also cap how fast one account can publish, so publish can return rate_limited even when the platform allowance still has room.

• refresh_account

  Re-read one connected channel's metadata. On Naver Blog this re-reads the blog's categories through the user's browser extension and waits up to a minute for it; list_accounts then shows the new list under naverBlog.categories. Call this when a category the person mentions is not in list_accounts yet. If the extension is offline you get 202 and the refresh runs when that browser comes back. Other channels return refresh_unsupported because their metadata is live on every call. If the response carries `bridge`, `bridge.nextStep` says what is needed: `run_wake` means Chrome with the extension is closed, so tell the person `bridge.userMessage` with the `bridge.wake` command for their OS and retry once after they say Chrome is open; `ask_user_login` / `ask_user_update` mean tell the person `bridge.userMessage`. Do not retry more than twice.

• media_presign

  Use this only when you can HTTP PUT the file bytes yourself (a shell or code runtime). Web and mobile chat clients cannot, so do not call it there: for a file on the person's device use media_upload_link, for a public https address use media_from_url. Returns a media id and a one-time uploadUrl. PUT the file bytes to uploadUrl with the same contentType, then call media_complete. Images: image/jpeg, image/png, image/webp, image/gif, up to 20MB. Video: video/mp4, video/quicktime, video/webm, up to 8GB, 43200 seconds, 4096px wide. Aspect ratio up to 20:1. Any image pixel width is fine. Documents for DM automations only (deliver.mediaId), not for posts: application/pdf, application/x-hwp, application/hwp+zip (.pdf, .hwp, .hwpx), up to 25MB. If you can see the image, write altText describing it. The response has mediaExpiresAt: this media id disappears after that time if it was never published, and publish will then fail with media_expired.

• media_from_url

  Attach an image or video that is already on the public web. We download it, copy it into our storage and give you a media id you can pass to publish. One step, no upload needed. https only. Google Drive and Dropbox **share** links do not work: they return an HTML preview page, not the file. Use a direct file URL that ends in the file itself. Accepted formats (read from the bytes, not the headers): image/jpeg, image/png, image/gif, image/webp, video/mp4, video/quicktime. Each channel then checks what it takes when you publish. If you can see the image, write altText describing it.

• update_media

  Mark or unmark an uploaded image or video as AI-made (aiGenerated). Applies to posts published or edited after this call; posts already out do not change (use update_post to rewrite a Naver Blog post). Every copy of the same file in your workspaces follows.

• media_upload_link

  Ask the person to upload files from their own device. Returns a short-lived link. **Give the link to the person, then wait.** Poll media_upload_status with the token until it returns ready, and only then call publish with the media ids it gives you. Do not publish before the status is ready. Use this when the file is on their computer or phone; use media_from_url when the file already has a public https address. The page also takes PDF and HWP/HWPX documents, for a DM automation's file (deliver.mediaId); a post cannot carry them.

• media_upload_status

  Has the person uploaded yet? Returns waiting, ready or expired, plus every media id uploaded through that link. Pass those ids to publish as mediaIds. Ready images also come back as image blocks so you can SEE each photo and place it in the right paragraph: previewIds[i] is the media id of the i-th image. Up to 20 images per call; pass offset to see the rest. A media with duplicateOf is the same bytes as that other id — use one of them.

• media_complete

  Step 2 of attaching an image or video. Call it after the upload finishes. We check the file really landed before marking it ready. Only a ready media id can be passed to publish.

• list_automation_templates

  Ready-made automation templates with the params each one takes. Read this before create_automation. Every template lists the channels it works on. The most used one is comment_to_dm: a comment on a post gets one private reply with a button, and tapping it delivers a link or file inside the messaging window. AI-written comment replies are comment_public_reply with replyMode "ai" (and comment_to_dm's public reply with publicReplyMode "ai"); the old template id ai_comment_reply still works and the answer says renamedFrom.

• list_automations

  Automations on the connected accounts: name, channel, whether it is live or a draft, triggers, run count, and templateParams when the flow still has its template shape. Filter by accountId, status (draft or live) or templateId. Use get_automation to read one flow's document.

• get_automation

  One automation as a document: triggers, nodes, start. Also returns version, which put_automation and update_automation need, and templateParams when the flow still has its template shape. pastComments is the latest send_to_past_comments job with its progress, or null. Pass version to read an older saved version's document instead (list_automation_versions).

• create_comment_to_dm

  The most common automation: when someone comments on a post, DM them. **Creates a draft; nothing goes out until enable_automation.** How Meta works: a DM cannot be started by the account. The only automatic door is a private reply to a comment, one per comment, within 7 days of the comment, and once the person answers the 24-hour window opens for the rest. Instagram can check whether the person follows the account (requireFollow); Facebook cannot, so requireFollow is rejected there. Threads has no DMs at all; use create_automation with comment_public_reply. A file to deliver: if it already has a public https link that returns the file itself (jpeg, png, gif, webp, mp4, mov or PDF), pass it as deliver.fileUrl and it goes to the person as-is; the link is opened once on save and a web page (a Google Drive or Dropbox share page), a private address or a dead link is rejected. If the file has no public link, upload it to Uplika first (media_upload_link without a shell, media_presign then med

• create_automation

  Create an automation from any template in list_automation_templates by passing its params. Creates a draft. For a flow no template covers, build the document yourself and call put_automation on the draft.

• put_automation

  Edit an automation by replacing its whole document: for flows no template covers, or that were already edited on the canvas. If get_automation shows templateParams, change it with update_automation instead (only the params you pass change; an Instagram follow check is requireFollow, notFollowingMessage and recheckTitle). Replacing the document of a flow that still has its template form is refused with automation_is_template, because the person can no longer open it in the form afterwards; pass detachTemplate: true only when the change cannot be expressed as template params. Read it first with get_automation and pass the version you got; a stale version is refused with version_conflict so a concurrent edit is not overwritten. Node types: send (mode window | private_reply | public_reply), condition, action, delay, random, goto, ai. Waiting is a send node with buttons and next: null; the tapped button's next continues. A loop must pass through such a wait. A comment trigger's post.postId

• enable_automation

  Turn an automation live. **This is the moment messages start going to real people.** Confirm with the person first. Only one automation per account can wait for the next post: enabling a second one is refused with next_post_taken until the first binds to a post. Only one message flow without keywords (a default reply or AI replies) can be live per account, or one message would get two answers: enabling a second is refused with automation_catch_all_taken, which names the live one. Refuses with reconsent_required if the account does not hold the DM permissions (the person reconnects it), with feature_in_review if the flow uses a feature whose permission is still in Meta app review (a mention trigger, liking a comment on Instagram) and the account does not already hold it, and warns if the account is not subscribed to webhooks.

• send_to_past_comments

  Run a live comment automation on comments that are **already on the post**: the ones it missed because they came before it was enabled, during an outage, or while another tool handled the account. An automation normally reacts only to new comments. How Meta works: a comment can get one private reply, and only within 7 days. Older comments cannot be reached, and a comment another app already answered by DM is refused by Meta (counted as alreadyReplied, not as a failure). Instagram and Facebook only; top-level comments only. mode preview sends nothing: it reads the newest comments and answers eligible (how many would get the automation now) and skipped by reason (mine, tooOld, keyword, alreadyRan, answered, sameAuthor). One person gets it once: when someone commented several times, only their newest comment is answered (sameAuthor counts the rest). **Always preview first, show the person the numbers, and start only after they confirm**, because a sent message cannot be recalled. mode sta

• disable_automation

  Stop an automation. Runs already waiting for a button stay waiting but nothing new starts.

• update_automation

  Edit an automation that still has its template shape, without rebuilding the whole document: pass only the template params you want to change (the same params as create_automation / create_comment_to_dm). Top-level fields are replaced, object fields such as deliver merge one level deep (deliver.text alone keeps deliver.links), null removes a field, arrays are replaced whole. Read it first with get_automation and pass its version; a stale version answers version_conflict. Also renames (name) and turns it on or off (enabled, with the same checks as enable_automation). Instagram follow check: requireFollow, notFollowingMessage, recheckTitle. A flow that was edited on the canvas has no template shape and answers automation_not_template: use put_automation for it. Changing a live flow changes what goes out to people right away.

• delete_automation

  Delete an automation and its run history. Cannot be undone. A live automation is refused with automation_live: disable it first, or pass force: true after the person confirms, because deleting it stops what is going out to people.

• duplicate_automation

  Copy an automation as a new draft with the same triggers and settings, optionally with a new name. Runs and versions are not copied; a copy bound to a specific post keeps that post, a copy of a next-post flow waits for the next post again when enabled.

• validate_automation

  Check a flow document against the rules for one account without saving it: node shapes, references, the 24-hour window, and features still in Meta review. Answers problems with paths; an empty list means put_automation would accept it.

• list_automation_versions

  Saved versions of one automation (every put_automation or update_automation adds one). Read one with get_automation and version.

• list_automation_runs

  Runs of one automation with their status and a step log. Status says where a run is or why it stopped: running, waiting, done, superseded, blocked_window (24-hour window closed), blocked_opt_out, blocked_paused (a person is handling that conversation), blocked_burst, blocked_ai_quota (the workspace used its daily automation AI limit; it resets at 00:00 UTC), failed_channel, failed_ai (the AI step could not classify the comment or write the reply; the reason is in the log as classify_failed or ai_failed), expired.

• list_conversations

  The inbox: DM conversations on Instagram and Facebook and mention threads on Threads. Each item says whether the 24-hour window is open and how long is left. state: open (default) or closed. kind: dm or mention.

• read_conversation

  One conversation with its recent messages and the contact: name, whether they follow the account (Instagram only), tags, opt-out. AI drafts waiting for approval show as status draft.

• send_dm

  Send a message in a conversation as the account. **Only inside the 24-hour window** after the person's last message; outside it the call is refused with window_closed and nothing can be done until they write again. On a mention thread (Threads) this posts a public reply. Pass draftId to send an AI draft that was waiting for approval. Sending pauses automations on that conversation for 30 minutes.

• get_contact

  One contact: name, username, whether they follow the account and whether it follows them (Instagram only, and only for people who have messaged), follower count, tags, opt-out, and when the messaging window closes. Follower lists do not exist on any channel; this is the closest thing.

• list_mentions

  Threads posts that mention the connected account, delivered by webhook. Same shape as list_conversations with kind mention. Reply with send_dm, which posts publicly. Mentions need a permission of their own: when no connected Threads account holds it the list is empty and the response carries notice (code feature_in_review while that permission is in Meta app review, reconsent_required once reconnecting grants it). list_platforms shows the state.

• approve_reply

  Threads only: approve (or ignore) a reply held by reply approval on one of the account's posts. Approving makes it public. Read the queue with pending: true.