Moderate spoken audio
Check a voice message, call recording or podcast episode for harassment, threats or hate speech before it goes live, and see what was flagged and roughly where. Clean audio moves on, flagged cases go to a person. Pay per use, no subscription.
Run it online
Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.
Text moderation has had years of tooling behind it; spoken content mostly hasn't, even though voice messages, live call recordings and user-uploaded audio carry the same risks as a comment section.
Why spoken content slips past filters
A platform that scans uploaded text for abuse has nothing to check when the abuse arrives as a voice clip, a call recording or the audio track of a livestream. The harmful content exists, but no moderation system sees it because there is no text to scan. That blind spot has grown as voice messages, audio-first social apps and recorded calls have become everyday ways to communicate, and no human team can keep up by listening to every submission.
How the check works and where it fits
The recording is transcribed internally, and the spoken content is then evaluated for categories such as harassment, threats, hate speech and other unsafe material. You get more than a pass or fail: the result says what was found and roughly where, with enough context to act on. Place it as a gate before publication or long-term storage, so clean audio proceeds automatically and flagged cases go to a human reviewer. It suits voice messages, community voice channels, support call archives and podcast directories alike.
Content moderation's shift from text to voice
Automated moderation began almost entirely as a text problem — filtering keywords, then later using models to judge context and intent in written comments. Voice and audio moderation is a newer extension of that same discipline, requiring a transcription step before any judgment can happen at all, which is exactly why this task combines speech-to-text with content evaluation rather than treating them as two separate jobs you'd have to wire together yourself.
Where this matters operationally
Platforms accepting user-generated audio — voice messages, community podcasts, call recordings uploaded for support — need a way to catch violations before content goes live or before a recording is retained long-term. Community and gaming apps with voice channels rely on the same underlying need: knowing when spoken content crosses a line, at a volume no human moderation team could keep up with by listening manually.
What you can do with it
Voice messaging platforms
Screen voice messages before delivery to catch harassment or threats that a text filter would never see.
Community and gaming voice channels
Check recorded voice clips or clip reports against moderation policy without a human listening to every submission.
Support call archives
Flag recorded customer calls that contain abusive or threatening language, routing them for review instead of filing them unchecked.
User-generated podcast platforms
Screen uploaded episodes for policy violations before they go live on a public directory, protecting the platform's other creators and listeners.
FAQ
Does it moderate the tone of voice or only the words?
The evaluation is based on the transcribed content and what was said, so it's built to catch violations expressed through words rather than vocal tone alone.
Is there a free way to test this?
There's no free tier — free tiers get abused and slow everyone down. No subscription, no tokens, no invented credits, and a failed task is never charged.
Can this run on live audio streams?
It processes submitted recordings asynchronously rather than a continuous live stream, so it fits best on clips, uploads or completed call recordings rather than real-time monitoring.
What languages does moderation cover?
It works across the range of spoken languages supported by the underlying transcription, so non-English audio can be screened the same way as English content.
Is flagged audio kept for evidence?
No, audio is deleted after the standard retention window and never used for training; if you need to retain flagged recordings for compliance, store them on your own side before that window closes.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/audio/moderate \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"audio":"https://ejemplo.com/audio.mp3"}'const res = await fetch("https://api.kit.forhosting.com/audio/moderate", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"audio": "https://ejemplo.com/audio.mp3"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/audio/moderate",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"audio": "https://ejemplo.com/audio.mp3"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/audio/moderate", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"audio":"https://ejemplo.com/audio.mp3"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"audio":"https://ejemplo.com/audio.mp3"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/audio/moderate", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"audio": "https://ejemplo.com/audio.mp3"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "audio.moderate",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_mb | 200 |
max_minutes | 180 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
422 | task_failed | The task failed after 3 retries. You are never charged for it. |
Technical notes
This endpoint listens to a recording and flags toxic, unsafe or policy-violating content with the context of what was actually said.
Why audio slips past text-based moderation
A platform that scans uploaded text for abuse has nothing to check when the abuse arrives as a voice clip, a call recording, or a livestream's audio track — the harmful content exists, but no moderation system ever sees it because there's no text to scan. That blind spot has grown as voice messaging, audio-first social apps and recorded calls have become normal ways to communicate, and it's the specific gap this endpoint is built to close.
What the task actually checks for
Send audio to POST /audio/moderate and the task transcribes it internally, then evaluates the spoken content for categories like harassment, threats, hate speech and other unsafe material, returning a flagged result with enough context to act on — not just a pass or fail, but what was found and roughly where. Because it runs asynchronously, the result lands at your webhook when ready, or waits at a signed link for 24 hours.
Where it sits in a trust and safety pipeline
This endpoint fits as a gate before publication or storage: audio comes in, gets checked, and either proceeds automatically or gets routed to a human reviewer for flagged cases. It complements the Speech to Text API when you also need a stored transcript for review, and works alongside the Audio Keyword Extraction API when you want both compliance flags and topic visibility from the same file.
Technical questions
What does the audio moderation API actually detect?
It transcribes the audio internally and evaluates the spoken content for categories such as harassment, threats and hate speech, returning flags with enough context to review, not just a single pass or fail signal.
How is the audio moderation API priced?
A base rate per request plus a rate per minute of audio, both published on this page, with no charge for a task that fails after its automatic retries.
How fast do I get flagged results back?
Results are delivered by signed webhook as soon as the task finishes, or you can retrieve them from a signed link valid for 24 hours, whichever suits your review workflow.