TL;DR: Creating Teams meetings programmatically means Microsoft Graph, which assumes every participant lives in your Microsoft tenant. That works well internally and becomes awkward for external users, multi-tenant products, and anyone needing meeting data outside Microsoft's cloud. A standalone meeting API avoids the tenant dependency entirely.
If your organisation runs on Microsoft 365, using Teams for programmatic meetings looks like the obvious choice. Often it is.
The complications appear when meetings need to involve people outside your tenant, when you are building a product rather than an internal tool, or when a customer asks where their meeting data lives and Microsoft’s answer does not satisfy them.
This guide covers what Microsoft Graph gives you, the three constraints that push teams elsewhere, and how a standalone meeting API compares.
Through Microsoft Graph, using the onlineMeeting resource. You authenticate against Microsoft Entra, call the create endpoint on behalf of a licensed user in your tenant, and receive a join URL. Every meeting is owned by a real user account, which is the detail that shapes everything else.
Microsoft’s documentation notes that the create online meeting API produces a standalone meeting not attached to any calendar event, so it does not appear on the organiser’s calendar unless you create it differently.
The tenant model is the defining characteristic. Meetings belong to licensed users. That is elegant for internal workflows, where everyone already has an account, and awkward the moment your users do not.
What are the limits on Microsoft Graph meetings?
Microsoft documents throttling across Graph, returning HTTP 429 with a suggested wait time when thresholds are exceeded. For meetings specifically, Microsoft support guidance indicates a ceiling in the region of 2,000 meetings per user per month on the Cloud Communications service. Confirm current figures against Microsoft's documentation before designing around them.
Graph applies service-specific throttling limits, and when a threshold is crossed it returns 429 with a retry hint. Microsoft’s own support answers describe a limit around 2,000 meetings per user per month.
That is generous for internal use and restrictive for a platform. If you provision meetings for thousands of end users, you are distributing load across licensed accounts you must also pay for, which turns a technical limit into a licensing cost.
Convay’s documented model is different in kind: 10 concurrent active meetings per user, with no documented monthly creation ceiling. As always, the question is not which number is bigger but which shape matches how your product creates meetings.
When is Teams the wrong fit?
When your participants are not in your tenant, when you are building a multi-tenant product where every customer would need their own Microsoft licensing, or when meeting data must stay outside Microsoft's cloud for sovereignty reasons. Each is structural rather than a feature gap.
- External participants: guests can join, but the model assumes a tenant, and permissions get complicated at the edges
- Multi-tenant products: your customers would each need Microsoft licensing, which is rarely a viable product requirement
- Licensing cost at scale: meetings are owned by licensed users, so provisioning capacity means buying seats
- Sovereignty: Microsoft is US-headquartered, so CLOUD Act exposure persists regardless of the region hosting the data
- No self-hosting: there is no path to running the meeting service inside infrastructure you control
To be fair to Microsoft, none of these are defects. Graph is built to orchestrate Microsoft 365, and it does that better than any alternative. The mismatch appears when you ask it to serve people who are not Microsoft 365 users.
A standalone meeting API inverts the assumption. Participants need no account with anyone, join links are issued per person, and for regulated buyers the platform can run on your own infrastructure under your own jurisdiction.
If your meetings are internal and your organisation already runs Microsoft 365, stay with Graph. The integration is tighter than anything a third party can offer.
Frequently Asked Questions
Through Microsoft Graph, using the onlineMeeting resource. You authenticate against Microsoft Entra, call the create endpoint on behalf of a licensed user in your tenant, and receive a join URL. Meetings created this way are standalone and do not appear on the organiser’s calendar by default.
Microsoft applies service-specific throttling across Graph and returns HTTP 429 with a suggested wait time when thresholds are exceeded. Support guidance indicates a ceiling around 2,000 meetings per user per month on the Cloud Communications service. Verify current limits in Microsoft’s documentation before designing around them.
Yes, guests can join, but the model assumes meetings belong to licensed users in your tenant. Permissions and behaviour become more complex at the edges, which is why products serving users outside a single organisation often prefer a standalone meeting API with no tenant dependency.
No. Teams is a cloud service, so meeting data is processed on Microsoft infrastructure. Organisations that must keep meeting data inside infrastructure they control, typically government, defence, or certain financial institutions, need a platform offering on-premise deployment.
Use Graph when meetings are internal and your organisation already runs Microsoft 365, because the integration is tighter than any third party can match. Use a standalone meeting API when participants sit outside your tenant, when you are building a multi-tenant product, or when sovereignty rules require self-hosting.
Related guides
- Start with the complete video conferencing API guide
- Compare the Zoom Meeting API alternative analysis
- See when self-hosting becomes the requirement
- Score options with an evaluation framework
Building for users outside your tenant?
A standalone meeting API removes the tenant and licensing dependency entirely. We will walk through the endpoints and, if sovereignty is a requirement, the on-premise deployment path.
