Deepgram retires dg-token as a way to verify speech callbacks

Deepgram retired its dg-token callback header and documented other ways to verify callbacks.

**Dek:** The October 27 notice tells integrators to move callback verification to Basic Auth. Speech-to-text also has a documented option using a secret passed with extra metadata.

Deepgram’s October 27 changelog says callback receivers should stop relying on the dg-token header to verify requests from Deepgram. The provider directs integrators to Basic Auth and says speech-to-text callbacks can also use a secret supplied through the documented extra metadata mechanism. The notice links callback guidance for speech-to-text, text-to-speech and Text Intelligence. [Deepgram October 27 changelog](https://developers.deepgram.com/changelog/2026/10/27)

The callback and the original job have separate trust boundaries

A service may use one credential to submit a transcription job and a different mechanism to recognize the notification sent back when it finishes. The outbound job credential answers whether the caller can use Deepgram. The callback receiver needs to decide whether a request at its own endpoint can update a job or attach a transcript. Changing that second check should not make the first credential available to the receiver or its logs.

An integration that checks only the retired header should review the exact callback path and configuration it uses. A product receiving speech-to-text callbacks can evaluate the documented options for that path. Teams using text-to-speech or intelligence should verify the instructions for those products separately, since the changelog describes the extra metadata option specifically for speech-to-text. [Deepgram October 27 changelog](https://developers.deepgram.com/changelog/2026/10/27)

Test a valid notification and a rejected one

In a test environment, send a callback through the intended service flow and confirm it updates only the matching job. Then exercise a request that lacks the expected credential and one that carries a valid-looking job identifier without authorization. The receiver should reject the invalid request before changing stored results. Logs can identify the failure class without retaining the credential or the full callback body.

A callback can also arrive more than once or after the consumer temporarily loses its connection. The service should use the original job identity to reconcile an already applied result. That is separate from verifying the sender. The change to authentication is a good point to verify both properties because they protect different parts of the same asynchronous workflow.