Publishing Threads reply chains through the API: how we built it and what went live

On Threads, the posts that travel often come as a chain: a first post with the hook, then the author’s own reply with the rest. In October 2026 our founder called chains a very important tool for his personal-brand series and asked for them in Mellow Hub, our publishing product. Our provider could not publish them, so we built it ourselves. This is how, and what happened on the first live runs.

The situation and the goal

On 12 October 2026 we read five popular AI posts on threads.com to see what a chain does. Four of them, with 43,000 to 118,000 views, were two-post chains: a complete first post with the hook or the result, then the author’s own reply holding what did not fit, the link, the prompt, the second half of a list or the follow ask. That reply collected its own likes and shares, 48 to 56 likes and 18 to 20 shares. The one four-post chain, three steps and a punchline from a smaller account, was the weakest at 9,300 views. Five-to-seven-post chains had no evidence behind them in what we read. Claims elsewhere that a first reply within 90 seconds doubles thread depth come from vendor blogs, and we treat them as hypotheses.

Mellow Hub publishes most networks through a provider, Post for Me. Its Threads settings, read on 12 October, were caption, media and placement, with no reply field; its pull request for chains on X, Threads and Bluesky was closed on 5 August 2026 with the note that the feature would come as part of comments, with no date. Ayrshare, Outstand, Repping and Eden offered reply chains through Meta’s Threads API at the time. The goal: a person or an AI agent writes a post and the posts that follow it, picks a time, and the whole chain goes out on its own.

What we built, step by step

1. A Threads sign-in of our own. Chains go through our own Meta app with the Threads use case and four permissions: threads_basic, threads_content_publish, threads_manage_replies and threads_read_replies. A person signs in once, in Accounts, beside the provider’s connection, never instead of it. The token lasts 60 days and is refreshed automatically.
2. One field for the chain. The post’s caption and media are the first post; options.threads.thread holds what follows: up to 24 posts, each up to 500 characters, with at most one picture or video each. The first post can be a carousel of up to 20 files. Threads counts an emoji by its size in UTF-8, and so does our character counter.
3. Publishing in order. A part with words alone is one request that creates and publishes it. A part with a picture or video is a container, polled until it is FINISHED, then published. Every part after the first carries reply_to_id, the id the part before it was published as. Progress is saved after every part.
4. Each part asked for once. Threads has no idempotency key. Before a publishing request the job marks it as being sent. A plain refusal clears the mark; a request that got no answer leaves it, and the next run looks for that part among the profile’s latest posts, by its text. If it is there, it counts as out; if not, the chain stops and asks a person to look.
5. Failure stops the rest. The post says which part failed and how many are already on Threads, and “Send again” continues from that part: the first post never goes out twice. Meta’s retryable errors (codes 1, 2, 4, 17, 32 and 613, or HTTP 5xx and 429) are retried with back-off up to six times.
6. Files that outlive the wait. The provider’s upload storage drops a file within about a day when no provider post uses it, and a chain is not a provider post. A chain that waits more than six hours has its files copied to our own storage while it waits.
7. No edits once it starts. A chain with a part out cannot be edited, moved or cancelled; before that it can.

Results

• Deployed by 23 October 2026, with 47 tests against a fake Threads API.
• First live chain, 23 October, 11:01:30 UTC on @wlad_kowalski, in Russian: 4 parts, 4 published, no error. On threads.com the three continuations sit under the first post as one native thread numbered 1/4 to 4/4, with the picture on the first post. The continuations carry no picture, by design.
• Second live chain, the same day at 17:01:30 UTC, in English, on our founder’s English profile: 4 of 4, the same native thread, 9 views on the first post when we read it.
• The open question answered. Before launch nobody on the team knew whether replies posted through the API would render as a native thread or as loose replies. They render as a thread.
• Eleven more chains per profile were scheduled after these. The proofs in this article are the two four-part chains of 23 October.
• The chains that followed. On 8 November 2026 we opened six of the later Russian chains on threads.com, from 24 October to 3 November, five-part ones among them: in each, every continuation sits under the first post, marked Author.

What did not work, and what we changed

• The provider route. No field, no date: building our own route was the only way. It mirrors how Hub already publishes Instagram through our own Meta app and Telegram through our own bot.
• A file almost lost. The English chain, scheduled on 22 October for 17:00 UTC the next day, had its first picture on the provider’s storage, which keeps an unused file for about a day. We caught it before it ran; that is where step 6 came from.
• One sign-in per account, by a person. Threads’ consent signs whichever Threads account the browser has open. Our AI agent could not switch accounts without a password, so each profile was signed in by a person signed in as that account. The app secret, too, was set by our founder.
• Not for every customer yet. As of 27 October 2026, Meta’s App Review for the Threads permissions had not been filed, so chains work only on Threads profiles added as testers to our Meta app. Opening them to everyone needs Meta’s access verification, the Threads use case on the app in our verified business portfolio, and the review.
• Not built: chains on X and Bluesky, reading and answering the replies under a chain, separate statistics for each part (the figures are the first post’s), and attaching a file to a continuation in the cabinet’s composer (the API can).

How to do it yourself

1. Create a Meta app with the Threads use case and request threads_basic, threads_content_publish and threads_manage_replies; Meta’s page on creating replies lists all three.
2. Publish the first post and keep its id.
3. For each next part, create a container with reply_to_id set to the previous part’s id, wait for it to be ready if it has media, and publish it.
4. Save progress after every part, and never resend a part blindly: look for it on the profile first.
5. Write two or three parts that each stand alone, under 500 characters, with the hook and the payoff in the first.
6. Mind Meta’s limits: 250 posts and 1,000 replies per profile in 24 hours, so a five-part chain uses one post and four replies.
7. Or use Mellow Hub: switch on Chain in the Threads card of the composer, or send options.threads.thread from an agent, once the Threads account is enabled for chains.

Numbers at a glance