The Microsoft Graph API is a shared multi-tenant resource. Microsoft enforces strict service limits and throttling to prevent any single user from degrading performance for others. For Outlook mail operations, these limits vary by mailbox type and region but typically fall between 4 and 10 requests per second. When a web-based Office.js add-in tries to draft a campaign, each draft creation, recipient addition, and attachment reference requires a separate API call.
What throttling looks like in practice
A single personalized email with three recipients and one file attachment generates multiple Graph API calls before it is ready to send. Creating the draft message is one call. Adding each recipient individually is a separate call. Attaching a file requires uploading it through the API, which means chunking the data into multiple HTTP requests. A campaign of 500 personalized emails can easily generate thousands of API calls, all competing for the same budget of 4 to 10 requests per second.
When the limit is exceeded, Graph returns an HTTP 429 response with a Retry-After header instructing the client to wait before retrying. The add-in backs off, waits, and tries again. For a large campaign, this back-and-forth extends execution from minutes to hours. Some recipients get drafted quickly. Others sit in a retry queue. The campaign becomes unpredictable.
Beyond throttling, the Graph API also enforces daily recipient limits and message rate caps that vary by subscription level. These limits are documented in Microsoft's Exchange Online limits page, which specifies 10,000 recipients per day and 30 messages per minute as standard boundaries. A web add-in operating through Graph must respect all of these simultaneously.
How VSTO sidesteps the entire API layer
A VSTO add-in does not use the Graph API at all. It runs inside the Outlook process on the local machine and communicates directly with the Outlook Object Model through COM. This is the same interface that Outlook itself uses to manage mail items internally.
When FlowDrafts creates a draft, it calls the Outlook Object Model locally. When it adds a recipient, it sets a MAPI property on the local mail item. When it attaches a file, it tells Outlook to pull the file from the local drive. There are no HTTP requests, no API authentication, no rate limit counters to manage. The add-in operates at the speed of the local CPU and disk.
Bypass API Throttling
Draft hundreds of personalized emails at local CPU speed, not API speed.
This difference is most visible with large attachments. Through the Graph API, attaching a multi-megabyte PDF requires uploading it in chunks over the network. Through VSTO, the same file attaches from the local disk in a fraction of a second. There is no bandwidth cost and no API budget consumed.
FlowDrafts also manages Exchange delivery locally. Every few emails, the add-in checks the Outbox. If more than 15 items are pending, it pauses until the queue clears. This prevents Exchange from being overwhelmed and keeps Outlook responsive. The backpressure logic runs in local code, not through API responses.
What the architecture comparison looks like
| Capability | Web Add-in (Graph API) | VSTO Add-in (FlowDrafts) |
|---|---|---|
| API calls per email | 10+ calls per draft | 0 (local COM calls) |
| Requests per second | 4-10 hard limit | No throttling (local COM) |
| Daily recipient cap | 10,000 per day | Exchange limit only |
| Large attachments | Chunked HTTP upload | Local file system attach |
| 429 errors | Common at scale | None (no cloud API) |
| Retry + backoff | Required when throttled | Not needed |
| Outbox flow control | Depends on Graph queue | Local backpressure |
| Data sovereignty | Data passes through cloud | 100% local processing |
The Graph API was designed for individual mailbox operations performed by a single user through Outlook or a custom application. Microsoft's throttling documentation states explicitly that the limits exist to protect shared infrastructure from excessive demand. A VSTO add-in was designed for the opposite scenario: high-volume, local-first execution where performance cannot be sacrificed to multi-tenant fairness constraints. For firms sending large campaigns regularly, the choice between the two architectures determines whether email automation works reliably or fails under load.