Skip to main content
This step-by-step guide shows how to switch your realtime transcription from Deepgram to Gladia with minimal code changes. It highlights equivalences, subtle differences, and drop‑in replacements so you can migrate quickly and confidently, without any regressions.

Step-by-step guide

Install the SDK

Install the official SDKs to enable realtime streaming. That’s all you need to get started in Python or TypeScript. For Deepgram :
For Gladia:

Initialize the client

Create and authenticate the client that manages your live connection. The shape is the same idea across providers—just swap the client and key. For Deepgram :
For Gladia :

Configure the session

Choose the model, audio format, and language options your app needs. Most parameters map one‑to‑one, so your existing settings carry over naturally.

Deepgram to Gladia parameter mapping

Gladia config example
See the full schema in the live init reference.

Start the transcription session

Open a live transcription session using your configuration. The flow is the same as with Deepgram: establish the WebSocket and get ready to stream audio. For Deepgram :
For Gladia :

Send audio chunks

Stream audio frames to the session as they are produced. Both SDKs accept small chunks continuously—keep your existing chunking logic. For Deepgram :
For Gladia :

Read transcription messages

After audio is flowing, subscribe to transcript and lifecycle events. The mapping below shows how to translate Deepgram listeners to Gladia in a single place. Event mapping from Deepgram to Gladia:
  • Transcript → listen to Gladia message and branch on message.data.is_final to separate partial vs final results.
  • Open/Close/Error → map to Gladia started/ended/error.
In practice, subscribe once to message and use the is_final flag instead of wiring separate listeners—less boilerplate, same control. To receive partials, enable messages_config.receive_partial_transcripts: true in your init config. For Deepgram :
For Gladia :