v2.6.20Latest

When a transcription fails, the error now tells you why. Your transcription provider's own reason is added to error_message in the API, in webhooks and in the dashboard. Teams that bring their own storage or their own transcription key get safer retranscription and retention behaviour, and Google Meet and Microsoft Teams transcripts contain fewer Unknown speakers.

⚡Improvements

• Failed transcriptions include your provider's reason. When a bot ends with TRANSCRIPTION_FAILED, error_message keeps its standard sentence and adds Details: <provider reason> (up to 600 characters), for example a rejected custom parameter or a provider timeout. The reason appears in GET /v2/bots/{bot_id}, GET /v2/bots, the bot.failed webhook and the dashboard, where it is shown under the bot's status. Other error codes keep their exact text. If you match error_message exactly for TRANSCRIPTION_FAILED, match on error_code instead, see error codes. Before: "error_message": "The transcription process failed. …" → After: "error_message": "The transcription process failed. … Details: <provider reason>"
• Temporary transcription provider errors are retried more reliably. A submission is retried when your provider reports the error as temporary, such as a timeout or a network error, and is not retried when the provider reports it as permanent.
• Fewer Unknown speakers in Google Meet and Microsoft Teams transcripts. A segment the bot could not attribute is now named after the participant shown as speaking in the meeting at that moment, or, if there was none, after the nearest identified speaker.
• Deleting a bot's data also clears its status history. The status timeline is cleared together with the rest of the bot's data, both on a per-bot delete and when the bot passes your plan's retention window. Bots whose data was already deleted are cleared as part of this release.
• Request logs are kept for 14 days, down from 90 days.
• Webhook payloads are kept for at most 5 days by our delivery infrastructure, including payloads that were never delivered. Before, they were kept for up to 90 days.

🐛Bug Fixes

• Retranscribing a bot on your own storage no longer sends non-audio files to your transcription provider. When your recordings, audio chunks and logs shared one bucket, POST /v2/bots/{bot_id}/retranscribe submitted every file stored for the bot, including screenshots, logs and the full meeting audio. This could create hundreds of failed requests on your provider key, bill the same audio twice, and leave the bot stuck in transcribing. Only the bot's audio is submitted now. Bots whose audio chunks have already expired are retranscribed from the final audio file. See bring your own storage.
• Transcripts written to your own storage no longer fail with the documented permissions. Storing a completed transcript required PutObjectTagging on the service key, which the documented service-key permissions do not include. The service key now only needs the documented permissions.
• After retention removes your transcription API key, we no longer call your provider with our own key. For bots that used your own provider key, status checks, result fetches and provider-side deletions now stop once that key has been removed. Before, they were retried with our own account, and a provider-side deletion could be reported as successful even though it had not happened. Bots that never set their own key are unaffected.

↩ All releases