Every Microsoft Teams bot limit, in one table

Microsoft publishes the ceilings that govern a Teams bot across half a dozen pages: the rate-limit tables live in the bot documentation, message size in the formatting guide, manifest field lengths in the app manifest schema, member paging in the context APIs, and the org-level caps (team sizes, channel counts) in the Teams admin limits reference. This page pulls the documented numbers into one place, quoted exactly, with the source next to every row.

The limits interact more than the scattered docs suggest. A broadcast that respects the per-thread send window of 7 operations per second can still be throttled by the global ceiling of 50 requests per second per app per tenant. A message that is fine at 60 KB sails past the recommended 80 KB working ceiling once mentions and reactions are counted in UTF-16, and dies at the 100 KB cap with 413 MessageSizeTooBig. An invoke handler that answers in six seconds does not degrade gracefully - Teams retried it twice, told the user "Unable to reach the app", and threw your late answer away. Knowing the numbers before designing the send path is cheaper than discovering them from 429 Throttled responses in production.

Microsoft warns that "the exact values of rate limits are subject to change" and that the published figures "are for estimation only," so treat these tables as design targets rather than contractual guarantees, and implement backoff regardless of how much headroom you believe you have - the handling contract for each ceiling links to the matching entry in the Teams error reference. Each section intro links the error you receive when its ceiling is crossed, and every row cites the Microsoft Learn page it was read from. Everything below is quoted from Microsoft Learn as of the verification date; anything Microsoft does not document - including several numbers that circulate in forum answers - is deliberately not listed here.

The per-bot-per-thread limit "controls the traffic that a agent is allowed to generate in a single conversation," where a conversation is "1:1 between agent and user, a group chat, or a channel in a team." One message to each of a thousand users touches a thousand threads, so "if the application sends one agent message to each user, the thread limit doesn't throttle" - broadcasts are governed by the global ceiling in the next section instead. Exceeding any window returns 429 Throttled with a Retry-After header. Note the docs' caveat that service-level message splitting "results in higher than expected RPS": one long message can count as several operations.

Two more budgets sit above the per-bot table. The per-thread limit for all bots "controls the traffic that all agents are allowed to generate across a single conversation" - a busy channel with several installed bots shares one pool, so your bot can be throttled by a neighbor's chatter. Above that, "the global limit per app per tenant is 50 Requests Per Second (RPS)," the ceiling that actually governs broadcast jobs. The documentation also fixes the retry contract: alongside 429, "error codes 412, 502, and 504 must also be retried" - the handling recipes are in the 412 and 502 entries.

The bot message ceiling is documented in the message-formatting guide, not the rate-limit page, and it is bigger than the old 28 KB folklore: 100 KB, with an explicit engineering margin. Because the measurement covers the serialized activity - "the message itself (text, image links, etc.), @-mentions, and reactions encoded as UTF-16" - the visible text underestimates the real payload. Overflow is rejected with 413 MessageSizeTooBig, which is documented as non-retryable: the payload must shrink. Machine-generated Adaptive Cards are the usual offender; cap list lengths at generation time.

Bot-sent cards live inside the 100 KB activity budget above - there is no separate documented card cap for bots. Incoming webhooks are the surface with the famous 28 KB limit, and they carry their own rate limit that has nothing to do with the bot tables. Formatting support is uneven across surfaces and platforms (desktop, iOS, Android), so a card that renders on desktop can degrade on mobile; the cross-platform tables in the formatting guide are worth checking before shipping markdown-heavy messages. Payloads that violate schema expectations fail with 400 Bad Argument rather than a size error.

Invoke-style interactions run on a hard clock. For message-extension action commands and dialog submits, "your app has five seconds to respond to the invoke message"; miss it and "the Teams client retries the request twice before it sends an error message Unable to reach the app," and "if the bot replies after the timeout, the response is ignored" - the failure anatomy is in the Unable to reach the app entry. Regular message activities are more forgiving, but a slow endpoint still produces redelivery, duplicate replies, and eventually the silent-bot behavior dissected in Teams bot not responding; endpoint-side failures surface as 502 bot returned an error.

The Teams app manifest JSON schema enforces hard maximum lengths, and the Developer Portal or upload validation rejects packages that exceed them - a common cause of "app cannot be uploaded" during deployment, distinct from the runtime 401 BotNotRegistered that follows a botId mismatch inside an accepted manifest. The values below are read from the published schema (v1.19); the manifest release notes record one change since: the bot command limit was "increased from 10 to 12" in schema v1.24. Manifest mechanics and the botId pitfall are cause 1 in Teams bot not responding.

Roster fetches are both paged and rate-limited, and the two interact: a team of 20,000 members at the maximum page size of 500 is 40 calls, comfortably inside the read windows above, but the same fetch at page size 50 makes 400 calls and needs pacing. Microsoft is blunt about the legacy path: "Don't use non-paginated member retrieval in teams and channels. For large rosters, non-paginated calls can be incomplete or throttled" - throttled meaning 429. Member queries in conversations the bot has been removed from fail with 403 BotNotInConversationRoster.

Proactive messages - anything sent outside a reply to a user - run under structural constraints rather than numeric ones. The app must already be installed where the message lands; targeting a user by Entra ID works only in personal scope, and without the personal installation the send fails with 403 ForbiddenOperationException. Users who block or uninstall the bot answer with 403 MessageWritesBlocked, and stale references produce 404 ConversationNotFound. The serviceUrl rules matter across clouds: hardcode the public host and GCC tenants fail with 403 InvalidBotApiHost.

These are Teams-wide limits from the admin documentation rather than bot-API limits, but they bound what a bot can do: how many people a channel post can reach, how many members a roster fetch can return, how many channels an enumeration can yield. The mention restriction in very large teams is easy to miss - a bot that @mentions the team in a 12,000-member org fails where the same code worked in a smaller one, usually surfacing as 400 Bad Argument on the mention entity or as a silently absent notification.