TL;DR: A video meeting API manages the meeting as an object with a lifecycle: created, scheduled, joined, ended. Most integration bugs come from ignoring that lifecycle, particularly forgetting to end sessions and mishandling timezones on scheduled meetings. Model the meeting in your own database against your own records, and the rest follows.
Teams integrating a video meeting API usually focus on creating meetings. Creation is the easy half.
The problems arrive later: sessions that stay open for weeks because nothing closed them, meetings that exist an hour off for half the participants, and no way to answer who attended because everyone shared one link.
All three are lifecycle problems. This guide treats the meeting as an object with states, which is the mental model that prevents them.
A video meeting API lets your application create, schedule, join, and end video meetings programmatically. It treats a meeting as a resource with an identifier and a state, so your system can attach meetings to bookings, courses, or tickets and manage them alongside your own records.
The distinction from a media SDK matters here. A meeting API is concerned with the session as an entity, not with rendering video. You receive identifiers and join URLs, and your users enter the meeting through them.
That makes it a natural fit anywhere meetings hang off something else you already model: an appointment, a class, a consultation, a support escalation.
What does the meeting lifecycle look like?
Four stages: authenticate to obtain a token, create the meeting either instantly or scheduled for later, distribute join links to participants, and end the session when it is finished. Each stage maps to an endpoint, and skipping the last one is the most common production mistake.
Working against Convay’s Meeting API, a scheduled meeting is created like this.
POST /services/vcmeetingsettings/api-user/schedule-meeting
Authorization: Bearer <accessToken>
{
"meeting_title": "Cardiology follow-up",
"start_time": "1701060600000",
"end_time": "1701064200000",
"timezone": "Asia/Dhaka",
"meeting_description": "Post-operative review"
}Times are epoch milliseconds with an explicit timezone. This is where a surprising share of bugs live. Store the timezone alongside the timestamp in your own database, and never derive it from the server’s locale, because that breaks the moment you have users in two countries.
The API validates sensibly, rejecting a start time after the end time, an empty title, or a start time in the past. Surface those errors to whoever booked the meeting rather than logging them silently.
Ending sessions is the stage teams forget. An end endpoint exists precisely so scheduled events can be cleaned up automatically once their window passes. Sessions left open are an access surface nobody is watching.
How should you model meetings in your own system?
Store the meeting identifier against the record it belongs to, along with the scheduled window, its timezone, the per-user join links you issued, and the current state. That single table answers most support questions and makes automated cleanup straightforward.
- Meeting identifier, linked to the booking, class, or ticket it serves
- Scheduled start and end, stored with the timezone rather than converted
- Per-user join links, so you know who was issued access and can revoke individually
- State: scheduled, active, ended, cancelled, updated by your own jobs
- Host account used, which matters when you distribute load across accounts to respect concurrency limits
That last row deserves attention if you run at volume. Convay documents a limit of 10 active meetings per user simultaneously, so a busy hour on a single host account will hit a ceiling. Tracking which account owns which meeting lets you distribute deliberately rather than discovering the limit in production.
Per-user links are worth the small extra effort. One shared URL gives you no attendance record and no ability to revoke access for a single person. The website integration guide covers the distribution pattern in detail.
Frequently Asked Questions
A video meeting API lets your application create, schedule, join, and end video meetings programmatically. It treats each meeting as a resource with an identifier and a state, so your system can attach meetings to bookings, courses, or support tickets and manage them alongside your own records.
Call the schedule endpoint from your backend with a title, start and end times, and a timezone. Times are typically epoch milliseconds. Store the returned meeting identifier against your own record, then generate and deliver per-user join links ahead of the session.
Almost always a timezone handling error. Store the timezone explicitly alongside the timestamp rather than relying on the server locale, which breaks as soon as you have users in more than one country. Pass the timezone on every scheduling request instead of assuming a default.
Yes, and it is the step most often skipped. Sessions left open remain joinable and count toward concurrency limits. Run a scheduled job that calls the end endpoint once a meeting’s window has passed, so cleanup does not depend on a person remembering.
It depends on the platform’s limit model. Convay documents 10 active meetings per user simultaneously, so high-volume systems distribute meetings across multiple host accounts. Other platforms cap the creation rate per day instead, which requires queuing rather than account distribution.
Related guides
- Start with the complete video conferencing API guide
- See the website integration pattern
- Understand how usage drives cost
- Compare limit models across platforms
Attaching meetings to bookings or classes?
We will walk through the lifecycle endpoints, the scheduling payload, and how to distribute meetings across host accounts so concurrency limits never surprise you.
