Moderation api
Moderation api
Changelog
  • Changelog
  • Support portal

Moderation api changelog

August Updates: Voice, Unicode Spoofing, New Policies, & more

August Updates: Voice, Unicode Spoofing, New Policies, & more

Moderate voice calls, catch homoglyph evasion with the evidence attached, and send us the verdicts from your own checks.

It has been a few months since the last update. Since then we have added a new content type, three new policies, a way to send us your own verdicts, and a severity score you can actually reason about.

Voice

Trust and safety used to stop at the edge of a call. If your product has live audio — a support line, a voice channel, an AI agent talking to customers — none of it reached your moderation setup.

Today, voice is a first-class content type.

  • Conversations: a call is a conversation, and every utterance in it is grouped under one record instead of arriving as unrelated requests. The same grouping works for text, so a chat thread and a call read the same way in review.

  • Your existing policies apply: the text policies you already run on messages score the transcript. Nothing new to configure per policy.

  • Bring your own id: pass a conversationId and the call links straight back to the record in your system, along with any metadata you attach.

Real-time voice is available on custom plans — read the docs or talk to us if you want it turned on.

Unicode Spoofing

НОТ busіnеss рrоduсt reads as plain English. It is not — the Н, О, Т and і are Cyrillic look-alikes. Swapping a few characters is one of the cheapest ways to walk a banned phrase straight past a wordlist, and until now the only evidence you had was a policy that quietly failed to fire.

We're adding a Unicode spoofing policy, and putting the evidence in front of the reviewer.

What it detects

  • Mixed script: a single word built from more than one writing system.

  • Look-alikes: whole words that map to a banned word once confusables are folded away.

  • Invisible characters: zero-width joiners and other separators wedged between letters.

  • Zalgo: stacked combining marks used to break parsing and readability.

Each signal is toggled independently. If your users legitimately write in Cyrillic, Greek or Han, add those to the expected scripts list and whole-word confusables in them stop counting. You can run the policy in shadow first to see what it would catch.

The evidence, in the queue

Open a flagged item and the offending tokens are highlighted inline: which signal tripped, which scripts are mixed, what the word looks like once folded, and the exact code points involved. It renders in the single item view, in conversation context, and next to the translation. The reviewer sees why it fired instead of copy-pasting text that looks fine.

Unicode spoofing documentation →

Two More Policies

Face detection flags images by a rule you write in one sentence: flag images that contain at least — or fewer than — N faces. That covers both directions, so you can block group photos or require that a profile picture actually has a face in it. Images only, configured on a channel's Privacy page.

Low-quality content catches low-effort text: posts under a minimum word count, heavily repetitive text like buy buy buy buy now, and the same line pasted over and over. It is fully deterministic — no model call, and no usage cost.

Bring your own moderation flags

Plenty of you run your own checks before calling us — banned IP lists, an internal heuristic, a third-party vendor. There was no way to tell us the outcome, so your verdict never reached the review queue.

You can now send a client action with the content:

{
  "clientAction": {
    "action": "review",
    "behavior": "escalate",
    "source": "banned-ip",
    "reason": "Signup IP on internal blocklist"
  }
}
  • escalate (the default) applies your action only when it is stricter than ours. You can pull a clean item into review; your allow can never suppress our reject.

  • override replaces our recommendation outright.

  • Your action is available to the rules engine as client.action, client.behavior and client.source, so you can write rules on it.

The flagged field always reflects our analysis alone, so your reporting stays clean.

Client action documentation →

Custom Data In The Author Profile

Reviewers judge an account with only the context we hold. The account age, the plan, the open ticket, the impersonation link — all of it lives in your system.

Point us at an endpoint and we will render your data in the author sidebar. We call it when a reviewer opens an author, sending your project's webhook secret plus any headers you configure, and render what comes back: stats, badges, buttons into your own tools. If the call is slow or fails, the panel degrades quietly rather than blocking the review.

Custom data documentation →

Webhooks v2

New webhooks now use a versioned envelope, modelled on Stripe:

{
  "id": "evt_…",
  "type": "queue_item.resolved",
  "api_version": "…",
  "created": "…",
  "data": { "object": { … } }
}

The event id is stable and repeated in a webhook-event-id header, so retries are safe to deduplicate. A webhook-version header lets your handler branch.

v2 also adds author lifecycle events — author.blocked, author.unblocked, author.suspended, author.updated and author.trust_level_changed — fired wherever the change originates, whether that is an automated action, a reviewer, or an expiry. Every event type is documented in the OpenAPI spec.

Existing webhooks stay on v1 and are untouched. Create a new webhook to move to v2.

Webhook documentation →

Everywhere Else

  • Policies and rules are top-level pages. They no longer hide behind a channel. If you have more than one channel, a switcher appears; if you have one, you never see the channel concept at all.

  • Threshold sliders show exact counts. The histograms under channel thresholds used to be built from a sample of 100,000 items. They are now exact, on a log scale so the high-score tail you are actually setting a threshold on stays visible, with per-bucket counts on hover.

  • The item detail view got a rework. The content and metadata panes scroll independently, the activity timeline moved beside the metadata, and conversation context scrolls straight to the item under review.

  • Shadow detections are visible. Labels a shadow-flagged policy triggered now show in the queue table, are selectable in the label filter, and are counted in facets — without counting as a flag.

  • Reorder your review queues by dragging them in the sidebar.

  • Undo a resolve. Resolved items show their full detail with an undo button instead of a blurred overlay.

  • flagged_fields on webhook payloads tells you which fields of an object triggered the flag, not just that something did.

  • URL Risk catches bare domains written without http:// or www., and can always flag free link shorteners regardless of threshold.

  • Discord: choose which channels get moderated — all except the ones you select, or only the ones you select.

  • Authors have a company field, editable in the dashboard and available over the API.

Heads Up: Legacy Endpoints

The per-content-type endpoints (/moderate/text, /moderate/image and friends) are deprecated in favour of the unified POST /v1/moderate, which accepts every content type. If your project still calls them you will see a banner on your project overview and your org owner will get a weekly reminder until you have moved.

The migration is usually a one-line change. If yours is not, reply to the email and we will help.