Setting up a Fallback Transcription Workflow

In the case where your primary provider fails to generate transcripts for a meeting, you may want to set up a fallback transcription workflow. This can help ensure you always have transcripts available, even if there are issues with the primary provider.

This can also be useful when you're using meeting captions for transcription and the host's settings have captions disabled, preventing a transcript from being generated.

Implementing a Fallback Mechanism

The recommended approach to set up a fallback transcription provider is to add a check in your post-call workflow when you receive the done webhook for a bot.

Here are the steps:

1. Check if the bot has a valid recording (contains a video_url) and participants were present in the meeting (the length of meeting_participants is greater than 0).

2. If true, check if the transcript is empty.

3. If the transcript is empty, assume the primary transcription provider failed. At this point, you can kick off an asynchronous transcription job using a different provider. Follow the asynchronous transcription quickstart guide and use the Analyze Bot Media endpoint.

This approach is recommended because it is consistent and agnostic to the transcription provider, as it doesn't rely on specific error codes from a given service.

Alternative Approach

Another option is to listen for transcription error webhooks from the primary provider. If an error is received, you can mark the bot as "failed" in your database and use that to determine whether an asynchronous transcription job should be kicked off.

However, this method can be more cumbersome as it involves storing additional state in your database instead of adding a check in your post-call workflow.