We use AI to write faster, not to decide what’s true. Someone at Digital Samba read every line of this article before you did.
You're adding video to your product, and somewhere around the second customer call it becomes obvious that video alone isn't enough. People want a transcript to search later, and someone will ask for a summary they can skim instead of re-watching an hour of footage.
So you go looking for a video transcription API to bolt on, and that's where it gets complicated: most transcription and meeting-summary services route your users' audio through US-hosted infrastructure, or hand it to a third-party LLM you have no contractual visibility into. For a consumer app, that's a footnote. For a SaaS platform selling into EU healthcare, education or legal customers, it's often a dealbreaker before the feature ships.
There's an alternative worth knowing about: you can get live captions, full transcripts and AI-generated summaries with speaker attribution through a single API, with the audio and text handled by EU-based infrastructure and a sub-processor rather than a separate US-based notetaker service. This piece is about how it works and how to integrate it: we'll walk through what the pieces are, how Digital Samba implements them, what a minimal integration looks like, and the one trade-off worth understanding before you switch it on. Near the end we'll also touch briefly on how this compares architecturally to bolting on a standalone notetaker bot, though that's not the main focus.
Table of contents
Buyers evaluating this kind of feature tend to conflate three distinct things, whether they're calling it a meeting transcription tool, an AI notetaker, or just 'the API'.
Before committing to any provider, run through a short checklist:
Live captioning and post-session transcripts are two sides of the same feature. In-room, captions can be switched on per room with a defined spoken language: text streams in as people talk and corrects itself on the fly for a synchronised feel. Caption languages currently cover Bulgarian, Catalan, Danish, Dutch, English, Finnish, French, German, Italian, Portuguese, Romanian, Spanish, Swedish and Turkish, with more added as the underlying speech models are extended.
Transcription is controllable both in-room and via the REST API. Moderators can start or stop it from inside the session, or you can trigger it programmatically, and rooms can be configured with an auto-start setting so transcription begins the moment the first participant joins. Once a session has transcripts, retrieve them with a GET request against sessions/:id/transcripts, which returns a paginated array of entries. Each one carries the participant's ID and name, the language, the transcript text, plus start and end timestamps. Dial-in participants appear with no participant ID, labelled 'Phone conference' instead. Transcription also covers phone (PSTN) audio this way, so participants dialling in are captured in the same transcript as everyone joining by video.
Once a session has been transcribed, Digital Samba can generate a summary from that transcript, with speaker attribution, so the summary tells you who raised what rather than flattening the discussion into a single voice. Because each participant's audio runs through the pipeline on its own stream, that attribution comes from the signal path rather than being worked out after the fact from a single mixed recording, which is what speaker diarisation does. Treat the result as a condensed account of the discussion rather than a verbatim record.
Fetch summaries from a single endpoint, sessions/:id/summary. The first call kicks off generation and returns a status of IN_PROGRESS; poll the same endpoint until the status flips to READY, or handle FAILED, since a failed generation doesn't fire a webhook. Unlike transcripts, there's no separate txt or JSON export for summaries through the public API: you get the summary text in the response and store or display it yourself.
Treat both outputs as an aid rather than a verified record. Speech-to-text accuracy varies with accent, audio quality and language, and a wrong AI-generated summary of a legal consultation or a clinical conversation carries real consequences. Have someone check anything you're relying on before you treat it as an official record. Plan for retention from the start, too: transcripts and summaries are personal data once they exist, so you need a deletion policy as much as somewhere to store them. They're encrypted at rest on our side, but removing them when they're no longer needed, or when someone asks, is still your job. Four endpoints handle it: DELETE sessions/:id/transcripts, DELETE sessions/:id/summaries, and the room-scoped equivalents, DELETE rooms/:id/transcripts and DELETE rooms/:id/summaries.
The practical value here is architectural as much as functional: one API surface for both transcript and summary, one authentication model and one EU-based sub-processor handling the audio and text under our data processing agreement (DPA) rather than a separate contract for you to review. You're not stitching a bot into the call to take notes and then separately managing what that bot does with the recording afterwards.
Here's what a basic build looks like, step by step.
Create a room with transcription switched on. Only privacy is required on room creation; everything else is optional. transcription_enabled defaults to off and is gated by your plan, so send it explicitly:
transcription_store_enabled matters more than it looks. Leave it off and live captions still work in the call, but nothing gets saved, so sessions/:id/transcripts comes back empty and there's no transcript to summarise afterwards.
2. Embed the room with the SDK as usual. If you want moderators to start or stop transcription manually mid-call, expose the in-room controls; otherwise the auto-start setting handles it the moment the first participant joins.
3. Register a webhook for the events that actually matter. Don't build retrieval around session_ended: transcription and summarisation both keep processing after the session itself has ended, so a fetch triggered by session_ended can come back short or empty. Alongside participant and recording events, Digital Samba fires two events built specifically for this:
4. Retrieve the transcript when session_transcript_ready arrives.
For a single-file export, GET .../transcripts/export/?format=json returns the whole session as JSON. Leave format off, misspell it, or set it to anything else, and you get plain text back instead.
5. Retrieve the summary when session_summary_ready arrives, or poll sessions/:id/summary directly if you'd rather not wait on the webhook:
Build in two things from the start. A FAILED summary never fires a webhook, so a webhook-only integration will wait forever on the calls where generation fails; add a timeout or a fallback poll. And transcription isn't available in breakout rooms, so plan around that gap if your product uses them.
That's the whole loop: no guesswork beyond what's documented, and the two ready events save you polling on a timer to find out when something is done.
The differentiator that matters for regulated buyers is easy to state and easy to overlook until it bites: the audio, transcripts and summaries stay with that same EU-based sub-processor, under Digital Samba's data processing agreement, rather than being routed to a US-hosted LLM. There's a specific legal reason this matters, beyond compliance box-ticking. Under GDPR Chapter V, sending personal data (and meeting audio plainly qualifies) to a processor outside the EEA counts as an international transfer. Since the CJEU's 2020 Schrems II ruling, organisations relying on standard contractual clauses, the model contract terms normally used to legitimise such transfers, are expected to run a documented Transfer Impact Assessment of the destination country's surveillance regime before they can rely on those clauses. Keeping the whole pipeline inside the EEA sidesteps that assessment rather than requiring a defensible answer to it. If you want to see exactly who processes this data, the current sub-processor list is in Digital Samba's DPA.
There's a second route some vendors take instead. Since July 2023, the European Commission's adequacy decision for the EU-US Data Privacy Framework lets a certified US processor take personal data without a Transfer Impact Assessment (sometimes called a Transfer Risk Assessment) at all. It's a real option, but the decision is currently being challenged before the Court of Justice, so relying on it leaves you exposed to litigation you don't control. Processing that never leaves the EEA doesn't carry that risk.
For a product selling into telehealth, EdTech or legal customers, this often matters more than any feature comparison. Sending audio containing patient details, student records or privileged conversations to a US-hosted third party for 'smart summaries' can turn an attractive feature into a compliance liability the moment a customer's legal team asks where the audio went. Keeping transcription and summarisation inside the same EU data boundary as the call resolves that specific question, the international-transfer risk. It doesn't hand you the rest of your GDPR compliance for free.
You still need a lawful basis for recording and transcribing the call in the first place, which in most jurisdictions requires giving participants clear notice and, often, getting their consent before you start, regardless of where the processing happens afterwards. That obligation sits with you whether you use native transcription or a standalone notetaker bot, so build it into your consent flow from day one rather than after a customer asks about it.
One more regulation to keep on your radar: the EU AI Act's transparency rules for AI-generated content start applying from 2 August 2026, and they're directly relevant to AI-generated summaries like these. Check whether your deployment needs the output labelled as AI-generated.
Here's the trade-off, stated plainly. In end-to-end encrypted sessions, server-side transcription and summaries aren't available, and that's a structural consequence of what E2EE means: the server routes encrypted media between participants without ever holding the keys to decrypt it, so there's nothing for a server-side speech-to-text or summarisation process to read. Captions and transcription are explicitly disabled in E2EE-enabled rooms for exactly this reason.
That leaves a trade-off to make per use case rather than a bug to work around. A legal consultation or a sensitive HR conversation needs maximum confidentiality, so it calls for E2EE, and transcription simply isn't part of that session's feature set. A session that needs a searchable record and a summary is better served by standard transport encryption plus server-side processing within EU infrastructure. Building this choice explicitly into room configuration, rather than assuming one setting fits every session, is the difference between a platform that quietly breaks a feature and one that lets developers choose correctly.
This is an architectural point rather than a vendor comparison. A standalone notetaker bot, the kind that dials into your call as an extra participant purely to record and transcribe it, is a separate data processor sitting outside your platform's boundary. It has its own storage, retention policy, terms and security posture that you need to vet independently of the video platform you already trust. Keeping transcription native to the platform that hosts the call still involves a sub-processor for the AI work, but it's one vetted party under a DPA you already hold, rather than a fresh contract to find, read and negotiate yourself.
The wider pattern holds regardless of which specific notetaker product a team uses. Security researchers have flagged that these bots typically request calendar, audio and sometimes contact access, and send conversations to external servers under terms most organisations never review. University privacy offices make a similar point: bringing in an AI notetaker involves sharing the conversation with a third-party vendor you haven't necessarily vetted, on top of whatever agreement you already have with your video platform. The legal risk isn't hypothetical: a wave of US litigation filed in 2025 and 2026 alleges that some notetaker bots recorded conversations, and in at least one case used them, without full participant consent, a pattern one law firm has compared to an uninvited guest sitting in on a privileged conversation. None of this says whether any specific product is good or bad. It's a reason to weigh, case by case, whether adding a participant purely to record the call is worth the extra vendor relationship it introduces.
Put together, this gives you transcripts and AI-generated summaries retrievable through one EU-hosted API, with a webhook-driven flow that tells you when each artefact is ready instead of leaving you to poll, and a clear-eyed trade-off around encryption instead of a line that pretends the trade-off doesn't exist. If you're building this in, the transcription, webhooks and security documentation are the next stop, worth reading before you write the integration rather than after.
If you want help mapping this to your own product, or you'd like a walkthrough of the API, get in touch with the Digital Samba team through our website.
It's an API that converts the spoken audio of a video call into text, typically covering live captions during the call, a retrievable transcript afterwards, and sometimes an AI-generated summary built from that transcript.
Yes. Transcription can be started, stopped or set to auto-start via the REST API and SDK. Transcripts are retrievable through sessions/:id/transcripts, and AI-generated summaries are retrievable through sessions/:id/summary.
Yes. Summaries attribute points to the participant who made them, taken from the per-participant transcript rather than inferred from a mixed recording. Both the transcript and the summary are retrievable through the REST API.
Meeting audio is transcribed and summarised by an EU-based sub-processor under Digital Samba's DPA, rather than being routed to a separate US-hosted transcription or LLM service.
In most cases, yes. GDPR requires a lawful basis, and national rules on recording conversations vary: some EU member states treat participant consent as mandatory, others accept notice plus a legitimate interest. Check the position in the jurisdictions your customers operate in, and remember the obligation is yours as the controller, not your video provider's.
Yes. Both are deletable through the API, at the session level (DELETE sessions/:id/transcripts, DELETE sessions/:id/summaries) or the room level, and both are encrypted at rest while they're stored.
Both are supported. Poll the transcript and summary endpoints directly, or register a webhook for session_transcript_ready and session_summary_ready and trigger retrieval from those instead of guessing at timing. Avoid triggering retrieval from session_ended: both artefacts are usually still being generated at that point.
No. In E2EE sessions the server never holds the keys needed to decrypt media, so server-side transcription, captions and summaries are unavailable by design. It's a deliberate trade-off between maximum confidentiality and server-side AI features.
14 languages are currently supported: Bulgarian, Catalan, Danish, Dutch, English, Finnish, French, German, Italian, Portuguese, Romanian, Spanish, Swedish and Turkish, with more added as the underlying speech models are extended. Transcription also covers phone (PSTN) audio, not just browser-based participants.