The SharePoint API lets external systems, workflows and applications read and write SharePoint Online data through two supported surfaces, the SharePoint REST API and Microsoft Graph. Since 2 April 2026 the rules changed: Azure ACS and SharePoint Add-ins are fully retired, so every integration now authenticates through Microsoft Entra ID. This guide explains how the API works, how to choose between REST and Graph and how to build integrations that survive throttling and governance review.
Table of Contents
What is the SharePoint API?
The SharePoint API is the programmatic interface for reading and writing SharePoint Online sites, lists, document libraries, permissions and metadata. It is exposed through two supported surfaces, the SharePoint REST API and Microsoft Graph and it is secured through Microsoft Entra ID. Integrations use it to move documents and data between SharePoint and other business systems without a person in the middle.
Under the hood, almost everything in SharePoint is a list. Microsoft’s Graph SharePoint overview describes lists as the foundation for data storage in SharePoint, with document libraries being a special list type that holds files. That model is why the API is so useful for integration: once a system can talk to lists and drives, it can reach most of what a business keeps in SharePoint.
In our consulting work the majority of SharePoint API projects are not greenfield builds. They are usually about connecting SharePoint to something else, a CRM that needs project documents, a finance system that needs approvals evidence or an AI assistant that needs to read policy files. That work sits inside the broader discipline of business systems integration and the same principles apply whichever platform is at the centre. Many organisations are already calling the API daily without realising it, because Power Automate connectors and third-party backup tools sit on the same endpoints. If you are planning broader SharePoint work, our SharePoint consulting page covers the structural side.
What replaced SharePoint Add-ins and ACS after 2 April 2026?
Microsoft Entra ID is now the only supported authentication path for SharePoint Online integrations. Azure ACS stopped working for existing tenants and was fully retired on 2 April 2026 and SharePoint Add-ins were retired alongside it. Any integration still using ACS app-only principals has already stopped working and there is no extension option.
Microsoft’s Azure ACS retirement notice is blunt about it: there is no option to extend ACS with SharePoint Online beyond 2 April 2026 and this applies to every environment including government clouds. The practical impact is bigger than most teams expect, because ACS was the quiet default for years. Anything registered through the old appregnew.aspx page with a client ID and secret, which describes a lot of legacy sync jobs and provider-hosted add-ins we still find in Australian tenants, is in scope.
Our view is that the retirement is a good thing. ACS principals were near-invisible to governance, often carried tenant-wide permissions and never expired. If you have not audited yet, run the Microsoft 365 Assessment tool referenced in the retirement notice to scan your tenant for ACS usage, then rebuild each integration on an Entra ID app registration. Once nothing legitimate remains, tenant admins can disable custom app authentication entirely.
SharePoint REST API vs Microsoft Graph: which should you use?
Use Microsoft Graph by default and drop to the SharePoint REST API only where Graph does not cover the scenario. Microsoft’s throttling guidance highly recommends choosing Graph over CSOM and REST where possible, because Graph consumes fewer resources for the same functionality. REST remains fully supported for SharePoint-specific capability Graph has not absorbed.
Microsoft’s own developer documentation states that innovation in REST APIs against SharePoint is now driven through the Microsoft Graph REST APIs, with several Graph endpoints backed directly by SharePoint Online. The table below compares the two surfaces on the factors that actually decide the choice in real projects.
| Factor | Microsoft Graph | SharePoint REST API |
|---|---|---|
| Endpoint | graph.microsoft.com | tenant.sharepoint.com/_api |
| Best for | Files, lists, sites, permissions, cross-service scenarios spanning Teams, Outlook and OneDrive | Deep SharePoint-specific features not yet in Graph, legacy compatibility |
| Where new investment lands | All new API innovation | Maintained but not extended |
| Throttling cost | Predetermined resource unit cost, generally lower | No predetermined cost, usually consumes more resource units |
| Tooling | Graph SDKs, Graph Explorer, consistent auth across Microsoft 365 | PnP libraries, OData queries, older samples |
| Default position | Start here | Use by exception |
In practice most non-trivial integrations we build end up mixed. Graph handles files, sites and permissions cleanly, then one or two calls drop to REST for something SharePoint-specific like a particular list form behaviour. That is a normal architecture, not a failure. What matters is that both surfaces sit behind the same Entra ID app registration so governance sees one identity, not two.
How does SharePoint API authentication work now ACS is retired?
Every SharePoint API integration authenticates through a Microsoft Entra ID app registration, using delegated permissions when a signed-in user is present or application permissions for unattended services. The Sites.Selected permission model grants an app access to specific sites only, which is the least-privilege pattern governance teams now expect.
The setup process is consistent regardless of what you are connecting:
- Register an application in Microsoft Entra ID and record the client ID.
- Choose the permission type: delegated for user-present scenarios, application for background services.
- Request Sites.Selected rather than tenant-wide scopes, then grant the app access to only the sites it needs.
- Use certificate credentials instead of client secrets for unattended access, stored in a vault, not in code or a config file.
- Get admin consent recorded, so the permission grant is visible and auditable in Entra ID.
We hold ourselves to the same standard we set for clients. When we built OPC Hub, our own custom CRM, Microsoft Entra ID sat at the centre of the authentication model from day one, with role-based access control and audit logging built in rather than bolted on. The same principle applies to any SharePoint integration: identity first, features second.
Can SharePoint call external APIs?
Not directly in any way you should rely on. SharePoint Online is a target for API calls, not a platform for making them. The supported pattern is event-driven: SharePoint raises a change through a webhook or connector trigger and middleware such as Power Automate, Azure Logic Apps or an Azure Function makes the outbound call to the external API.
This distinction shapes architecture decisions more than any other point in this guide. Teams sometimes expect SharePoint to behave like an integration engine, then discover the platform gives them no supported server-side place to run outbound logic. The middleware layer is not overhead, it is where retry handling, error logging and credential storage belong anyway. For simple flows a Power Automate workflow is usually enough. For higher volumes or complex transformation, an Azure Function with a queue in front of it is the pattern we reach for, because it lets you control pacing when the external system or SharePoint itself starts throttling.
What are the SharePoint API throttling limits and how do you avoid 429 errors?
SharePoint Online throttles each application by resource units within a time window and returns HTTP 429 or 503 with a Retry-After header when limits are exceeded. Microsoft’s guidance is that honouring Retry-After is the fastest way through, because throttled requests still count towards your usage limits.
The detail that catches teams out is in Microsoft’s SharePoint Online throttling guidance: aggressive retries actively work against you, since failed calls still consume quota and applications that keep exceeding limits can be blocked outright. The same document notes that CSOM and REST usually consume more resource units than Graph for the same job, which is another reason Graph is the default choice above.
The mitigations that matter most in production are pacing and decoration. Spread bulk operations across off-peak windows rather than hammering a migration or nightly sync through business hours. Watch the RateLimit headers SharePoint returns as you approach limits. Decorate traffic with a registered app ID and a proper User-Agent string, because well-decorated traffic is prioritised over anonymous calls. Use delta queries and batching so you request less in the first place. Throttling almost never shows up in a demo and almost always shows up in the first full-volume run, so build the handling before you need it.
What are the most common SharePoint API integration use cases?
The most common SharePoint API integrations connect documents and list data to the other systems a business runs on: CRM document sync, finance approval evidence, automated document generation, compliance archiving and AI assistants that read SharePoint content. The driver is app sprawl, since data spread across many systems rarely stays consistent by itself.
The scale of that sprawl is easy to underestimate. Zylo’s 2026 SaaS Management Index found the average company manages 305 SaaS applications. SharePoint is where an enormous share of Australian business documents live, so it ends up as the common denominator across those stacks. The patterns we build most often:
- CRM integration, surfacing SharePoint documents against Salesforce or Dynamics 365 records and writing key CRM fields back to SharePoint metadata.
- Document generation, creating contracts or reports from templates and filing them with correct metadata and permissions automatically.
- Line-of-business sync, keeping project or client folders aligned with a job management or finance system.
- AI grounding, giving an internal assistant governed read access to policies and procedures stored in SharePoint.
- Compliance archiving, moving records into managed libraries with retention labels applied through the API.
Each of these is a different balance of volume, latency and governance, which is why we scope the integration pattern before choosing tools. Our API and integration services page describes how we approach that scoping.
What are the most common SharePoint API integration mistakes?
The mistakes that cause real damage are over-permissioning, secrets in code, ignoring Retry-After and treating SharePoint like a database. Most failed integrations we are asked to rescue made at least two of these and every one of them is avoidable at design time rather than expensive to fix in production.
- Granting tenant-wide Sites.FullControl.All when Sites.Selected on two sites would do. Governance reviews now flag this immediately.
- Client secrets pasted into scripts and config files, with no rotation and no vault. Certificates in a key vault are the supported pattern.
- Retry loops that ignore Retry-After. The failed calls still count against quota, so the integration throttles itself harder.
- Using SharePoint lists as a transactional database. Lists are excellent for documents and structured team data, poor for high-volume relational workloads.
- No pagination or delta handling, so the sync works on 200 test items and falls over on 200,000 real ones.
- Building anything new on the Add-ins model. It is retired and new work on it is technical debt on day one.
When is SharePoint the wrong data platform?
SharePoint is the wrong platform when the workload is relational, transactional or high-volume. It excels at documents, metadata and collaboration data. When an application needs complex joins, strict schemas, thousands of writes per hour or row-level performance guarantees, Dataverse or Azure SQL is the honest answer, with SharePoint kept for the documents.
We apply this rule to our own systems. When we built OPC Hub, our internal CRM, we deliberately did not build it on SharePoint lists. Client records, jobs, quotes and time entries went into Azure SQL because they are relational transactional data and the result was one system replacing a stack of disconnected tools with zero double entry. The table below is the comparison we walk clients through when this decision comes up.
| Factor | SharePoint | Dataverse | Azure SQL |
|---|---|---|---|
| Best at | Documents, metadata, collaboration content | Structured business data inside Power Platform | Relational, transactional, high-volume workloads |
| Relationships | Basic lookups | Native relationships and business rules | Full relational model |
| Volume comfort | Large libraries, modest list transaction rates | Mid-scale business apps | Very high |
| Licensing model | Included with Microsoft 365 | Per-user Power Platform licensing | Consumption-based Azure billing |
| Typical role in integration | Document store and collaboration layer | App data layer for Power Apps | Custom app and analytics backbone |
The strongest architectures we see use SharePoint for what it is good at and connect it to the right data platform through the API, rather than forcing everything into one tool. That is an integration decision and it is exactly the kind of call our system integration and CRM work exists to get right early.
Frequently asked questions
Is SharePoint being discontinued or replaced?
No. SharePoint Online remains a core Microsoft 365 workload and its APIs are actively maintained. What has been retired is the old authentication and extension layer, Azure ACS and SharePoint Add-ins, both fully retired on 2 April 2026. The platform and its APIs, accessed through Microsoft Graph and the SharePoint REST API, continue with ongoing Microsoft investment.
Do I need extra licensing to use the SharePoint API?
There is no separate SharePoint API licence. Access rides on the Microsoft 365 licensing your organisation already holds. The real costs sit in the surrounding architecture, such as Azure Functions, Logic Apps or middleware hosting, which bill on their own consumption models and in the effort to design, build and support the integration itself.
What is Sites.Selected and why does it matter?
Sites.Selected is a Microsoft Graph permission that grants an application access to specific SharePoint sites only, instead of every site in the tenant. It matters because it is the least-privilege pattern security reviews now expect. An integration that only needs two sites should be able to touch only those two sites and Sites.Selected is how you enforce that.
Should I use Power Automate or custom code for SharePoint integration?
Power Automate suits event-driven flows with modest volumes, such as filing a document when a form is submitted. Custom code through Microsoft Graph suits high volumes, complex transformation or strict error handling, where you need control over pacing, retries and logging. Many real solutions combine both, with flows handling triggers and an Azure Function handling the heavy lifting.
What happens to integrations still using Azure ACS?
They have stopped working. Azure ACS was fully retired for SharePoint Online on 2 April 2026 with no extension option, so any integration still authenticating through ACS principals now fails. The fix is to re-register the integration as a Microsoft Entra ID application, request the least permissions it needs and reissue credentials, ideally certificates rather than client secrets.
How long does a SharePoint API integration take to build?
A focused single-direction sync, such as filing generated documents into a library with metadata, is typically days to a couple of weeks including testing. Bidirectional sync with a CRM, or anything with volume, error recovery and governance requirements, is usually a few weeks. The biggest time variable is rarely the API itself, it is agreeing the data model and permissions up front.
Where the SharePoint API fits now
The SharePoint API in 2026 is a mature, well-governed integration surface with one clear identity model. Graph first, REST by exception, Entra ID always, Sites.Selected wherever possible and throttling handled before the first full-volume run. Get those five calls right and SharePoint becomes the reliable document layer in a connected stack instead of another silo.
If you are planning a SharePoint integration, rescuing one that broke after the ACS retirement or deciding between SharePoint, Dataverse and Azure SQL for a new build, we do this work every week for Australian organisations. Book a free call and we will talk through your scenario, no obligation.
