Deepgram India endpoint GA: voice data localization vs a US-hosted API

Deepgram made its India regional endpoint, api.in.deepgram.com, generally available on September 15, 2026, covering speech-to-text, text-to-speech, the voice agent and text intelligence. If your rule is that voice data must be processed in India, that endpoint exists; Sume documents no regional endpoint, and the repository's operations notes place its API in the US.

Deepgram details come from its changelog, read 2026-10-03. Sume details come from the OpenAPI reference and Sume's own operations notes in the repository. Data-localization rules differ by sector and contract, so this post lists facts, not a legal conclusion.

What does the Deepgram India endpoint cover?

The changelog lists the supported paths: /v1/listen and /v2/listen for speech-to-text, /v1/speak and /v2/speak for text-to-speech, /v1/agent/converse for the voice agent, and /v1/read for text intelligence. WebSocket URLs use the same host, for example wss://api.in.deepgram.com/v1/listen. The page adds that existing API keys and tokens work with regional endpoints, so moving is mostly a base-URL change.

One related caveat appears in the October 2 entry on mid-stream keyterms: that feature is on the global endpoint only and not yet on the EU, Australia or India endpoints. Regional endpoints can trail the global one on new features, so check the changelog for the feature you need, not only for the product.

Where does Sume run?

Sume's public API is at api.sume.com, with one host and no region selector in the request fields documented in the OpenAPI reference. The repository's operations notes say the API service runs in the us-east4 region with two instances, that Vercel functions run in iad1 and that the database is in us-east4. Those notes describe Sume's own services; they do not say where each upstream speech or music provider processes audio.

So if your requirement is that audio and transcripts stay in India, Sume's documentation does not let you claim that. It is an honest gap, and it is cheaper to find out before you build than after a customer's security review.

What can you still do with Sume if data location is flexible?

If your constraint is retention or access rather than location, the docs give you some controls. Jobs are scoped to a workspace and to the member whose key made them, reads from another member or workspace return 404 not_found, and artifacts are hosted on media.sume.com. Webhooks deliver terminal events only, so you can pull results into your own storage and stop depending on the hosted copy.

Sume STT takes a public HTTPS audio_url, up to ten minutes per job, at $0.01 per audio minute; TTS is billed per character at $0.0475 per 1,000. None of that changes where processing happens, so do not read it as a localization feature.

How should you decide?

Write the requirement down in one sentence before comparing vendors: is it processing location, storage location, or who can access it? Then ask each vendor a matching question and get the answer in writing.

• Processing must be in India: use a provider with a documented in-country endpoint, such as Deepgram's, for that traffic.
• Storage must be in India: download artifacts promptly and keep them in your own bucket.
• Only access control matters: workspace-scoped jobs and member-owned keys may be enough.
• Unknown: ask Sume support before you promise anything in a contract.