Building Custom Moderation Dashboards: A Guide to the EchoThread Comment Moderation API

A custom comment moderation API for newsrooms lets your editorial desk triage high-volume community discussions directly inside your existing publishing tools rather than stranding staff in disconnected vendor tabs. Building your own interface turns programmatic comment moderation into a streamlined editorial queue that unifies reviews across beats, maps directly to newsroom assignments, and reduces the manual triage burden on daily news desks.

For an editor or community manager managing active commentary on breaking news, investigative packages, or opinion pieces, moderation is recurring labour. When traffic spikes, flipping back and forth between a CMS, a chat app, and a third-party moderation page slows down editorial response. This guide demonstrates how to use the EchoThread API to assemble an internal dashboard tailored to your desk's exact workflow.

Why a Comment Moderation API for Newsrooms Beats a Browser Tab

When community discussions expand across multiple reporting sections, vendor browser dashboards present structural bottlenecks. A separate browser tab means continuous context switching, lack of a unified queue across multiple properties, and zero native integration with your newsroom's existing content management system. Editors lose working hours copying URLs, hunting down context, and managing moderation queues in isolation.

This technical guide addresses a central operational question: should your organization build a dedicated internal dashboard on top of the EchoThread API, or continue moderating through standard EchoThread surfaces like the hosted dashboard, email links, and chat notifications? While solo bloggers benefit from turnkey widgets, multi-author news desks with heavy comment volume require specialized throughput.

Adopting API-first moderation workflows delivers three core operational advantages to a modern news desk:

• A consolidated multi-property queue: Ingest pending comments from your main news site, specialized verticals, and regional desks into a single workspace, avoiding separate logins and isolated tabs.
• Role-aligned editorial actions: Enforce custom newsroom hierarchies where section copy editors approve routine submissions, senior editors handle sensitive holds, and desk leads manage sitewide blocks.
• Controlled editorial automation: Route submissions based on reporter beat, assign SLA timers to fast-moving breaking news threads, and automatically sort flagged items into specialized review queues.

There is an honest engineering tradeoff to evaluate before writing code: a bespoke dashboard is software your engineering or product team must build, host, and maintain. Conversely, the default EchoThread web dashboard delivers immediate utility with zero infrastructure overhead. For teams reviewing hundreds or thousands of comments daily, building an internal interface on the EchoThread comment moderation API for newsrooms provides the throughput necessary to keep discussions healthy. For additional operational strategy on organizing review lanes, consult our practical guide to comment moderation workflows for newsrooms.

What the EchoThread API Actually Exposes (and What It Does Not)

Before designing your dashboard client, you must understand the exact scope of the EchoThread architecture. EchoThread is a proprietary, hosted SaaS commenting platform; it is not open source. Only its integrations are: the EchoThread MCP server (@echothread/mcp) and n8n node (@echothread/n8n-nodes-echothread) are MIT-licensed on GitHub. Furthermore, EchoThread is a fully hosted SaaS; it does not offer a self-hosted or on-premise deployment. Your custom dashboard operates strictly as an API client, leaving data persistence, threat scanning, and delivery pipelines to the EchoThread hosted infrastructure.

Authentication relies on an EchoThread API token generated per site. On the EchoThread platform, webhooks configured with API tokens are available on EchoThread Starter and above (as well as during the initial 14-day Starter feature trial). Client applications leverage this surface to read site hierarchies, thread states, and individual comments. For write operations—such as approving holds, rejecting submissions, marking spam, posting editorial replies, and deleting entries—the API requires an active token on EchoThread Starter or higher, as detailed in the EchoThread API documentation.

It is equally important to plan around architectural boundaries. The EchoThread MCP server cannot post new comments, and EchoThread offers no hosted MCP endpoint; developers connecting an AI assistant must run the MIT-licensed client locally via stdio, as outlined in the Model Context Protocol specification. Additionally, the EchoThread MCP server remains dedicated to administrative reading and moderation actions. To inspect endpoint specifications and payload schemas directly, refer to the official EchoThread API documentation and webhook guides rather than making assumptions in client code.

Designing the Queue: What Your Dashboard Must Show Before It Shows Anything Else

An effective moderation dashboard begins with choosing the appropriate unit of work. For solo sites, comment-by-comment review often suffices. For news operations, thread-level triage with an expandable comment drill-down is typically superior. Grouping items by the parent reporting piece allows editors to evaluate discussions within the full editorial context of the article rather than parsing detached snippets.

A minimum viable queue row should expose exactly five primary data points to keep triage moving quickly:

1. Comment body: The complete submitted text, preserving paragraph breaks without extraneous HTML formatting.
2. Author display name: The reader's visible screen name alongside their authentication provider badge.
3. Target URL and section metadata: The target page URL, allowing the reviewer to identify the beat or reporter instantly.
4. Precise timestamp: Submission time displayed in relative format for recent entries and absolute UTC for older holds.
5. Routing rationale: The specific condition that held the comment in the queue.

Surfacing the explicit routing rationale is vital for triage speed. In EchoThread, the moderation queue labels a decision as the owner's own rule and shows the text that matched. Your custom interface can clearly separate an owner-authored restricted-words match from an item flagged as borderline by automated filters, giving the editor immediate clarity on why the comment stopped in the queue.

Default views must withstand fast-paced news cycles. Configure the interface to sort held comments oldest-first so editorial response times remain consistent, while sorting published reader comments newest-first. Adding saved filter presets by section—such as Politics, Metro, or Investigative—allows beat editors to claim specific queues. Avoid the common pitfall of building a view that displays every published comment by default; an interface that fails to filter out the high volume of approved submissions will slow down your desk more than the standard administrative views. For established throughput strategies, examine our breakdown on how to triage high-volume comment queues.

Programmatic Comment Moderation: Wiring Webhooks So the Queue Fills Itself

Polling an API repeatedly creates unnecessary server overhead and introduces latency during breaking news coverage. Instead, programmatic comment moderation relies on an event-driven model: when a reader submits a comment, EchoThread dispatches an HTTP POST webhook to your dashboard ingestion endpoint. Your application parses the event payload and pushes the entry to active editorial screens in near-real time using techniques like MDN Web Docs: Server-sent events.

Webhooks with API tokens are supported on EchoThread Starter and above, as detailed in the EchoThread webhook documentation. If your organization relies on chat alerts, keep payload limitations in mind. On EchoThread Starter and above (and during the Starter trial), a site owner can send new comments to Slack or Discord by pasting an incoming-webhook URL, with separate toggles for comments awaiting review and published comments; comments that ask a question are marked. EchoThread Starter and above allow up to 5 alert destinations per site. On EchoThread Starter and above, alerts carry the commenter's display name, the page and the first 300 characters of the comment, never an email or IP address. On EchoThread Starter and above, alerts are notifications only: moderating happens in the EchoThread dashboard, by email, or through the API. EchoThread does not support Telegram yet. Consequently, your engineering team must not attempt to design inline approval buttons inside chat payloads, as alerts are strictly informational.

For newsrooms coordinating low-code pipelines, EchoThread publishes an MIT-licensed n8n community node, @echothread/n8n-nodes-echothread, which implements standard triggers and actions described in the n8n community node documentation. The EchoThread n8n node features a New Comment trigger along with Approve, Reject, Mark Spam, Reply, and Get actions. The EchoThread n8n node uses an EchoThread API token and needs EchoThread Starter or above, as listed on the EchoThread pricing page. EchoThread has no Zapier or Make app. If you need step-by-step guidance on connecting real-time notifications to team channels, read our walkthrough on how to set up comment webhooks for Slack.

Roles, Permissions and Who Can Act on What

Before deploying client code to your staff, map internal desk responsibilities to API capabilities. An unsegmented dashboard where any user can purge threads or execute sitewide restrictions creates editorial liability during high-stress publishing moments.

Consider the following operational role breakdown:

• Desk Copy Editors: Granted permissions to view review queues, approve routine holds, and reject submissions violating editorial standards.
• Senior Section Editors: Empowered to mark aggressive submissions as spam, execute author bans within their specific site, and issue formal staff replies.
• Editorial Directors & Administrators: Retain full rights to adjust sitewide automation settings, update word lists, and revoke API credentials.

When implementing user moderation, note that EchoThread seat holders cannot be banned. This safeguard ensures that team members, guest columnists, or verified staff accounts cannot have their commenting privileges revoked by peer moderators using custom dashboard interfaces.

EchoThread owners and moderators can ban or trust a commenter on a per-site basis. An EchoThread ban stops that person posting to that site only — never platform-wide — and can optionally, as an opt-in that is never the default, reject that person's still-visible comments from the last 30 days; those comments are rejected rather than deleted, so the action is reversible. EchoThread's trust setting auto-approves that person's comments on that site, bypassing pre-moderation and a restricted-word hold, but never a restricted-word reject. EchoThread seat holders cannot be banned. EchoThread's per-site ban and trust are free on every plan, including the free Hobby plan, as detailed on the EchoThread pricing page. EchoThread's per-site ban is a different feature from EchoThread's per-reader block, which hides someone from one reader and tells nobody. Your custom dashboard must clearly separate these actions in the UI: use an instantaneous single-click pattern for approvals, but implement an explicit confirmation dialog for bans and thread closures. For deeper structural planning, review our guide to comment moderation roles for multi-author news sites.

Automating the Boring 80%: Rules, Spam Scoring and Thread Closing

A performant moderation pipeline handles obvious bad actors automatically, reserving human editorial judgment for complex, nuanced discussions. EchoThread provides spam and moderation tooling in two layers: AI-assisted spam scoring through its Siftfy integration, and deterministic rules the site owner writes themselves — a restricted-words list, per-site commenter bans and trust, and auto-closing old threads. EchoThread is not a built-in first-party AI moderation engine, and EchoThread's owner-authored controls are rules, not AI. Understanding this distinction prevents engineers from spending time attempting to fine-tune non-existent proprietary models.

Deterministic checks often take precedence in execution order. EchoThread lets a site owner keep a restricted-words list of up to 2,000 entries, matched case-insensitively against the comment body and the author's display name, where "*" matches a run of non-space characters. The owner chooses once for the whole EchoThread restricted-words list whether a match holds the comment for review or rejects it; a display-name match always holds rather than rejects. EchoThread runs restricted-words matching before the spam classifier, so a comment the rule decides never reaches it, and the EchoThread moderation queue labels the decision as the owner's own rule and shows the text that matched. Only owners can edit the EchoThread restricted-words list, it is included in the EchoThread site export, and it is free on every plan including the free Hobby plan, as shown in the EchoThread comment moderation guide.

Following deterministic checks, content passes through external classification. EchoThread does not use Akismet, and there is no Akismet key to set up. EchoThread scores spam with Siftfy, an AI spam classifier that EchoThread integrates, on every plan with no configuration. Comments EchoThread scores as high-confidence spam are filtered, and borderline comments go to the owner's Echo