SDK blocking path: speech_model in options causes AssemblyAI 400

[Lazare-42]

Bug

Related to #21 (now fixed in schema). The blocking batch path (router.transcribe()) still fails when user-provided options contain speech_model (singular, deprecated).

Scenario

Bots created with SDK < 0.8.5 have transcription_custom_params: { "speech_model": "universal" } stored in the database. When retranscribing these bots, the stored params are passed to router.transcribe(). The SDK forwards speech_model to AssemblyAI, which responds:

Invalid endpoint schema, please refer to documentation for examples. — HTTP 400

Root cause

The SDK's internal AssemblyAI adapter in router.transcribe() doesn't map/strip the deprecated speech_model key. Since v0.8.5 removed speech_model from AssemblyAITranscriptionSchema, new bots won't have it — but existing bots with stored params still do.

Expected behavior

The SDK should either:

1. Map speech_model → speech_models: [value] internally (backwards compat), or
2. Strip speech_model and log a deprecation warning

Workaround

We're mapping speech_model → speech_models in our wrapper before calling router.transcribe():

if (provider === "assemblyai" && "speech_model" in unflattened) {
  if (!("speech_models" in unflattened)) {
    unflattened["speech_models"] = [unflattened["speech_model"]]
  }
  delete unflattened["speech_model"]
}

[Lazare-42]

Update — root cause confirmed:

The actual error was NOT speech_model vs speech_models. It's that router.transcribe() passes diarization: false directly to AssemblyAI, which doesn't have a diarization field (it uses speaker_labels).

When called with:

router.transcribe({ type: "url", url }, { provider: "assemblyai", assemblyai: { diarization: false } })

The SDK sends { "diarization": false, ... } to https://api.assemblyai.com/v2/transcript, which returns:

Invalid endpoint schema, please refer to documentation for examples. — HTTP 400

Expected: The SDK should either:

1. Map diarization → speaker_labels for AssemblyAI
2. Strip unknown fields before sending to provider APIs
3. Not pass through raw diarization as-is

Workaround: We now only include diarization in options when it's true (no point sending false).