Native SDK Recording vs Third-Party Bot Services for Meeting Platforms

How each architecture works, and where each one breaks

The AI meeting assistant market stopped competing on whether it can transcribe a call. Every serious product does that now, with speaker labels and accuracy good enough for most business purposes. What separates one architecture from another in 2026 is a set of decisions that never appear in a demo: which jurisdiction the audio touches, whether the consent flow holds up in court, what the per-seat bill looks like once the user count climbs, and whether a visible bot changes how a sales call actually goes.

Two events reshaped that decision this year. Zoom opened RTMS to all developers on June 25, 2025, giving teams a way to pull live meeting media without a bot ever joining the call. Google followed with a Meet Media API in developer preview in April 2026, though it's not something anyone can ship on yet since it requires every participant to be enrolled in the preview. Meanwhile Recall.ai, the company that built its business on the bot model, raised a sizable Series B in September 2025, with more than 2,000 companies already building on its API. Betting against the bot model outright would be a mistake: too much capital and infrastructure has built up around it, and moving away from it now takes an actual reason, not just a preference for the newer thing.

Four factors decide which architecture fits a given team: where the data has to live, how exposed the product is to consent law, what the bill looks like once seat count climbs into the hundreds, and how much friction a visible bot adds to a call that matters. The rest of this piece works through each one.

A bot-based recorder joins the meeting as a visible participant, records through the platform's normal call experience, and ships that data out over a webhook and a media WebSocket. Stated that way, it sounds simple. In practice it breaks into six stages: authenticate, join, wait, capture, process, deliver. Every one of them has a failure mode that looks trivial in a demo and eats weeks of engineering time in production.

Take the waiting room. A bot that gets held there needs a policy: how long to wait before giving up, whether to retry the join, what to tell the user if admission never happens. None of that is a one-line fix, and teams that treat it as an edge case end up debugging silent failures months after launch.

Media format is another wall. Zoom sends H.264 video and PCM 16LE audio. Teams uses SILK and G.722 for audio, paired with H.264 video. That means separate decoding logic per platform, not a shared pipeline, and every new platform added to the roadmap becomes its own reverse-engineering project. The bot also occupies an actual seat and shows up in the participant list, and whoever runs it owns every reconnect, every scaling hiccup, every dropped stream.

Native SDK access skips the bot. The application just subscribes to a media feed. Zoom RTMS is the clearest case of this working at scale: it streams live per-participant audio, video, transcripts, screen share, and participant events over WebSockets, with SDKs in Node.js and Python and a Go SDK planned. It runs across Zoom Meetings, Webinars, the Video SDK, and Zoom Contact Center, and apps using it never appear as a tile in the meeting. RTMS also carries in-meeting notices telling participants what app is active, what it can see, and who added it, so consent is surfaced by the platform itself rather than bolted on after the fact by whoever built the integration.

Google's Meet Media API offers something comparable on paper, but as of April 2026 it's still developer preview only, and requiring every participant to be enrolled makes it unusable for anything beyond a controlled pilot. Microsoft Teams is in between: it supports application-hosted media bots that send and receive media over a socket-like API, but the participant model is closer to a bot than to a true native stream.

There's a middle path too. Recall.ai's Desktop Recording SDK records through an app installed on the user's own machine, capturing the same data as its Meeting Bot API without putting a bot in the roster, though it still requires a desktop install. Granola goes further, capturing audio at the operating system level rather than integrating with each meeting platform separately, which lets it work across Zoom, Teams, Meet, Slack huddles, and even in-person conversations without platform-specific configuration or admin permissions.

Bots work on all three major platforms today. Bot-free native streaming, at production scale, only exists on Zoom in 2026. That asymmetry runs through every section below.

Platform-by-platform constraints that determine what is even buildable

Zoom has the most complete developer surface of the three, and it's not close. It holds 55.91% of the video conferencing market and processes something like 3.3 trillion meeting minutes a year, which makes it the platform any recording strategy has to plan around first. Its Meeting SDK gives direct WebRTC-level media access, and its webhook system covers a broad range of event types. Starting March 2, 2026, any Meeting SDK app joining meetings outside its own account will need an OBF token, a ZAK token, or RTMS as an alternative path, a tightening that makes life harder for third-party bots specifically. RTMS remains the cleanest bot-free option at production scale anywhere this year. And the user base is already primed for recording: 87% of companies on Zoom subscribe to at least one paid feature, many explicitly for recording, so there's no need to convince anyone that recording belongs in the workflow.

Teams is a different animal. It handles roughly 2.7 billion meeting minutes a day across 320 million monthly active users and 8 million US companies, which is enormous scale, but the API surface hasn't kept pace. Microsoft Graph API has no real-time media support, so there's no direct path to live recording through it. Application-hosted bots exist, but building one means working through Azure Bot registration, OAuth flows, meeting permissions, and WebRTC setup, the most complex authentication chain of the three platforms by a wide margin. Recording and transcription also sit behind organizational policy controls, and consent flows have to line up with whatever regional rules apply. There's no RTMS equivalent for third parties on Teams in 2026, and nothing on the roadmap suggests one is close.

Google Meet is the least mature of the three, on both bots and APIs. It has more than 300 million monthly active users, but its strength sits in education and small business, not the enterprise recording volume Zoom and Teams see. There's no official bot API, so third-party bots join as plain WebRTC participants, which means whoever builds the integration has to maintain their own compatible WebRTC client and keep it working as Google changes things underneath them. The Meet Media API preview doesn't change that calculus yet. Recording itself is locked to paid Workspace tiers, Business Standard and up, and only 56% of Meet users are even on a paid plan.

A team that needs to cover Zoom, Teams, and Meet in 2026 cannot skip bot infrastructure for at least two of those three platforms. RTMS is real and production-ready, but it's a Zoom-only path, and pretending otherwise just delays the engineering work.

The UX cost of a visible bot, and when it tips a deal or a relationship

A bot joining a sales demo, a negotiation, or a candidate interview changes the room the second it appears. Someone stops mid-sentence to ask who just joined. The transcript keeps running fine, but whatever rapport existed before that interruption rarely comes back the same way.

Annoyance with visible "Notetaker" bots has become common enough that bot-free tools are picking up adoption specifically because they avoid it. How a product connects to a call is not a backend detail hidden from the user. It appears in every meeting: in the roster, in the awkward pause, in the question about who's recording.

The complaints are specific and recurring: users on longer calls report timestamps drifting off, and bots that drop out and rejoin mid-meeting, jarring for everyone still on the line. For healthcare, finance, and legal teams, a visible bot can be an outright non-starter, and the discomfort runs deeper than optics. To a sophisticated buyer, a bot in the roster reads as a signal about the vendor's compliance posture before any contract terms get discussed.

A handful of bot-free products have picked up real traction because of this. Fireflies launched a Desktop App in November 2025 that captures audio directly on the device across Zoom, Teams, Meet, Slack Huddles, WhatsApp, FaceTime, Aircall, Discord, and in-person conversations, with no bot in the lobby and no Notetaker name in the attendee list, on both Mac and Windows. Meetily takes the local-processing route entirely: open source under MIT, more than 30,000 GitHub stars, and past 560,000 downloads as of September 2026, with no cloud upload and nothing visible to other participants. Granola's OS-layer capture works the same way, across Zoom, Teams, Meet, Slack huddles, and in-person settings, without platform-specific setup, and it picked up SOC 2 Type 2 certification in July 2025. It's free on a Basic plan capped at 25 notes of history, then starts at $14 per user per month. Platform-native tools solve visibility differently by cutting the third-party bot out entirely: Zoom AI Companion and Microsoft Copilot (at $30 per user per month, per coworker.ai, for Teams meetings) do this, but only inside their own ecosystems.

None of this comes free. Desktop capture removes the roster friction, but it adds an install requirement and depends on the user's own device being present, awake, and configured correctly. That's a different kind of friction, not the absence of one.

Data residency and consent law exposure as procurement blockers

A number of US states require all-party consent for recording as of 2026, and whether a bot's visible presence in a meeting roster constitutes sufficient legal notice remains legally unsettled. That gap, between what feels like disclosure and what counts as disclosure, is where the legal exposure actually lives.

Two cases make the stakes concrete. Brewer v. Otter.ai, a federal class action reported in August 2025, alleges the company's bot recorded meetings and trained on the resulting transcripts without all-party consent; related class actions over Otter.ai's auto-join behavior consolidated in late 2025 and carried into 2026. Separately, Fireflies.ai was sued under Illinois' Biometric Information Privacy Act, reported by the National Law Review, over claims it collected voiceprints without explicit consent. Both cases share a structural detail: the recording bot was visible to everyone on the call, and the companies still ended up in court. Both suits proceeded despite the bot being visible to all participants, suggesting that roster visibility alone may not resolve the consent question.

Cross-border data handling adds another layer of pressure. Gartner's forecast projects more than 40% of AI-related data breaches by 2027 will come from cross-border generative AI misuse, which is pushing procurement teams toward tools that keep transcripts inside a known jurisdiction, or off the network altogether.

Vendors are adjusting accordingly. Recall.ai carries SOC 2, ISO 27001:2022, GDPR, CCPA, and HIPAA compliance. Granola, certified SOC 2 Type 2 in July 2025, takes a privacy-conscious approach to handling source audio. Meetily sidesteps the question almost entirely by keeping everything local with no cloud upload, which substantially reduces the data-exposure surface.

Zoom RTMS changes the residency conversation more structurally: the media stream goes straight to the developer's own infrastructure rather than routing through a third-party bot vendor's servers first. That's one fewer hop, and one fewer party holding a copy of the audio. For healthcare, finance, and legal teams, this compliance question is usually the first filter applied to any tool, not the last. Cost and interface only get evaluated once the architecture clears this bar, and teams that flip that order end up re-litigating the vendor choice six months in.

Per-seat cost at scale: where bot pricing compresses margin and when building pays

Cloud transcription sets the floor for everything else. Cloud transcription from providers like AWS Transcribe and Google Cloud Speech-to-Text sets a baseline cost, and every bot-API vendor's price sits on top of that in some form.

Recall.ai's pay-as-you-go pricing, as of August 2026, runs $0.50 an hour for the Meeting Bot API or the Desktop Recording SDK, plus $0.15 an hour if built-in transcription is used, plus $0.05 an hour for storage past the first seven free days, with the first five hours free and custom pricing on the Launch and Enterprise tiers. Speak AI prices differently, at $4 an hour for meeting transcription including API, MCP, and webhook access, or $20 per user per month on its Pro plan with a hosted player, library, and analytics dashboard bundled in.

Billing structure varies by vendor philosophy, and this matters more than it looks like on a pricing page. Recall.ai unbundles recording from transcription, so teams pick their own speech-to-text provider (AssemblyAI, Deepgram, Gladia, whichever fits), which means more control but more assembly work and a bill that shifts depending on which STT vendor gets chosen. Nylas Notetaker bundles recording, transcription, calendar sync, and summaries into one line item: simpler to account for, less room to swap components. Skribby undercuts both on raw per-hour price with flat pricing, which matters most for startups and solo developers running low volume where every dollar of infrastructure spend shows up on the P&L.

For teams that want to skip vendor billing entirely, there's a self-hosted lane. Vexa is open source and self-hostable (also available as hosted SaaS), so there's no per-hour vendor charge, but the full operational burden, scaling, uptime, patching, sits with whoever runs it. Meeting BaaS runs on token-based pricing with a self-hosted option and infrastructure based on another continent, which matters for teams with regional data residency requirements. Meetily is free and open source under MIT, transcribing locally on-device with no per-meeting charge at any volume.

Most teams evaluating this get the build-versus-buy math backwards. They assume owning the infrastructure saves money at scale, when the opposite is true below a fairly high bar. Building in-house means staffing a multi-engineer effort over an extended timeline, plus around 4 vCPU of compute per concurrent bot. Only above a high monthly recording volume, or once a team needs per-speaker media streams and in-meeting agents that off-the-shelf bots don't support, does owning the stack start to pay for itself. Below that line, buying wins outright: the engineering cost of building and maintaining bot infrastructure rarely clears the bar against a per-hour vendor fee.

Platform-native tools reset the math one more time. Zoom AI Companion comes bundled with a paid Zoom plan at no incremental per-recording cost, while Microsoft Copilot runs $30 per user per month for Teams-only coverage. Both are useful benchmarks when weighing what a third-party bot actually costs against the platform's own answer at the same headcount.

A decision framework for matching architecture to actual constraints

Start with coverage, not compliance, cost, or UX, because coverage decides what's even on the table. If the product has to work across Teams and Meet as well as Zoom in 2026, bot infrastructure is unavoidable for at least two of those three platforms. No native-SDK option currently replaces that need in full.

If the team operates in a regulated industry, or serves customers across multiple US states, run the compliance filter next, before anything else. Twelve states require all-party consent, and active litigation against Otter.ai and Fireflies.ai shows that consent has to be built explicitly into the product, not assumed from the fact that a bot is visible in the roster. A hard data residency requirement points toward self-hosted options like Vexa or Meeting BaaS, on-device tools like Meetily, Granola, or the Fireflies Desktop App, or a vendor with documented residency controls such as Recall.ai's compliance and data-handling settings. Where the location of a vendor's servers is itself the compliance concern, Zoom RTMS is worth weighing seriously, since it removes that server from the data's path.

Cost and UX matter, but they come second and third, not first. A team that clears the compliance bar with room to spare can then ask what a visible bot costs it in deal chemistry, and what per-seat pricing looks like once headcount triples. A team that can't clear the compliance bar doesn't get to ask those questions yet, and any vendor pitch that starts with price before addressing consent law is skipping a step that will resurface later, usually in front of a lawyer.