Gemini 3.8 Voice Replication: POST /v1beta/voices returns 500 INTERNAL with REST and google-genai 2.25.0

Gemini API
1

I am trying to register a replicated voice using the documented Gemini Developer API Voices endpoint. On September 24, 2026, registration failed with both direct REST and the official Python SDK.

Endpoint: POST https://generativelanguage.googleapis.com/v1beta/voices
Model: gemini-3.8-flash-tts
Voice type: replicated
Storage: store=true
SDK comparison: google-genai 2.25.0, Python 3.14, httpx 0.28.1 on macOS.

The response is HTTP 500, status INTERNAL, message: “Error translating server response to JSON”.

The in-range reference WAV is 29.8 seconds, 24 kHz, mono, PCM 16-bit. It combines excerpts from two recordings of the same speaker with a short silence between them. The separate consent WAV is about 11.97 seconds, also 24 kHz mono PCM 16-bit, with that speaker reading the documented Japanese consent statement. Both are sent as base64 data with mime_type audio/wav.

Request structure (audio omitted):

{
  "store": true,
  "voice": {
    "model": "gemini-3.8-flash-tts",
    "type": "replicated",
    "display_name": "Voice replication test",
    "replicated": {
      "source_audio": {"mime_type": "audio/wav", "data": "<BASE64_REFERENCE>"},
      "consent_audio": {"mime_type": "audio/wav", "data": "<BASE64_CONSENT>"}
    }
  }
}

The display name above is anonymized. Offline comparison confirmed that SDK serialization matched the direct REST request body for our test, including the audio bytes.

With the same 29.8-second input, direct REST returned the error after about 10.52 seconds, and the SDK after about 6.64 seconds. Each test issued only one POST; automatic retries were disabled and an independent transport guard prevented duplicate POSTs.

GET /v1beta/voices?type=replicated returned HTTP 200 with zero voices and no next page before and after these attempts. No voice ID was obtained and no subsequent speech synthesis was attempted. This does not establish that consent verification or create permissions succeeded.

An earlier reference was 55.4 seconds (outside the documented 10–30 second range) and failed too; the observations above use the corrected 29.8-second reference.

Could the team help clarify:

  1. Is this a known CreateVoice / voice replication error?
  2. Are there additional eligibility or input constraints not described in the guide, including concatenated recordings or Japanese consent?
  3. How can we distinguish reference/consent validation failure from a backend response-serialization failure?
  4. Which request identifiers or non-sensitive diagnostics would help, and is there a private support channel if audio is needed?

For privacy, this public report contains no audio, API keys or account/project identifiers. I have not established the root cause and am not assuming this is a general outage.

2

Good news: I have now successfully registered a replicated voice and generated speech with it. Sharing the follow-up results in case they help others or the team investigate the 500 response.

  1. I recorded a fresh reference clip (about 17 seconds) and a separate Japanese consent clip (about 12 seconds) as a pair in the same recording session. After converting both to 24 kHz mono PCM 16-bit WAV, CreateVoice returned HTTP 200 in about 9 seconds. The new voice appeared in ListVoices, and subsequent speech synthesis also succeeded.
  2. I then kept that same successful consent clip and tried one older reference recording on its own, using its full 24.9 seconds with no concatenation. This returned the same HTTP 500 INTERNAL: “Error translating server response to JSON”. The previously registered voice remained available.

Both registration tests used gemini-3.8-flash-tts, google-genai 2.25.0, store=true, and the same project. Each test made one registration POST with automatic retries disabled. A separate display name was used for the second test.

Recording a fresh reference-and-consent pair worked well in my case. The single-clip follow-up also shows that concatenation alone does not explain the earlier failures. Differences between the older reference and the new consent recording may be worth investigating, including recording conditions and speaker verification.

If an input or speaker/consent verification issue is involved, a more specific error message would be very helpful so users know what to adjust. The successful generated voice sounds close to my own, so I am pleased with this progress. Thank you!