danny-avila/LibreChat · error
Invalid response from the STT API
Error message
Invalid response from the STT API
What it means
After axios.post returns, sttRequest checks response.status; anything other than 200 throws. The surrounding try/catch logs the failure via logAxiosError (which records the upstream status/body) and re-throws, so callers see 'Invalid response from the STT API' while the detailed status lives in the log. Non-200 usually means auth (401/403), bad request (400), throttling (429), or upstream error (5xx).
Source
Thrown at api/server/services/Files/Audio/STTService.js:319
const [url, data, headers] = strategy.call(
this,
sttSchema,
audioReadStream,
audioFile,
language,
);
const options = { headers };
applyAxiosProxyConfig(options, url);
applySSRFSafeAgentIfDirect(options, url, allowedAddresses);
try {
const response = await axios.post(url, data, options);
if (response.status !== 200) {
throw new Error('Invalid response from the STT API');
}
if (!response.data || !response.data.text) {
throw new Error('Missing data in response from the STT API');
}
return response.data.text.trim();
} catch (error) {
logAxiosError({ message: `STT request failed for provider ${provider}:`, error });
throw error;
}
}
/**
* Processes a speech-to-text request.
* @async
* @param {Object} req - The request object.
* @param {Object} res - The response object.View on GitHub (pinned to 5ff282f900)
Solutions
- Read the logAxiosError output to get the real upstream status and body.
- Verify the provider apiKey, instanceName, deploymentName, and apiVersion in librechat.yaml.
- For 429/5xx, retry with exponential backoff; for 401/403 rotate and re-set the key.
- Confirm the resolved URL points at the intended STT deployment.
Defensive patterns
Strategy: try-catch
Try / catch
try {
const text = await stt.sttRequest(provider, sttSchema, { audioBuffer, audioFile, language }, allowedAddresses);
} catch (err) {
// logAxiosError already recorded the upstream status/body server-side
if (/Invalid response from the STT API/.test(err.message)) {
return res.status(502).json({ error: 'STT provider returned an error status' });
}
throw err;
} Prevention
- Treat non-200 as expected from upstreams; surface a 502 to the client and log the real status.
- Keep apiKey/deployment/apiVersion in config so they can be rotated without code changes.
- Add retry-with-backoff for 429 and 5xx only, never for 4xx auth errors.
When it happens
Trigger: Azure/OpenAI-compatible STT endpoint returns a non-200 status: wrong apiKey (401), wrong deployment/instance (404), stale api-version (400), rate limit (429), or provider outage (5xx).
Common situations: Rotated key not updated in config; deployment deleted in Azure; apiVersion pinned to a deprecated value; burst of requests hitting a throttle; transient provider 5xx.
Related errors
- Failed to fetch image from URL. Status: ${response.status}
- Request failed with status ${response.status}: ${json.error.
- Missing data in response from the STT API
- No STT schema is set. Did you configure STT in the custom co
- Multiple providers are set. Please set only one provider.
AI-assisted analysis of danny-avila/LibreChat@5ff282f900 (2026-08-12).
Data as JSON: /api/errors/68839558770f0566.
Report an issue: GitHub.