If you want to automate instagram and tiktok replies API work, the fastest path is to treat comments like any other event stream. A small backend service polls or receives webhooks, decides on a reply, posts it back through one endpoint, and writes a row to your database. No dashboard clicking, no browser sessions, just HTTP.
This post walks through that service step by step using the Creator OS REST API. You will see the exact request shapes, the fields that matter, and the failure modes you need to handle. Everything below comes from what Creator OS actually supports, so if a network does not allow something, this post says so instead of pretending it does.
Instagram comments ──┐
├──> your worker ──> reply endpoint
TikTok comments ─────┘ │
└──> your database (log row)Why Automate Replies From Your Backend Instead of a Dashboard
A social media scheduling dashboard is built for a human sitting in front of it. That is fine for publishing. It is awkward for a reply workflow that needs to run every few minutes, apply your own rules, and hand the result to another system.
Creator OS ships a hosted MCP server and a CLI so an AI agent can run your accounts, and it also gives you a plain REST API with an API key. That third surface is the one this post is about. If you would rather let an agent handle the same work in natural language, start with the AI comment reply workflow instead and come back here when you want code.
Backend automation gives you three things a UI cannot: your own routing logic, your own storage, and your own retry policy. You decide which comments get a public reply, which get a DM, and which get nothing.
What You Need Before You Start
- A Creator OS account with Instagram and TikTok connected. Instagram needs a Business or Creator account.
- A Creator OS API key. Keys look like
cos_live_...and are pinned to one workspace, which is one set of socials. An agent holding one workspace’s key cannot post to another workspace. - The base URL for API calls. It is listed in the docs at https://www.creatoros.ca/docs. Read it there rather than guessing a hostname.
- Instagram connected with a Facebook login if you want the paid partnership label later. Not required for replies.
One limit to know up front: Creator OS supports replies to comments on Instagram, Facebook, X, Threads, YouTube and LinkedIn. Replying to TikTok comments is not supported. On TikTok you can hide and delete comments for Business accounts, and there are no DMs on TikTok. So your worker should treat TikTok as a read and moderate source, not a reply target. Plan for that before you write the routing table.
The Creator OS REST API in One Minute
Requests are authenticated with your API key. Errors all come back in the same shape:
{ "error": { "code": "...", "message": "...", "status": 400 } }Ids are opaque typed tokens, so you can tell at a glance what you are holding: acc_ for accounts, post_ for posts, cmt_ for comments, conv_ for conversations, msg_ for messages, auto_ for automations, med_ for media. Store them as strings. Never parse them.
Webhooks exist too, with events like post.published and comment.received, signed with an X-CreatorOS-Signature header. Webhooks are the low latency option. Polling is the simpler one, and it is what the walkthrough below uses.
Step 1: Fetch Instagram and TikTok Comments on a Schedule
First, discover what you are working with. List your connected accounts so you know which acc_ ids belong to Instagram and which belong to TikTok. You can do that with the CLI while you are building:
creatoros auth:check
creatoros accounts:listThen pull comments for a given post. The pattern is the same on every platform: you need the post id and the account id.
creatoros inbox:comments --platform instagram --since 2026-01-01T00:00:00Z --limit 50
creatoros inbox:comments --platform tiktok --limit 50The REST equivalent is a GET against the comments collection for one of your published posts, using the post_ id you stored when the post went out. Because ids are workspace scoped, the same call from a different API key simply returns that other workspace’s data. There is no way to cross the boundary by accident.
Run this on a schedule. A cron every five minutes is plenty for most accounts. If you want near real time and want to skip polling, subscribe a webhook to comment.received and let Creator OS push the event to you.
Step 2: Route Comments Through an Auto-Responder
Now you have a list of comments. Each one has an id, an author, and text. This is where your own logic lives, and this is the part no hosted dashboard can do for you.
A simple router looks like this:
- Skip anything you have already seen. Key your dedupe table on the comment id.
- Skip anything from your own account.
- Match the text against rules, in priority order.
- Pick an action: public reply, private reply as a DM, hide, or ignore.
Two of those actions are worth spelling out. A public reply shows up under the comment for everyone. A private reply, also called a comment-to-DM funnel, starts a DM thread with the commenter. Creator OS supports comment-to-DM keyword funnels on Instagram and Facebook only, so keep that action scoped to those two networks in your router.
You can build the same rule in Creator OS as a first class object rather than your own code. An automation takes a name, an account, a post or platform post, a set of keywords, a match mode of exact, contains or word, a DM message, and an optional comment reply:
creatoros automations:create \
--accountId acc_123 \
--postId post_456 \
--keywords "link,send it,guide" \
--matchMode contains \
--dmMessage "Here is the link you asked for." \
--commentReply "Sent you a DM!"Use the automation when the rule is simple and you want Creator OS to run it. Use your own router when the decision needs data Creator OS does not have, like order history or a CRM record.
Step 3: Post Replies Back With One Endpoint
This is the part that makes the whole design worth it. One reply endpoint covers every network that supports replies.
creatoros inbox:reply post_456 --accountId acc_123 \
--message "Thanks for reading, glad it helped."Add --commentId cmt_789 to thread the reply under a specific comment rather than at the top level of the post. For a comment-to-DM funnel you would use the private reply action instead:
creatoros inbox:private-reply post_456 cmt_789 \
--accountId acc_123 --message "Sending the guide now."Over REST, the same operation is a POST to the reply endpoint for the post, with the account id, the comment id and the message body. The response gives you back the comment id of your own reply, which you want to save.
Instagram is the network where replies matter most, and it is also the one with the most surface area. If you also want to handle the wider publishing side, the single social media API overview covers how posts, stories and carousels map onto the same shape.
Step 4: Log Every Reply for Analytics
Do not just fire and forget. Write a row for every reply you post, with the source comment id, the reply id, the platform, the account, the rule that matched, and a timestamp. That table becomes the thing you actually learn from.
You can enrich those rows with Creator OS data. Per post analytics, daily account metrics, follower stats and best time to post are all available across connected platforms:
creatoros analytics:posts --platform instagram --sortBy engagement --limit 20
creatoros analytics:daily --platform tiktok --from 2026-01-01 --to 2026-01-31
creatoros accounts:follower-stats --granularity dailyIf your replies include links, use Creator OS short links. They live on go.creatoros.ca and report click stats, so you can see which replies actually drove traffic instead of guessing from likes. That closes the loop: comment in, reply out, click measured.
Handling Rate Limits, Duplicates, and Failed Replies
Three things break first in a system like this.
Duplicates. Polling means you will see the same comment twice. Dedupe on the comment id before you do anything else. If you also run webhooks, dedupe there too, because the two paths can overlap. An idempotency check costs one indexed lookup and saves you an embarrassing double reply.
Failures. A reply can fail if the comment was deleted between your fetch and your post, or if the post itself is gone. Because every error uses the same { error: { code, message, status } } shape, you can branch on the code rather than parsing prose. Log the failure with the comment id so you can retry it deliberately instead of in a loop.
Platform rules that differ. Your router should know which actions each network allows. Replies work on Instagram, Facebook, X, Threads, YouTube and LinkedIn. DMs work on Instagram, Facebook and X, and all DMs land in one inbox. TikTok gets no replies and no DMs, only comment moderation on Business accounts. Threads replies to replies are supported. Hide and delete are supported on the networks listed above and on TikTok for Business accounts.
A practical retry policy: retry network errors twice with backoff, do not retry validation errors, and alert yourself if more than a small number of replies fail in an hour. That is enough to catch a rotated token or a removed post without paging you at 3am.
If you would rather watch the whole loop being built than read it, the walkthroughs on the KevBuildsApps YouTube channel cover exactly this kind of worker against the Creator OS API, and the launch video shows the surrounding tooling.
One more option worth knowing if you are already using an AI coding tool: the same comment handling is available as agent skills. Running npx @creatoros/cli@latest init installs 14 Claude Code skills, including respond-to-comments and respond-to-dms, and creatoros sync updates them later without overwriting files you have edited. Details are at https://www.creatoros.ca/docs/cli. There is also an open source route: Social Agents is an agent harness that runs your socials on Creator OS and starts with npm start creatoros social-agents.
Get Started With Creator OS
To run this yourself, connect Instagram and TikTok, generate an API key, and read the base URL from the Creator OS docs. The MCP setup reference lives at https://www.creatoros.ca/docs/mcp, and posting options per network are at https://www.creatoros.ca/docs/post-options.
The Creator plan is $19.99/month or $59.99/year and covers up to 8 connected accounts, which is 7 socials plus Skool. API keys, the MCP server, the CLI and the agent skills are included in every plan, so a backend worker costs nothing extra. Agency plans are $49/month or $399/year for 5 sets of socials, up to 40 connected accounts, and $99/month or $599/year for 10 sets, up to 80 accounts.
Sign up here, connect your accounts, and point your worker at the comments endpoint. Start with one rule, one keyword, and a log table. Expand from there once you can see what people are actually asking for.