Connecting Deepgram to n8n: transcription without a native node, webhook callback, and diarization

n8n's OpenAI node handles Whisper transcription well enough, but as soon as a project needs reliable speaker recognition or a large volume of calls at a lower cost per minute, Deepgram quickly comes up. The catch: n8n gives it no native node at all. The whole integration runs through a raw HTTP Request node, and two concrete traps await anyone trying to copy a "classic Whisper" pattern — blocking the workflow waiting for the response instead of using Deepgram's asynchronous callback, and confusing the pre-recorded API with real-time streaming, which follows an entirely different protocol.

No native node: everything goes through HTTP Request

Deepgram's pre-recorded transcription API is called with a POST request to https://api.deepgram.com/v1/listen, an audio file or URL in the request body, and an Authorization: Token <API key> header — not to be confused with the Bearer scheme used by most other AI APIs, OpenAI included. The current model is selected via the model parameter (nova-3 at the time of writing, successor to nova-2), and the language via language (or language=multi for automatic detection, depending on the model).

If you've already built a transcription pipeline with the OpenAI node and Whisper, the HTTP Request node's structure stays similar: a Set node upstream prepares the audio URL or binary, then the HTTP Request node points to /v1/listen with the chosen query parameters. The real difference shows up in what Deepgram lets you do with that same call afterward — native diarization and an asynchronous callback — with no extra code.

An asynchronous callback instead of a blocking call

For a file a few minutes long, a plain synchronous call (the HTTP Request node waits for the response) works fine. For an hour-long recording, it no longer holds up: the node stays open for the full duration of the transcription, with a real risk of timing out depending on how the n8n instance is configured — a problem already covered in our guide on AI agent timeouts.

Deepgram offers a cleaner alternative: add the callback query parameter with the URL of a Webhook node on your n8n instance. The call to /v1/listen then responds immediately with a simple request_id, and Deepgram sends the full transcription result in a separate POST request to that callback URL once it's ready (retrying up to ten times, 30 seconds apart, if delivery fails). The workflow splits into two: a first one triggers the send to Deepgram and ends right away, a second one — triggered by the Webhook — receives the transcription JSON and continues the processing (LLM summary, writing to Notion or Supabase, Slack notification). It's the same principle as the webhook signature-verification pattern already covered for SendGrid: one call that triggers processing, and a separate webhook that picks up the result.

Turning on diarization (who spoke, and when)

Whisper transcribes a continuous stream without distinguishing speakers; Deepgram does it natively via the diarize=true parameter. Every word in the JSON response then carries a speaker field (0, 1, 2…), and adding utterances=true groups words directly into per-speaker turns — a far more usable output than an array of individual words you'd have to reassemble yourself in a Code node. For a multi-participant meeting summary, that speaker field saves you from making an LLM guess who said what from raw text alone — a frequent source of error when diarization is missing.

Deepgram vs Whisper: what actually changes for an n8n workflow

Three differences genuinely matter for the choice, beyond the performance numbers published by the vendors themselves (treat those as rough orders of magnitude, not independent benchmarks):

• Native diarization: built into the Deepgram call (diarize=true), absent from n8n's OpenAI/Whisper node, which only returns continuous text.
• Built-in asynchronous processing: Deepgram's callback parameter saves you from building your own queue for long recordings, while a Whisper call stays synchronous by default.
• Real-time architecture: Deepgram offers a genuine streaming feed over WebSocket (wss://api.deepgram.com/v1/listen), which Whisper doesn't natively provide — but that persistent-connection protocol falls outside what an n8n HTTP Request node can do, see below.

These architectural points are verifiable in both vendors' documentation; cost-per-minute or word-error-rate (WER) gaps vary by language and audio type and aren't repeated here for lack of a recent independent benchmark.

The real-time streaming limit with HTTP Request

The wss://api.deepgram.com/v1/listen endpoint transcribes a live audio stream word by word, with latency on the order of a few hundred milliseconds. It's a WebSocket: a persistent, bidirectional connection, the opposite of a REST API's request-response model. n8n's HTTP Request node cannot hold that kind of connection open — it isn't built for it, and no native n8n node covers this case at the time of writing.

In practice, for n8n use, two reasonable options: stick with the pre-recorded API plus callback (which fits nearly every case — meeting summaries, post-call transcription, delayed captioning), or offload the WebSocket connection to a small external service (a serverless function, for instance) that receives the live stream and forwards already-transcribed segments to n8n through a plain Webhook. True real-time driven entirely from within n8n stays, for now, out of reach of the HTTP Request node.

A study by Cao, Ganesh, Cai et al. (2023), A Comparative Analysis of Automatic Speech Recognition Errors in Small Group Classroom Discourse, published at ACM UMAP, makes a useful point for any automated transcription pipeline: a speech-recognition engine's error rate rises sharply as soon as several speakers overlap or speak with an accent far from the training data — a reminder that diarization and human review still matter even with a strong engine, rather than treating the raw output as final.

A concrete case: support call transcription with speaker identification

1. A call recording (customer + agent) lands in a Drive folder or arrives via webhook from the phone system.
2. A first n8n workflow sends the file's URL to /v1/listen with diarize=true, utterances=true, and the callback parameter pointing to a second n8n webhook, then ends.
3. The second workflow receives Deepgram's JSON, splits the turns by speaker, and feeds it all into a Basic LLM Chain for a structured summary (reason for the call, resolution, points of customer friction).
4. The summary is archived in Supabase for a later audit, with a Slack alert if the detected reason matches a complaint.

Common pitfalls

• Using the Bearer scheme instead of Token in the Authorization header: Deepgram rejects the call with an authentication error that misleadingly looks like an invalid API key.
• Leaving the HTTP Request node blocked waiting on a long file instead of using the callback parameter, risking an execution timeout.
• Forgetting utterances=true and having to rebuild the per-speaker word grouping yourself in a Code node, when Deepgram provides it directly.
• Trying to drive the WebSocket streaming with an HTTP Request node: that protocol simply isn't one this node speaks.

Going further

This transcription-and-summary pipeline — whether it runs on Deepgram or on Whisper via the OpenAI node — fits naturally into a broader call- or meeting-processing system: sorting and prioritization with the Inbox AI Pack (€79), or archiving and an audit trail with the Compliance & Audit Pack (€149) for sectors that need to keep a usable record of every customer exchange. The Complete FlowKit Bundle (€269 instead of €347 bought separately) brings both together with the RAG Assistant Pack to make those transcriptions searchable afterward.