The API For Meeting Bots: Recall.ai's Success with Svix Webhooks

Recall.ai provides a single API for meeting bots on every platform like Zoom, Google Meet, Microsoft Teams and more.

Recall.ai is growing very fast, going from $0 to $10m in annual recurring revenue in two years. They also power the meeting bots of some of the world's best companies and developers, including companies such as Instacart, Apollo.io, Honeybook, and Calendly.

We spoke with David Gu Co-Founder and CEO of Recall.ai about their experience using Svix over the last few years.

Webhooks are the most natural way for us to keep our customers up to date with the status of our bots. If we didn't have webhooks, our API would be awful.

Recall.ai customers require real-time API notifications

Meeting bots are dynamic and can trigger a variety of events. On the Recall.ai platform, an event will be triggered when a bot joins the call, is put into the waiting room, gets admitted, started recording, pausing recording, and leaving the call, to name a few.

There are a lot of asynchronous status updates, and Recall.ai's customers rely on these in order to build their integration. According to David webhooks are the most natural way for us to keep our customers up to date with the status of our bots.

David further explained that if we didn't have webhooks, our API would be awful. You can't really design this product without webhooks. It's just an integral part of how it should be consumed.

Rolling your own webhooks is a huge distraction and a major time sink

At David's previous company they built their own webhooks system, and it was a huge distraction and a major time sink. So when they started Recall.ai they turned to Svix to power their webhooks and have been using it ever since.

Webhooks have a surprising amount of hidden complexity. Like other pieces of infrastructure, building an initial version is easy, you can do it in five minutes. Though it starts getting really painful when you start operating at scale, or when things start going wrong.

David explained how similarly to the rest of the infrastructure products they use like a database or a web server, webhooks seem really easily initially, but they become difficult when operating in production environments, at scale, or when things go wrong.

He gave AWS RDS as an example: we use AWS RDS, and we pay AWS much more than what it costs them to run. We could probably set our own Postgres, it's not hard. Though we'll then need to implement backups, zero downtime major version updates, monitoring, etc. David concluded by saying you need to worry about all of these when operating in a production environment, and you don't want to be the one that rediscovers all of the foot guns.

One of David's goals when adopting Svix was to never have to think about webhooks ever again. A goal he has achieved with Svix.

It's about more than just reliability

When it comes to webhooks, reliability is key. A delayed or a missing notification about a bot joining a call can lead to severely degraded experience for Recall.ai's customers. They require low latency and reliable delivery and they get that from the Svix platform.

It turns out there are a lot of customer-facing dashboards you have to build for easy webhook operations.

Though another key part of Svix platform that Recall.ai really appreciate is the pre-built embeddable consumer application portal. David further explained that it turns out there are a lot of customer-facing dashboards you have to build for easy webhook operations. The pre-built application portal has proven very useful for Recall.ai's customers, and is popular with other Svix customers as well.

When building your own infrastructure you can't win, you can only lose

David summarized their approach to building Recall.ai's infrastructure as follows: with building your own infrastructure you can't win, you can only lose.

He further explained that with infrastructure if you do a really good job and you spend a lot of time becoming experts at that infrastructure piece, your customers get mad because you haven't built the features they have been looking for. If you do a bad job, and you've gotten even a tiny bit of insatiability, then your customers are mad because your product is unstable. David then added so at best, if you execute perfectly and efficiently on the infrastructure components of your company, you get neutral benefits. Customers don't notice and they're not mad at you.

With building your own infrastructure you can't win, you can only lose. If you do a really good job and spend a lot of time on it the rest of the product suffers. If you do a bad job you get instability. Either way, your customers are unhappy with the result.

David further explained that while they built a world-class engineering team at Recall.ai, they will only be able to spend at most 2% of their time and attention on the webhooks system as they have many other things to do. He was glad that he found Svix because you are really good engineers, and I know that 100% of your focus is on making sure we delivery a really good webhooks experience. We don't need to worry about it, and you already cover all of the error cases we would have learned the hard way.

Another concern raised by David was that even if we already have a working system, we would still get webhook related tickets from customers 2-3 times a month. and they would have to work on these because while these tickets delivery low product value people will be upset if they don't. With Svix, we just never get these tickets. It's not our problem, and we can focus on the unique things that make our customers happy.

I literally have not thought about webhooks for months. It's kind of magical actually. You have built an enormously stable, reliable, and predictable service.

Fast implementation that transparently scales

David was looking back to when they initially built the Svix integration: I think it was literally 10 minutes. I also really liked the pre-built customer facing portal, because building a polished UI experience is actually very time consuming.

The pre-built UI has improved a lot since Recall.ai first integrated it, and they've been getting all of the improvements without any additional work or effort on their end. Our customers get all the stuff they need, without us needing to put all the effort.

Performance and latency have been top-tier. We have weird usage patterns, for example at 9am millions of people get into their sales calls and daily standups, we send tens of thousands of events within a very short amount of time, and have never run into any issues with Svix.

When it comes to performance, Recall.ai has been using Svix to send bursts of tens of thousands of events within a short amount of time and have never experienced any reliability or latency problems. David mentioned that the only time we've ever needed to contact your support was when we hit the rate-limits on your lower tiers and wanted to upgrade..

The Svix support has been excellent and very helpful. Though the best support is when you don't need support, and that's been our experience with Svix. We are very happy about that.

The end result

Most important business interactions in the world right now are happening over video conferences. The average human speaks at 150 words per minute, and the average typing speed is 40 words per minute. This means that there's immensely more information transmitted through computers nowadays than ever before.

Additionally, as large language models (LLMs) made it trivial to analyze this data and get real value out of it, the use-cases for a tool like Recall.ai just keep on growing.

You've just got so much more data and such amazing capability to work with this data, that we just see hundreds of companies building really cool things. A lot of these real-time use-cases are just driven by webhooks under the hood.

Svix is proud to be powering the infrastructure of groundbreaking companies such as Recall.ai, and looking forward to partnering with them for many more years to come.

The biggest compliment you can pay an infrastructure provider is that after integrating them, you don't need think about them ever again. It's how I felt about Heroku, how I feel about AWS S3, and how I feel about Svix.