Comment Generator API: Comment Drafting Inside Your Own Product

The Comment Generator API is a single endpoint. You POST the text of a social post plus a few parameters, and you get back one drafted comment as JSON. It runs the same engine as the three Chrome extensions, which have drafted more than 300,000 comments for people commenting on Instagram, LinkedIn, and Threads.

If you're weighing up building this yourself, here's the honest version: you can get a comment out of an LLM on your first afternoon. Nobody needs an API for that. The work sits in the distance between that first call and output you'd be comfortable letting a customer publish under their own name, in public, on a post someone else wrote. That distance is what this post is about.

What does the Comment Generator API do?

One request in, one comment out. You send the post's text as the caption field, and that's the only part you can't leave out, because the draft is built from that specific text rather than from a topic or a template. Everything else shapes the result. The objective field sets the stance you want, using the same set the extensions expose: agree, disagree, add insight, and the rest. Tone picks formal or informal. Length controls how long the comment runs. Question is a boolean for whether it should end with one. Language either names a target language or is left off, in which case the caption's own language gets detected and matched. Instructions is free text for anything standing, like a sign-off or a phrase your user always uses.

The response is one comment string. No candidate list to rank, no metadata to unpack, no preamble to strip off the front. If you want a second option, you send a second request.

Why caption-aware matters more than it sounds

"Reads the post" is easy to claim and easy to get wrong. The failure mode isn't a comment that's factually incorrect. It's a comment that's technically about the right topic and could sit under any of a thousand other posts on that topic. Someone writes about a hiring decision they regret, and the comment that comes back is about hiring in general. The author reads it and knows in about two seconds that nobody read what they actually wrote.

Drafting from the caption text means the output contains something that only exists in that one post: a number, a claim, an example, a turn of phrase. That single property is most of what separates a comment that gets a reply from one that gets scrolled past. We went through the structure behind it in how to write genuine LinkedIn comments, and it's the standard the API is tuned against.

What you'd be rebuilding

This is the part worth being specific about, because "just call an LLM" hides a real amount of work. Five things sit between a raw model call and a comment you'd ship.

An objective taxonomy that produces genuinely different output

Asking a model to disagree politely gets you something. Asking in a way that reliably produces an actual disagreement, with a reason in it, rather than a compliment with the word "however" wedged into the middle, takes iteration. The objectives are a fixed set precisely because each one had to be tuned until it produced a different comment shape, not the same comment with different adjectives bolted on.

Length discipline

Models run long by default and comments are short by nature. Getting a consistently short comment isn't a matter of putting a word count in the prompt. You ask for twenty words and get forty, or you get twenty words that read like a paragraph someone cut off mid-thought. Length control that returns a complete thought at the length you asked for is its own tuning problem, and it's the one that surprises people most.

Language handling that isn't just translation

Detecting the caption's language is the easy half. The hard half is that a comment written natively in German is not an English comment translated into German. Register shifts, idiom shifts, and how bluntly people disagree in public shifts a lot. The extensions cover English, German, French, Spanish, Portuguese, Indonesian, Hindi, Chinese, and Urdu among others, and each one needed checking rather than assuming.

The edge cases you only meet in production

Empty captions. Captions that are one emoji, or one hashtag. Posts announcing a death or a redundancy, where a cheerful "love this" is the worst output the system could possibly return. Captions in two languages at once. Posts that are themselves an ad. Baiting posts where the right move is something neutral rather than agreement. None of these show up in testing. They show up on a Tuesday, from a real user, and the engine behind the API has been meeting them on real posts for long enough to have handled most of the list already.

Evaluation

The hardest one, and the one that never finishes. There's no automatic metric for whether a comment reads like a person wrote it. Judging that means reading output against real captions, repeatedly, every time a model or a prompt changes. We did exactly that when moving all three extensions to a newer model, which is written up in the Claude Sonnet 5 release notes. Build this in-house and you own that review loop permanently, on every model upgrade, forever.

What the API does not do

It doesn't read posts for you. There's no scraping, no platform integration, no crawler. You supply the text, whether it came from a platform API, your own database, or a user pasting it into a box. And it doesn't post anything anywhere. It never touches a social account or anyone's credentials.

That second point is a design decision rather than a gap in the roadmap, and it carries over to whatever you build on top. If your product drafts a comment, the person whose name goes on it should see it before it publishes. The full argument is in why AI-drafted comments still need a human in the loop. The short version is that the platforms have gotten good at spotting unreviewed volume: LinkedIn now ships a "seems like AI slop" report button and blocks automated comments at scale, which we covered in what that button actually flags. A product that auto-publishes comments is building on a surface the platforms are actively closing.

Where the API fits

It makes sense when comment drafting is a feature inside something bigger rather than the whole product. Social media management dashboards, where drafting a reply is one action among twenty. Sales and CRM tools, where commenting on a prospect's post is a step in a sequence. Community platforms, where hosts and moderators need to keep a thread moving. Agency tooling, where several people draft on behalf of several accounts. In each case you already own the surrounding workflow and drafting is one call inside it.

It makes less sense if what you actually want is the browser-extension experience, because that already exists for Instagram, LinkedIn, and Threads. No point rebuilding it.

How do you get API access?

Access and pricing are handled case by case rather than through a self-serve signup, because volume and request shape vary a lot between the products that ask. If you need a different request shape or a dedicated endpoint, that's a conversation rather than a no. Get in touch with roughly what you're building and the volume you're expecting, and we'll take it from there.