The detection API, as designed and not yet shipping

Authentication, as intended

A bearer token created in an account, scoped to an environment and rotatable without downtime. Keys are not being issued, so the value below is illustrative.

Authorization: Bearer tr_live_[VERIFY: key format at launch]

Submitting a clip

curl https://api.aivoicedetctor.com/v1/detect \ -H "Authorization: Bearer $TRUTHRING_KEY" \ -F "audio=@call-recording.m4a" \ -F "channel=phone"

channel is optional and worth sending every time. Declaring that the audio came from a phone call, a messaging voice note or a studio file changes which measured error rate is reported alongside the verdict, and a verdict reported against the wrong error rate is a verdict presented as stronger than it is. Accepted values: studio, voicenote, phone, video, unknown.

Intended formats: mp3, m4a, wav, ogg, flac. Size ceiling, duration ceiling and rate limit are all undecided: [VERIFY: API size, duration and rate limits at launch]

The response contract

{ "verdict": "synthetic", "confidence": 0.962, "generator": "ElevenLabs", "generator_confidence": 0.81, "channel_detected": "phone", "false_positive_rate": "[VERIFY: measured rate for this channel]", "duration_seconds": 14.2, "model_version": "tr-[VERIFY: version at launch]", "reference": "TR-8F29A1", "reason": "Recording chain inconsistent with a captured microphone; prosody regular through two interruptions.", "created_at": "2026-08-31T09:14:22Z"
}

verdict is one of synthetic, human or unclear. All three are outcomes. unclear means the audio did not support an answer, and collapsing it into human is how a product ends up implying a clearance it never received — the single most consequential mistake available to anyone integrating this.

generator is null whenever the clip matches no signature we hold. The verdict can still be correct. We do not fall back to the nearest match, because naming the wrong system confidently does more harm, once challenged, than admitting we cannot name one.

reason is written for a person, not for a parser. Show it. A verdict without a stated reason is the thing this product exists to be an alternative to.

Reading the two confidences

• confidence concerns the verdict. Never render it as a bare number: 0.55 and 0.96 are both synthetic and mean entirely different things, and a percentage on its own invites the reader to supply the difference themselves.
• generator_confidence concerns attribution only. It decays faster than the verdict does, because a vendor can ship a new model in any given week, and each one nudges its signature away from the version we hold. Treat a low value as a reason to say nothing about the vendor rather than a reason to hedge.
• false_positive_rate is the share of authentic recordings this model wrongly marks as generated, measured for the detected channel. Display it anywhere a verdict could affect a person. It is the figure most of this market omits, and omitting it from your interface undoes the reason for choosing us.

Why the two verdicts are not symmetric, and why human should be shown more cautiously than synthetic, is set out on the accuracy page.

Two things not to build

Live call scoring. Streaming call audio through the endpoint and displaying a running verdict to an agent is the most requested integration and the one we would decline to support. Call audio is compressed exactly where the analysis reads, and a judgement delivered mid-sentence cannot be reviewed afterwards by anyone.

Automated action on a verdict alone. Blocking an account, freezing a payment or escalating a case because a single response came back synthetic puts a probability in the position of a decision. Route it to a person, with the confidence, the error rate and the reason attached.

Errors, as designed

Errors are refusals to answer rather than verdicts, and the intention is that none of them counts against a quota. Note that unclear is deliberately not in this table: it is a successful analysis with an honest outcome, and treating it as an error would push integrators towards hiding it.

Retention and versioning

The plan is that submissions can be sent with retain=false, so the audio is discarded once analysis completes while the verdict and reference survive. Default retention is not fixed: [VERIFY: default API retention period]. What is settled is the principle, described on the security page.

The path carries the major version, but model versions will change far more often than the API does. That is why model_version is on every response and why it should be stored beside every verdict you keep. A result acted on in one quarter has to remain explicable in the next, and the method changelog is where the difference between two versions gets recorded.

Questions