Synthetic audio marking

Every audio byte this API returns is model output — synthesis, voice previews, and the model’s side of a live session. So every one of them carries a machine-readable marker saying so. You do not opt in, and you cannot turn it off. The other side of a live session is the microphone. What the caller says is not model output, nothing marks it, and no claim on this page reaches it. This exists because the EU AI Act Article 50(2), applicable since 2 August 2026, requires AI-generated audio to be marked in a machine-readable format and detectable as artificially generated. It is a different duty from telling the person they are talking to an AI — see Compliance for that one.

The marker

{
  "schema": "eesi-synthetic-audio/1",
  "ai_generated": true,
  "producer": "eesi",
  "model": "nur-tts-v1",
  "created": "2026-09-06T14:22:08Z"
}

Five fields, and the interesting part is what is missing. There is no voice id, no account, no session id, no request id. This marker travels attached to audio that may be someone’s cloned voice, and a marker carrying identity would make every generated clip a tracking beacon rather than a disclosure. created is UTC to the second. schema is versioned so a reader can tell which shape it is looking at without guessing from the fields present.

Where it is written

Surface	Where the marker rides
`POST /v1/audio/speech`	`X-Synthetic-Audio` response header, plus the container metadata below
`POST /v1/voices/{voice_id}/preview`	`X-Synthetic-Audio` response header, plus an ID3 frame in the mp3
`WS /v1/realtime` and `WS /v1/realtime/translations`	`X-Synthetic-Audio` on the handshake response, and an `eesi.synthetic_audio` event sent before any other frame

Both live endpoints run the same session, so an interpreting session is marked identically to a conversational one. They send the header and the event because a browser cannot read handshake headers. The event arrives with the session-start declarations, ahead of any audio, so a client knows before it plays anything. Inside the audio itself, the placement depends on the container. The key is EESI_SYNTHETIC_AUDIO in every format that has one, so a single verifier finds it everywhere:

Format	Placement
`wav`	A RIFF `LIST`/`INFO` chunk with the marker in `ICMT`, written after `fmt`
`mp3`	An ID3v2 `TXXX` frame named `EESI_SYNTHETIC_AUDIO`
`flac`	A Vorbis comment block
`opus`	An `OpusTags` comment
`pcm`	Header only. Raw PCM has no container and no metadata slot
`aac`	Header only. Bare ADTS has no slot a prefix rewrite can fill

nur-tts-v1 advertises mp3, wav and pcm, so those three are what you will see in practice today. The flac and opus writers exist for a model that advertises them. Check formats on the model catalog.

Marking never buffers your audio. Each writer rewrites a bounded prefix — in practice the first chunk the model has already produced — and relays the rest untouched, so the payload is byte for byte what the model generated and time-to-first-byte is unchanged. Each writer also fails closed. Given bytes that are not exactly what the format requires, it returns them unmodified rather than risking a corrupt file: unmarked audio is a compliance gap, corrupted audio is a broken product. The response header is the layer that is always there. Read that first and treat the container metadata as the copy that survives being saved to disk.

Read it

From the response, before you have written anything to disk:

curl -sS -D headers.txt -o reply.mp3 https://api.eesi.ai/v1/audio/speech \
  -H "Authorization: Bearer $EESI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"nur-tts-v1","input":"A short line.","voice":"auto"}'

grep -i '^x-synthetic-audio:' headers.txt

import json

import httpx

response = httpx.post(
    "https://api.eesi.ai/v1/audio/speech",
    headers={"Authorization": f"Bearer {api_key}"},
    json={"model": "nur-tts-v1", "input": "A short line.", "voice": "auto"},
    timeout=60,
)
response.raise_for_status()
marker = json.loads(response.headers["X-Synthetic-Audio"])
assert marker["ai_generated"] is True
open("reply.mp3", "wb").write(response.content)

const response = await fetch("https://api.eesi.ai/v1/audio/speech", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "nur-tts-v1",
    input: "A short line.",
    voice: "auto",
  }),
});
if (response.status >= 400) {
  throw new Error(await response.text());
}
const marker = JSON.parse(response.headers.get("X-Synthetic-Audio") ?? "{}");
console.log(marker.ai_generated, marker.model);

From a file you already have, with ordinary tools:

ffprobe -v error -show_entries format_tags:stream_tags -of json reply.mp3

{
  "streams": [{}],
  "format": {
    "tags": {
      "EESI_SYNTHETIC_AUDIO": "{\"schema\":\"eesi-synthetic-audio/1\",\"ai_generated\":true,\"producer\":\"eesi\",\"model\":\"nur-tts-v1\",\"created\":\"2026-09-06T14:22:08Z\"}",
      "encoder": "Lavf61.7.100"
    }
  }
}

That output is from a locally encoded file, not from the download above — the encoder tag beside the marker is ffmpeg’s, and an API response carries whatever its own encoder wrote there, or nothing. The tag to read is EESI_SYNTHETIC_AUDIO; treat everything else in tags as the container’s own business. Both format_tags and stream_tags are worth asking for: mp3 and flac put the comment on the format, opus puts it on the stream. A wav reports the marker as comment, because that is what ICMT maps to.

Live sessions

{
  "type": "eesi.synthetic_audio",
  "event_id": "event_9f2c…",
  "marker": {
    "schema": "eesi-synthetic-audio/1",
    "ai_generated": true,
    "producer": "eesi",
    "model": "nur-realtime-v1",
    "created": "2026-09-06T14:22:08Z"
  }
}

It is vendor-prefixed with eesi. so an OpenAI-compatible client can ignore it without special-casing, and it declares the whole session rather than each frame: everything that session sends downstream is model output. See Realtime events.

The claim you must not make

This is metadata, not a watermark. Container metadata survives copying a file and moving it between machines. It does not survive a re-encode, a transcode, or a re-recording — one ffmpeg invocation removes it, and stripping it is neither hard nor detectable.

So the marker supports exactly one claim: this audio came from the EESI API and is machine-generated. It cannot support its negation. Audio you find elsewhere with no marker is not thereby human, and audio with a marker you did not receive over your own connection proves nothing about who produced it. Use it to attest to the provenance of your own output. Do not build a detector out of it. Robust perceptual watermarking — the kind that survives re-encoding — is not shipped here.

One gap, stated

A voice’s stored reference clip is served rather than generated, and it carries no marker. GET /v1/voices/{voice_id}/ref_audio returns the clip’s bytes; GET /v1/voices/{voice_id}/sample returns { "url", "content_type" }, a short-lived signed storage URL pointing at the same object. Neither the bytes nor the object behind the URL is marked. For a cloned voice that clip is the recording you uploaded of a real person, which is not synthetic audio. For a built-in voice it is frozen design output that is. If you redistribute a built-in voice’s reference clip, mark it yourself. Anything generated on demand — synthesis, preview, a live session — is marked.

Start here

Realtime interaction

Speech

Platform

Synthetic audio marking

The marker

Where it is written

Read it

Live sessions

The claim you must not make

One gap, stated

Going further

Compliance

Text to speech

​The marker

​Where it is written

​Read it

​Live sessions

​The claim you must not make

​One gap, stated

​Going further

Compliance

Text to speech

The marker

Where it is written

Read it

Live sessions

The claim you must not make

One gap, stated

Going further