There’s a sentence buried in Microsoft’s own Graph throttling guidance that decides this whole debate for you at the top end: “Solutions that need to extract a large volume of data from Microsoft Graph should use Microsoft Graph Data Connect instead of the Microsoft Graph REST APIs.” (Microsoft Graph throttling guidance.) That’s not a footnote. It’s Microsoft telling you that past a certain scale, the API is the wrong tool and there is a sanctioned bulk path instead.
But “past a certain scale” is doing a lot of work in that sentence, and neither option is universally right. We build governance tooling that scans real Microsoft 365 tenants, and we’ve run into the exact wall the doc is warning about. Here’s the honest practitioner comparison: what each path actually is, where each wins, and how to choose.
Two fundamentally different models
API scanning means calling the Microsoft Graph REST endpoints — /sites, /drives, /permissions, /users/delta — enumerating your tenant object by object, page by page, over HTTPS. You authenticate an app registration, request least-privilege scopes, and pull. Setup is minutes. You get exactly the fields you ask for, in near-real-time, and you can start today.
Microsoft Graph Data Connect (MGDC) is a bulk export pipeline, not an API. Instead of you pulling objects, Microsoft copies whole datasets — as JSON or Parquet — into your Azure storage (Azure Data Lake Gen2, Blob, or Fabric OneLake), orchestrated through Azure Synapse or Azure Data Factory. You then query that landed data at rest. Per the Data Connect overview, standing it up means enabling MGDC on the tenant, registering an Entra app, provisioning Azure Storage, and wiring a Synapse/Data Factory/Fabric pipeline. It’s an infrastructure project, not an API call.
Crucially, the two paths don’t even see the same catalog. MGDC exposes specific datasets, and for governance the relevant ones are SharePointSites_v1, SharePointPermissions_v1, SharePointGroups_v1, and SharePointFiles_v1 (Data Connect datasets). If the signal you need isn’t a published dataset, MGDC can’t give it to you at all — and that’s a real constraint, not a detail.
Where API scanning hits the wall
We’ve written before about what scanning ~1M files against Graph actually looks like, so we’ll compress it here. The short version: file enumeration is cheap and latency-bound. The killer is the permissions phase. Reading sharing permissions is the most expensive operation class in SharePoint’s throttling model, and on a large tenant it’s the permissions scan — not the file count — that turns a job from hours into days. Throttled requests still burn your quota, so you can’t retry your way out; you honor Retry-After and wait.
And the obvious escape — register more apps, multiply the budget — is a trap Microsoft closes deliberately. The tenant-wide bucket is capped at a small multiple of the per-app budget at every license tier, and the throttling docs name “creating multiple AppIDs for the same application” as an abuse pattern that can get your app blocked, with the notice landing in the customer’s Message Center. For a governance vendor, that’s the end of the relationship.
That’s the wall the throttling doc is pointing at. Above a few million high-cost objects — permissions across a large estate being the canonical case — API scanning stops being the right tool for a first, complete baseline.
Where each one actually wins
Neither path dominates. They trade cleanly:
API scanning wins on freshness. Delta query — Microsoft’s change-tracking model — lets you ask only “what changed since last time” against sites, groups, users, and driveItems. After the expensive first scan, steady-state sync is near-real-time and cheap, because you’re moving deltas, not the whole tenant. Delta is a pull model you can run every few minutes; the throttling doc explicitly steers you toward it to avoid throttling. If your governance question is “what changed on this high-risk site this morning,” the API is the answer and MGDC isn’t.
API scanning wins on setup and specificity. No Azure landing zone, no Synapse pipeline, no dataset that has to exist. You point an app registration at the tenant and go, pulling precisely the fields you need.
MGDC wins on sanctioned bulk at massive scale. It extracts in bulk without being subject to Graph throttling limits — that’s the entire point. For a first full baseline of a very large estate, or a periodic full re-materialization, it does in a batch run what would take an API scanner days of careful backoff, and it does it on the path Microsoft blesses for exactly this.
MGDC wins on governance posture — this is the underrated part. MGDC is not “an app with wide scopes.” It requires explicit admin approval per pipeline: an authorized admin approves each data extraction request, in the Microsoft 365 admin center or via PowerShell, before any data moves. Data lands in your Azure tenant under your controls, and the consent is granular and auditable rather than a standing Graph permission that quietly persists. For a security team that has to answer “who approved this bulk export of SharePoint permissions, and when,” MGDC has a better answer by construction. (Consumption is billed through your Azure subscription — see Microsoft’s Data Connect pricing for current rates; we won’t quote numbers that move.)
The trade-offs nobody puts on the slide
- Latency & freshness. API delta is near-real-time. MGDC is batch — you schedule a pipeline; you get a point-in-time snapshot, not a live feed. A permissions dataset extracted Tuesday says nothing about Wednesday’s oversharing until you run it again.
- Cost shape. API scanning is “free” in dollars but paid in throttling budget and engineering time on retry logic. MGDC is metered Azure consumption plus the standing cost of a data platform — real money and real infrastructure, but predictable and off the throttling clock.
- Operational surface. API scanning is one app registration. MGDC is app registration plus storage plus Synapse/Fabric plus per-pipeline admin approvals — more to secure, more to explain, more to break.
- Catalog coverage. The API can reach anything Graph models. MGDC reaches the published datasets and no more.
How to actually choose
A rough decision rule that’s held up for us:
- Continuous, change-driven governance signal? API + delta. Freshness is the whole game, and steady-state delta is cheap.
- First full baseline of a very large estate, or a periodic full re-materialization, where a complete permissions picture matters more than minutes-fresh? MGDC. This is precisely the case the throttling doc is written for.
- Need a bulk export that has to be demonstrably sanctioned — a named admin approving each extraction, data landing in your own governed Azure tenant? MGDC, for the consent posture alone.
- Small-to-mid tenant, or a targeted question about a handful of high-reach sites? API scanning, every time — MGDC’s setup cost isn’t worth it.
Many mature governance programs end up running both: MGDC for the heavy periodic baseline, delta-driven API scanning for freshness on top. They’re complements more often than they’re competitors.
The thing that matters whichever path you pick
Here’s the part that outlives the API-vs-bulk question. Neither path is worth anything if it reports its blind spots as zeros. An MGDC pipeline that a per-dataset approval never covered, or an API scan that got throttled off 130 of 650 sites, produces the same dangerous artifact: a confident, complete-looking number that’s actually partial. Whichever path you choose, the deliverable that matters is effective reach and honest coverage — what can actually be accessed, resolved through group nesting and claim principals, with an explicit statement of what you couldn’t read. Raw object counts flatter both models and inform neither. Bulk vs. API is a transport decision. Honest coverage is the governance decision.
Polaris Governance Hub runs inside your own Microsoft 365 tenant and reports effective reach with coverage stated as loudly as findings — never a partial scan rounded up to a confident zero. We’re taking a small number of design partners. See what Copilot can reach in your estate.