Start here: Graph and REST from outside SharePoint
For developers who call Microsoft Graph or SharePoint REST from scripts, services and Azure Functions rather than from a page in SharePoint. After this path you can pick the right API and permission model, write queries Graph accepts, retry safely and deploy a function app that stays up.
- SharePoint REST vs Microsoft Graph — which API for which jobA capability table, the auth differences and throttling budgets; decides which API you should call before you write code.A decision table by capability, the SPFx auth difference, common wrong picks, and throttling budgets
- Tenant-wide enumeration in Graph is app-only — check Delegated vs Application before you buildgetAllSites and similar calls reject delegated tokens with 403; check the permissions table first, or use an admin PowerShell export.getAllSites rejects delegated tokens; check the Permissions table first
- az CLI can't grant Sites.Selected — the scope is blocked by AADSTS65002Granting Sites.Selected needs Sites.FullControl.All, which the az CLI client cannot request; the Graph PowerShell SDK can.sites/{id}/permissions needs Sites.FullControl.All; the CLI client can't request it (AADSTS65002), use the Graph PowerShell SDK
- A comma in a Graph permissions table can mean AND — searching Teams messages needs two scopesA comma in the docs table can mean both permissions are required; the 403 says so, the table does not, so read errors closely.Searching chatMessage needs Chat.Read and ChannelMessage.Read.All; the 403 spells it out, the table does not (+ webUrl vs webLink from the same endpoint)
- The Microsoft Graph JS client sends $filter values unencoded — & splits the query, # cuts it offThe Graph JS client sends $filter values unencoded, so # and & quietly cut your query; double apostrophes, then encode..filter(), .query() and .api('…?…') pass the value into the URL as-is (SDK 3.0.2, also under SPFx MSGraphClientV3): # cuts the query, & splits it and .api() even moves $top into the filter; double apostrophes, then…
- directoryObject collections reject $select of user fields — and $top is a separate, per-endpoint trapSelecting user fields on members fails with 400; an OData cast fixes $select, and $top has to be probed per endpoint.User fields on /members//transitiveMembers = 400; OData cast cures $select everywhere, $top stays per-endpoint (probe both)
- Adding or removing a group member via Graph needs the object ID — a UPN returns 400 "Invalid object identifier"Adding or removing group members takes only the object ID, not a UPN; resolve the user first and skip the Invalid object identifier error.POST /groups/{id}/members/$ref and DELETE /groups/{id}/members/{id}/$ref accept only the user's object ID (GUID); a UPN from a people picker returns 400 Invalid object identifier — resolve it with GET…
- Retrying a throttled call is safe for GET onlyA 429 means not now, not nothing happened; retrying a write can duplicate rows, so retry policy has to depend on the method.429 means "not now", not "nothing happened"; no idempotency key exists, so a retried write duplicates the row (+ RateLimit-* headers are not guaranteed for delegated calls)
- Windows Functions — zip deploy onto a running app corrupts it (whole app 503)Zip deploy on Windows can lock wwwroot and take the whole app down with 503; WEBSITE_RUN_FROM_PACKAGE prevents it.Live wwwroot file locks → whole app 503; re-run the deploy, prevent with WEBSITE_RUN_FROM_PACKAGE=1
- Retry only fast failures — a gateway error after 230 seconds is a timeout, not a hiccupA gateway error after 230 s is a timeout, not a blip; retrying it multiplies the wait and the bill, so decide by elapsed time.The 502/503/504 a client rightly retries for transient failures also comes back when a request ran out of time (Azure Load Balancer returns 502 after 230 s), and retrying that multiplies the wait (3 × ~230 s) and the…