SharePoint API access requests: what you are actually approving
Last updated:
When a SharePoint Framework package needs to call an API beyond SharePoint itself, it cannot just do it. It declares the request in its manifest, and the request lands in SharePoint admin center → Advanced → API access as pending until an administrator approves it. Nothing happens until you press the button.
Two things decide how much you are giving away, and both are on that screen: the resource (whose API) and the scope (what it may do there). Microsoft Graph — Sites.Read.All and Contoso — Widgets.Read look identical in shape and are worlds apart in consequence: the first opens every SharePoint site in the tenant to that application, the second grants nothing over your data at all.
Approvals here are also tenant-wide, not per site — and they apply to any SPFx solution that asks for the same scope, not only the one you were thinking about.
How to read a request
| Field | What it tells you |
|---|---|
| Resource | Whose API is being called. Microsoft Graph means your Microsoft 365 data. A vendor's own name means the vendor's own service. |
| Scope | The permission itself. Read the verb (Read, ReadWrite) and the breadth (.All means across the tenant, not just what the user can see). |
| Package | Which deployed solution asked for it. If you do not recognise it, find out before approving. |
The single most useful habit: read the suffix. Sites.Read.All is not a slightly bigger version of Sites.Read — the .All means the permission applies across the whole tenant, and combined with an application permission it stops being limited by who is looking at the page.
Delegated vs application permissions
This is the distinction that matters most and the one vendors are least clear about.
| Delegated | Application (app-only) | |
|---|---|---|
| Acts as | The signed-in user | The application itself, with no user involved |
| Limited by user permissions | Yes — a user who cannot open a list will not see it through the component either | No — it can reach everything the scope allows |
| Works when nobody is looking | No | Yes, including background jobs |
| Risk if the vendor is breached | Bounded by each user's own access | Bounded only by the scope |
SharePoint Framework packages request delegated permissions through this screen, which is a meaningful safety property: the component inherits the limits of whoever is looking at the page. Application permissions exist, but they are granted to an Entra ID app directly rather than through the SharePoint API access page — so if a vendor asks you to consent to something in the Entra portal instead of here, that is worth a question.
Which requests should make you stop
- Any
.AllMicrosoft Graph scope for a component whose job is to display something on one page. A tracker does not need tenant-wide read of every site. ReadWritewhereReadwould do. Ask the vendor to justify the write, in writing.- Directory or user scopes (
User.Read.All,Directory.Read.All) for a component that is not an org chart or a people directory. - Mail, Calendars or Files scopes in anything that is not explicitly a mail, calendar or files product.
- A request you cannot map to a feature. If nobody can name the feature that needs it, it does not get approved.
The healthy pattern is the opposite: a package that requests one narrow scope against the vendor's own API, and reads your list data in the browser with the user's own session — so there is no tenant-wide grant to give and nothing for you to revoke later beyond the package itself. That is the model Sharelio uses, and the full manifest is published at sharelio.com/security.
Revoking
- SharePoint admin center → Advanced → API access.
- Find the approved permission, select it, choose Remove.
- If you also want the package gone, delete it from the App Catalog. Removing the permission alone leaves the package deployed but unable to call the API.
Revoking is immediate and does not touch your content: permissions govern access, not data. Reviewing this page periodically is worth putting in the calendar — approvals accumulate quietly, and packages that were retired years ago sometimes leave their grants behind.
Frequently asked questions
Does approving a request give the vendor access to our tenant?
Only if the resource is Microsoft Graph or another Microsoft API holding your data. If the resource is the vendor's own API, approving lets the web part obtain a token addressed to that vendor and nothing more — it grants no access to your sites, files, mail or directory. The resource column is what decides this, not the vendor's marketing.
Is this the same as granting admin consent in Entra ID?
No, and the difference matters. Approving here is scoped to what SharePoint Framework solutions may request and is handled by the SharePoint Administrator role. Granting admin consent to an application in the Entra portal is a broader action, needs Global Administrator or Privileged Role Administrator, and is not something a SPFx package can make you do.
Can we approve a permission for one department only?
No. API access approvals are tenant-wide. If you need to limit who can use a component, do it with site permissions — control who can place the web part and who can reach the sites where it lives — rather than expecting the permission grant to be scoped.
A package we deployed suddenly has a new pending request. Why?
Because a new version asked for it. This is a feature, not a fault: a package cannot quietly acquire permissions in an update. The new request sits pending, without effect, until an administrator approves it — which is your opportunity to ask the vendor what changed.