Comment Moderation API: Hide, Delete, and Reply Across Every Platform

A comment moderation API is an interface that lets your code take action on the public comments left on your social posts: hide and unhide them, delete them, reply to them, and turn commenting on or off for a post entirely. The interesting part is not any single platform. Instagram and Facebook expose comment moderation through the Meta Graph API for Instagram Business and Creator accounts, and that is well documented. The hard part is doing the same thing consistently across Instagram, Facebook, YouTube, TikTok, Threads, and LinkedIn, where the available actions, the words for them, and the failure modes all differ.

This post is about the moderation capability itself. It covers the four primitives every moderation feature is built from, exactly how they diverge per platform, the policy and rate-limit constraints you inherit, and how to collapse all of it into one call. It is not the Meta API reference and it is not a list of AI moderation tools. It is the cross-platform capability and the reasoning behind it.

What is a comment moderation API and what does it let you do?

On the write side, comment handling means acting on comments programmatically, not just reading them. Reading comments tells you what people said. Moderation is what you do about it. The two are usually paired (you read a comment, classify it, then act) but they are distinct capabilities, and moderation is the one with platform policy attached. Comment moderation on Instagram and Facebook is a documented capability of the Meta Graph API for Instagram Business and Creator accounts, covering reply, delete, hide and unhide, and disabling or enabling comments on a media object, described in Meta's own comment moderation documentation.

What it lets you do, concretely, is run policy on public engagement at machine speed. A support team can auto-hide spam before a human ever sees it. A brand can auto-reply to common questions and escalate the rest. An agency managing many client accounts can apply one moderation ruleset across all of them without logging into six native dashboards. In practice, the moderation API is the mechanism and the policy you run on top of it is yours. This guide is a spoke of the broader unified social inbox API model, where comments are one of four interaction surfaces, and comment moderation is usually the first feature teams ship because comments are the most broadly supported surface across platforms.

One distinction matters before going further. A comment moderation API is not the same as a content access or onboarding question. Whether you can call Instagram's comment endpoints at all is an access concern (app review, scopes, account type). What you can do once you have access is the moderation capability. This post is strictly about the second. The access side is its own topic and is covered separately; here, assume the account is connected and authorized, and focus on the moderation actions and how they behave.

What are the four comment moderation primitives?

Every comment moderation feature, no matter how sophisticated, is built from four primitives: hide/unhide, delete, reply, and disable/enable comments. The classifier in front of them can be a regex, a blocklist, or a model, but the action it triggers is always one of these four. Understanding them precisely (especially how hide differs from delete) is the difference between a moderation system that behaves predictably and one that surprises you in production.

Hide and unhide

Hiding a comment removes it from public view without deleting it and, importantly, without notifying the author. The person who left the comment still sees it as if it were live; everyone else does not. Unhide reverses it. This is the workhorse of moderation because it is reversible and low-drama: a false positive from your classifier can be undone, and a borderline comment can be hidden pending review without escalating a conflict with the commenter. Hiding is the right default for spam and low-quality noise where you do not want to provoke a reaction.

Delete

Deleting a comment removes it permanently. There is no undo, and on most platforms you can only delete comments on content you own, not arbitrary comments anywhere. Delete is the correct action for content you are confident is abusive, illegal, or a clear policy violation, where leaving it hidden-but-recoverable is not acceptable. Because it is irreversible, a careful moderation pipeline tends to prefer hide for automated decisions and reserve delete for high-confidence rules or human-confirmed actions.

Reply

Replying posts a public response to a comment, and on threaded platforms the reply is itself a comment nested under the original. Reply is moderation in the constructive direction: answering a question, correcting misinformation publicly, or acknowledging legitimate criticism rather than hiding it. Many real moderation policies combine actions: reply to a negative-but-legitimate comment, then escalate the thread to a human; or auto-reply to a frequent question and leave the comment visible.

Disable and enable comments

The fourth primitive operates on the post, not an individual comment: turning commenting off (or back on) for a specific piece of content. This is the blunt instrument for a post that is attracting a coordinated pile-on or a sensitive announcement where you do not want an open comment section at all. It is post-scoped and reversible, but it is the most disruptive option because it silences everyone, not just the bad actors. Use it deliberately, not as a default.

How does comment moderation differ across platforms?

The honest answer to cross-platform moderation is that the four primitives are not uniformly available. Comment read and reply is the surface you can rely on the most broadly, hide/unhide is common on the Meta platforms, delete is widely available on content you own, and disable/enable comments is the least portable. In our connector work, hide and unhide is the action whose behavior diverges most between Meta and everything else. As a result, the value of a unified comment moderation API is not that it invents missing actions, it is that it normalizes the ones that exist and gives the gaps one predictable error instead of six different runtime failures. The table below is qualitative on purpose. Treat it as a design constraint, and confirm the exact, current per-platform behavior in the API reference before you scope a feature.

Read that table as a portability map, not a scorecard. Reply is the one action you can build a cross-platform feature around with confidence. Hide/unhide is dependable on Instagram and Facebook and behaves differently or is absent elsewhere, so a hide-centric workflow is effectively a Meta-plus workflow. Delete is available on content you own across most platforms but the scope of what counts as yours varies. Disable/enable is the least portable and should be treated as a per-platform capability, not a baseline.

The design takeaway follows directly from that map. Build your moderation policy on the actions a platform actually exposes, and make the not-supported case a first-class branch in your code, because on a heterogeneous platform set it will fire.

What rate-limit and policy constraints apply to moderation?

Moderation is a write workload, and write workloads are where rate limits and platform policy bite hardest. Two constraints dominate. The first is rate limiting: bulk-moderating a backlog of comments is a burst of write calls, and the Meta Graph API in particular meters calls against an app-wide ceiling shared across every account your app touches, not a generous per-user budget. A naive loop that hides a thousand spam comments as fast as it can will hit that ceiling.

The numbers and the budgeting strategy are covered in the social media API rate limits guide, so this post will not restate them. The operational point is that a moderation pipeline needs backpressure, batching, and retry-with-backoff designed in from the start, not bolted on after the first 429.

The second constraint is policy, and it is not something an API can abstract away. You can only moderate comments on content you control. Platforms gate hiding, deleting, and disabling behind ownership and the right permission scopes, and they each enforce that gate differently. A unified API surfaces the gate consistently (one not-supported or permission error rather than six), but it cannot grant you a capability the platform withholds.

The same is true for adjacent surfaces. Replying inside private threads is governed by messaging-window rules described in the direct messaging API guide. Those rules are stricter than public comment rules and are a platform policy no abstraction removes. Therefore, build your moderation logic to treat both rate limits and permission gates as expected, recoverable conditions, not exceptions.

How do you moderate comments through one API?

The point of a unified comment moderation API is that one call does the work regardless of which platform the comment came from. In SocialAPI.ai the interaction id carries a type prefix (sapi_cmt_ for comments) and an encoded platform, so reply and moderation dispatch happen server-side without a database lookup and without a switch on platform in your code. The classifier is yours, the action is one of the four primitives, and the platform routing is decoded from the id.

The example below shows the shape: classify an incoming comment, then dispatch the chosen primitive through a single function. The exact endpoint paths, parameters, and response fields live in the API reference rather than in prose here so they stay current. See the SocialAPI.ai documentation for the endpoint-level reference.

// One moderation dispatcher. Every platform. No platform switch.
// The interaction id (sapi_cmt_<encoded platform:id>) tells the API
// which platform to route to. Your code only picks the primitive.

const BASE = "https://api.social-api.ai/v1";

async function moderate(accountId, interactionId, action, opts = {}) {
  // action: "hide" | "unhide" | "delete" | "reply"
  if (action === "reply") {
    return fetch(
      `${BASE}/accounts/${accountId}/interactions/${interactionId}/reply`,
      {
        method: "POST",
        headers: authJson(),
        body: JSON.stringify({ text: opts.text }),
      },
    );
  }
  // hide / unhide / delete go through the moderate action.
  return fetch(
    `${BASE}/accounts/${accountId}/interactions/${interactionId}/moderate`,
    {
      method: "POST",
      headers: authJson(),
      body: JSON.stringify({ action }),
    },
  );
}

function authJson() {
  return {
    Authorization: `Bearer ${process.env.SOCAPI_KEY}`,
    "Content-Type": "application/json",
  };
}

// Your classifier decides; the four primitives are the whole surface.
async function runPolicy(accountId, comment) {
  const bucket = classify(comment.content.text); // your rules or model

  if (bucket === "spam") {
    return moderate(accountId, comment.id, "hide");
  }
  if (bucket === "abusive") {
    return moderate(accountId, comment.id, "delete");
  }
  if (bucket === "question") {
    return moderate(accountId, comment.id, "reply", {
      text: "Thanks for asking, our team will follow up here shortly.",
    });
  }
  // "positive" / "negative-but-legit": leave it, optionally reply.
  return null;
}

// If a platform does not support the chosen action, the API returns
// one stable not-supported error. Handle it as an expected branch,
// not an exception, because on a mixed platform set it will happen.

Notice what is not in that code: no per-platform parsing, no per-platform reply mechanics, no second code path for TikTok versus Instagram. The platform is decoded from the interaction id by the API, the moderation primitive is the same call shape everywhere it is supported, and the unsupported case is one predictable error your policy handles in a single branch. That single failure contract is the actual deliverable of unification, because it means the fallback logic is written once. If you want native parity on a single platform instead, the Instagram comment API page covers what the Instagram-specific moderation surface exposes.

How do you automate moderation with an AI agent?

Once moderation is one call, an AI agent can run the classifier. The pattern is the same as the code above with the rule-based classify() replaced by a model that reads the comment text and returns a bucket plus, for replies, a drafted response. The four primitives become the agent's tool surface: hide, unhide, delete, reply. Because the action set is small and the dispatch is uniform, the agent does not need platform-specific tools, it needs one moderate tool and good judgment about which primitive to call.

Two design rules keep an agentic moderation loop safe. First, bias the agent toward reversible actions: prefer hide over delete for anything below high confidence, because hide is undoable and delete is not. Second, keep a human in the loop for the irreversible and the ambiguous: let the agent auto-hide obvious spam and auto-reply to clear questions, but escalate abusive-or-borderline content for confirmation rather than auto-deleting.

SocialAPI.ai exposes the same moderation surface over its MCP server, so an agent calls the same primitives a script would. The broader agent integration model is covered in the unified social inbox API pillar. By contrast with the model choice, the discipline that matters is constraining the action space to four well-understood primitives with reversibility-aware defaults.

Frequently asked questions

What is a comment moderation API?

A comment moderation API is the write side of comment handling: an interface that lets your code act on the public comments on your social posts rather than only read them. It exposes four primitives, hide/unhide, delete, reply, and disable/enable comments on a post. Comment moderation on Instagram and Facebook is a documented capability of the Meta Graph API for Instagram Business and Creator accounts; a unified comment moderation API normalizes those actions across Instagram, Facebook, YouTube, TikTok, Threads, and LinkedIn so one piece of code drives all of them.

What is the difference between hiding and deleting a comment?

Hiding removes a comment from public view without deleting it and without notifying the author, who still sees it as if it were live. It is reversible with unhide. Deleting removes the comment permanently with no undo, and on most platforms you can only delete comments on content you own. A careful moderation pipeline prefers hide for automated decisions because false positives are recoverable, and reserves delete for high-confidence rules or human-confirmed actions.

Does comment moderation work the same on every platform?

No. Reply to comments is the most broadly supported action, hide/unhide is dependable on Instagram and Facebook and behaves differently or is absent elsewhere, delete is available on content you own across most platforms with the scope of what counts as yours varying, and disable/enable comments is the least portable. A unified comment moderation API does not invent missing actions; it normalizes the ones that exist and returns one stable not-supported error where a platform has no equivalent, so your fallback logic is written once.

Can I moderate comments on posts I do not own?

Generally no. Platforms gate hiding, deleting, and disabling comments behind ownership of the content and the correct permission scopes, and each platform enforces that gate differently. A unified API surfaces the gate consistently as one permission or not-supported error rather than six idiosyncratic failures, but it cannot grant a capability a platform withholds. Build moderation logic that treats permission gates as an expected, recoverable branch, not an exception.

What rate limits apply when bulk-moderating comments?

Moderation is a write workload, so clearing a backlog is a burst of write calls. The Meta Graph API in particular meters calls against an app-wide ceiling shared across every account your app touches rather than a generous per-user budget, so a naive fast loop will hit it. Design backpressure, batching, and retry-with-backoff into the moderation pipeline from the start. The budgeting detail is in the social media API rate limits guide linked in this post.

Can an AI agent run comment moderation automatically?

Yes. Once moderation is one uniform call, an agent can run the classifier and call the four primitives as its tool surface. Two safety rules matter: bias the agent toward reversible actions (prefer hide over delete below high confidence, because hide is undoable) and keep a human in the loop for irreversible or ambiguous content. Auto-hide obvious spam and auto-reply to clear questions, but escalate abusive or borderline content for confirmation rather than auto-deleting it.

Is disabling comments on a post a per-comment or per-post action?

Disable and enable comments is a per-post action, not a per-comment one: it turns commenting off or back on for a specific piece of content and silences everyone, not just the bad actors. It is the most disruptive of the four primitives and the least portable across platforms, so treat it as a deliberate per-platform capability rather than a default moderation step, and confirm exact support in the API reference before depending on it.

Comment moderation is not a single endpoint, it is four primitives plus a classifier, applied across a platform set where the primitives are not uniformly available. The work a unified comment moderation API removes is not the first hide call. It is reconciling six platforms' moderation models into one action surface and one predictable failure contract so your policy is written once. Decide your classifier and your reversibility defaults first, treat rate limits and permission gates as expected branches, and check the SocialAPI.ai documentation for the current per-platform support before you scope the feature. From here, the unified social inbox API pillar maps how comments fit alongside DMs, reviews, and mentions in the same Interaction model.

Factual references in this guide are linked so each claim can be checked at its source. Primary source: Meta: Instagram Platform comment moderation (reply, delete, hide/unhide, disable/enable comments for Instagram Business and Creator accounts)