TL;DR: In-app video calling means the call happens without the user leaving your product. It suits on-demand conversation between people who are already interacting, such as marketplaces, telehealth, and support. It is the wrong pattern for scheduled meetings, where a join link is simpler, cheaper, and works everywhere.
In-app video calling is the most demanding pattern in this category, and it is regularly chosen by teams who did not need it.
The appeal is obvious. Users never leave your product, the experience is entirely yours, and it feels like the premium option. The cost is a call interface you own on every platform, forever.
This guide covers what in-app calling requires architecturally, which use cases genuinely justify it, and how to tell whether yours is one of them.
An in-app video calling API provides the infrastructure and client libraries to run video calls entirely inside your own application, with no redirect to a browser or external app. It typically includes call signalling, ringing and answering states, and push notification support so a user can be called when the app is closed.
The distinguishing feature is the call state machine. Scheduled meetings do not ring. In-app calling does, and that changes the architecture substantially.
You need to represent calling, ringing, answered, declined, missed, and ended. You need push notifications to wake a device. On mobile you need integration with the operating system’s native calling interface so an incoming call behaves like a real one. None of that exists in a meeting API, because meetings do not ring.
Which use cases justify in-app calling?
Use cases where the call is spontaneous rather than scheduled, and where the two parties are already interacting inside your product. Marketplaces, dating apps, on-demand telehealth, field service, and in-product support all qualify. Anything with a calendar invite generally does not.
| Use case | Call is | Right pattern |
|---|---|---|
| Marketplace buyer and seller | Spontaneous | In-app |
| On-demand doctor consultation | Spontaneous | In-app |
| Booked clinic appointment | Scheduled | Meeting API |
| University lecture | Scheduled | Meeting API |
| Government committee session | Scheduled | Meeting API |
The test is whether a calendar entry exists. If the participants agreed a time in advance, they are willing to open a link, and everything the ringing architecture provides is wasted effort.
Convay serves the scheduled column. It is a meeting API without ringing, presence, or in-app call states, so it is the wrong tool for a marketplace and a good fit for a classroom or a committee. Being explicit about that is more useful than claiming to cover both.
What does in-app calling cost you?
Three costs are consistently underestimated.
The call state machine. Ringing, declining, missing, and reconnecting all need handling on both sides, including the case where one party’s app is killed mid-ring.
Push notification reliability. A video call that does not ring is a broken feature, and push delivery is not guaranteed. This is a genuinely hard distributed systems problem, not a configuration step.
Permanent interface ownership. Your call interface must keep working across operating system updates, new device form factors, and browser changes, indefinitely.
If those costs are justified by your product, in-app calling is worth it. If you are choosing it because it feels more professional than a join link, it is not. The build-vs-buy guide works through the trade properly.
Frequently Asked Questions
It provides the infrastructure and client libraries to run video calls entirely inside your own application, with no redirect to a browser or external app. It typically includes call signalling, ringing and answering states, and push notification support so users can be called when the app is closed.
When calls are spontaneous rather than scheduled and both parties are already interacting inside your product, such as marketplaces, on-demand telehealth, or in-product support. If a calendar invite exists, participants will happily open a link and the ringing architecture adds no value.
In-app calling includes a call state machine with ringing, answering, declining, and missed calls, plus push notifications to wake a device. A meeting API creates a session and returns a join URL. Meetings do not ring, which is why they need none of that machinery.
Because delivery is not guaranteed and a call that fails to ring is a broken feature. You must handle delayed delivery, devices in battery saver mode, and apps killed by the operating system, then integrate with native calling interfaces so incoming calls behave like real ones.
You can create a meeting instantly and send the link, but there is no ringing, so the other person only joins if they happen to see the notification. For genuinely spontaneous calls between users, an in-app calling SDK with proper call states is the correct tool.
Related guides
- Start with the complete video conferencing API guide
- Work through the build-vs-buy decision
- See the web and mobile platform differences
- Understand the scheduled meeting lifecycle
Are your calls scheduled rather than spontaneous?
If a calendar entry exists, you can skip the call state machine entirely. We will show you the meeting lifecycle endpoints and what they remove from your roadmap.
