[Feature]: SageMaker endpoint support in the CLI

[GregHolmes]

Summary

Add SageMaker endpoint support to dg, so a customer running Deepgram self-hosted (BYOC) on Amazon SageMaker can test their endpoint from the CLI.

Problem to solve

Deepgram self-hosted (BYOC) on Amazon SageMaker is a supported deployment path, but there is no quick way to confirm a freshly provisioned endpoint actually works. Verifying it today means writing code against one of the SDKs, or hand-rolling a SageMaker InvokeEndpoint call with SigV4 signing and the right request envelope.

dg listen and dg speak are the natural smoke test for "is my endpoint up and transcribing", and right now they only talk to the hosted API.

Proposed solution

A sketch rather than a settled design. Route the existing commands through a SageMaker transport, selected by flag or environment variable:

# Batch STT against a SageMaker real-time endpoint
dg listen recording.wav --sagemaker-endpoint my-deepgram-endpoint --aws-region us-west-2

# Same thing via env, so existing examples work unchanged
export DG_SAGEMAKER_ENDPOINT=my-deepgram-endpoint
export AWS_REGION=us-west-2
dg listen recording.wav --model nova-3

# TTS
dg speak "Hello from SageMaker" --sagemaker-endpoint my-deepgram-endpoint -o hello.wav

Credentials should come from the standard AWS chain (environment, shared config, instance role) rather than anything Deepgram-specific.

Open questions for whoever picks this up:

• Which surfaces to cover first. Batch listen is the cheapest useful smoke test; streaming and speak are reasonable follow-ups.
• Whether this is a global option or per-command.
• What dg whoami, dg projects, dg keys and dg usage should do when a SageMaker endpoint is configured, since those are hosted-API only and should fail with a clear message rather than a confusing auth error.

Alternatives considered

• Do nothing. Customers keep writing throwaway scripts to verify a deployment.
• Document a curl or aws sagemaker-runtime invoke-endpoint recipe instead. Workable, but SigV4 plus the request envelope is a lot of ceremony for a smoke test, and it does not exercise the same code path the SDKs use.
• Leave it to the SDKs. They already support it, but that needs a project and code, which is the friction this is trying to remove.

Scope

Enhancement to existing commands, or a core/framework change, depending on which of the design options above is chosen.

Priority

Nice to have. This was explicitly raised as a non-priority request.

Extra context / links

The SageMaker transport already exists in the SDKs, so the wire format and request envelope are established and this should largely be a matter of wiring the CLI to the same path:

• JavaScript: feat: add pluggable transport interface for sagemaker support deepgram-js-sdk#492, pluggable transport interface for SageMaker support
• Java: feat: pluggable transport interface for SageMaker support deepgram-java-sdk#29, pluggable transport interface for SageMaker support
• Python: fix(sagemaker): extract SageMaker transport to separate deepgram-sagemaker package deepgram-python-sdk#665, SageMaker transport extracted into a separate deepgram-sagemaker package

Docs: https://developers.deepgram.com/docs/amazon-sagemaker

Raised internally in May 2026 and agreed at the time, but never filed as an issue. Opening it now so it is actually tracked.