# SharePoint REST API: Endpoints, Authentication, and Agent Retrieval

The SharePoint REST API provides direct HTTP access to SharePoint document libraries and metadata using OData standards. While REST endpoints support folder traversal and file retrieval, AI agents face steep challenges with form digest tokens, directory recursion overhead, and HTTP 429 throttling. Syncing document libraries into indexed workspaces allows engineering teams to bypass verbose OData payloads and ground AI agents via remote MCP.

Source: https://fast.io/resources/sharepoint-rest-api/
Author: [Tom Langridge](https://fast.io/authors/tom-langridge/)
Last reviewed: 2026-10-11

## Why SharePoint REST API Architecture Demands OData Discipline

Directly querying the SharePoint REST API from an autonomous AI agent quickly degrades into a cascade of expired form digest tokens, multi-megabyte OData metadata payloads, and abrupt HTTP 429 throttling errors. While the REST interface gives developers granular access to document libraries and item-level permissions, feeding raw SharePoint HTTP responses into an agent's context window consumes precious token capacity on XML schema envelopes instead of actual document contents.

The SharePoint REST API is an OData-compliant HTTP web service that enables external applications to query, upload, and manage files, lists, and metadata across SharePoint sites using standard HTTP verbs. Built on Open Data Protocol specifications, the REST interface maps SharePoint core objects, including site collections, webs, document libraries, lists, and folders, to distinct URL paths. Applications interact with these resources by sending standard HTTP requests: GET for reading data, POST for creating items or invoking operations, PUT or MERGE for updates, and DELETE for item removal.

### OData Payloads and JSON Formatting

A persistent challenge for developers and AI pipelines using the SharePoint REST API is metadata verbosity. By default, legacy SharePoint REST implementations return payloads formatted under OData version 3 verbose conventions. These responses wrap every item in extensive `__metadata` objects containing deferred navigation URLs, type descriptors, and URI pointers:

```http
GET https://contoso.sharepoint.com/sites/Engineering/_api/web/lists/getbytitle('Documents')/items
Accept: application/json;odata=verbose
```

The resulting JSON includes extensive schema boilerplate that dwarfs the underlying document attributes:

```json
{
  "d": {
    "results": [
      {
        "__metadata": {
          "id": "Web/Lists(guid'8f4a3b1c-7d2e-4f5a-9b8c-1e2d3f4a5b6c')/Items(1)",
          "uri": "https://contoso.sharepoint.com/sites/Engineering/_api/Web/Lists(guid'8f4a3b1c-7d2e-4f5a-9b8c-1e2d3f4a5b6c')/Items(1)",
          "etag": "\"3\"",
          "type": "SP.Data.Shared_x0020_DocumentsItem"
        },
        "FileSystemObjectType": 0,
        "Id": 1,
        "ServerRedirectedEmbedUri": null,
        "ServerRedirectedEmbedUrl": "",
        "ContentTypeId": "0x010100F9F5...",
        "Title": "Architecture_Spec.docx",
        "OData__CopySource": null,
        "CheckoutUserId": null,
        "ID": 1,
        "Modified": "2026-09-14T18:22:04Z",
        "Created": "2026-08-02T11:15:30Z",
        "AuthorId": 12,
        "EditorId": 12
      }
    ]
  }
}
```

To reduce payload overhead, modern SharePoint Online supports OData minimal metadata and no-metadata modes. By modifying the `Accept` header to `application/json;odata=nometadata` or `application/json;odata=minimalmetadata`, developers strip out legacy URI descriptors. Even with minimal metadata, however, responses still retain SharePoint system columns and OData type markers that inflate prompt tokens when fed into LLM context windows.

### Comparing SharePoint REST API and Microsoft Graph API

Enterprise teams evaluating Microsoft 365 integration must choose between the specialized SharePoint REST API and the broader Microsoft Graph API. Both provide access to files stored in SharePoint Online, but their architectural scopes and endpoint models diverge:

| Dimension | SharePoint REST API | Microsoft Graph API |
|---|---|---|
| Service Root | `https://{tenant}.sharepoint.com/sites/{site}/_api/` | `https://graph.microsoft.com/v1.0/` |
| Scope | Deep, specialized SharePoint site and list objects | Unified Microsoft 365 directory, mail, chat, and files |
| File Traversal | Direct server-relative URL resolution (`GetFolderByServerRelativeUrl`) | Drive-based item hierarchy (`/sites/{id}/drive/items/{id}`) |
| Granular Permissions | Native item-level permission inheritance and role assignments | Drive item permission scoping |
| Query Protocol | OData v3 and selected OData v4 conventions | Strict OData v4 standardized endpoints |
| Legacy Compatibility | Full support for legacy list schemas and CAML queries | Modern JSON schema oriented toward cross-service consumption |

Microsoft Graph is the standard recommendation for multi-service applications touching mail, calendar, Teams, and file storage simultaneously. However, engineering teams continue to rely on the native SharePoint REST API when building specialized automations that require fine-grained access to SharePoint site settings, complex list column structures, or direct server-relative path references.

## How SharePoint REST API Authentication Manages Bearer Tokens and Form Digests

Authenticating external applications against SharePoint Online requires establishing identity via Microsoft Entra ID. While user-interactive applications rely on delegated OAuth flows, automated scripts, backend services, and autonomous coding agents use the OAuth 2.0 client credentials grant to operate with application permissions.

### Registering the Entra ID Application

To configure app-only access, an administrator registers an application in the Microsoft Entra admin center and defines the necessary API permissions:

* Register an application under Microsoft Entra ID, navigating to App registrations. Note the Application (client) ID and Directory (tenant) ID.
* Generate an application secret under Certificates & secrets, or upload an X.509 public certificate for higher security.
* Grant API permissions under API permissions by selecting Add a permission, then SharePoint.
* Select Application permissions and assign `Sites.Selected` for restricted, site-scoped access or `Sites.Read.All` for tenant-wide read access. An administrator must then select Grant admin consent.

When using `Sites.Selected`, the application has no access to any SharePoint site collection until an administrator explicitly grants rights to a specific site URL using Microsoft Graph or PowerShell.

### Requesting the OAuth Bearer Token

With the application registered and permissions consented, the background service requests an access token from the Microsoft identity platform token endpoint:

```bash
curl -X POST "https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id={client_id}" \
  -d "client_secret={client_secret}" \
  -d "scope=https://{tenant}.sharepoint.com/.default"
```

The authentication service returns a JSON payload containing the `access_token` and its expiration duration:

```json
{
  "token_type": "Bearer",
  "expires_in": 3599,
  "access_token": "your-access-token"
}
```

### The Form Digest Token Requirement (`X-RequestDigest`)

Acquiring a Bearer token is sufficient for HTTP GET requests. However, when an application executes state-changing HTTP operations, including POST, PUT, MERGE, and DELETE, the SharePoint REST API demands an additional security validation token known as the form digest.

The form digest protects SharePoint against Cross-Site Request Forgery (CSRF). External applications must fetch a fresh digest value by calling the `/_api/contextinfo` endpoint:

```bash
curl -X POST "https://contoso.sharepoint.com/sites/Engineering/_api/contextinfo" \
  -H "Authorization: Bearer {access_token}" \
  -H "Accept: application/json;odata=nometadata" \
  -H "Content-Length: 0"
```

The response provides the security token string inside the `FormDigestValue` field, along with its lifetime:

```json
{
  "FormDigestTimeoutSeconds": 1800,
  "FormDigestValue": "0x4B3A8F2C1D...,11 Oct 2026 10:45:00 -0000",
  "LibraryVersion": "16.0.25210.12000",
  "SiteFullUrl": "https://contoso.sharepoint.com/sites/Engineering",
  "WebFullUrl": "https://contoso.sharepoint.com/sites/Engineering"
}
```

### The Digest Expiration Problem for Autonomous Workflows

The form digest token presents an operational trap for autonomous scripts and long-running agents. The digest carries an internal lifespan, specified by `FormDigestTimeoutSeconds`, which defaults to 1800 seconds.

When an agent executes an extended ingestion or analysis workflow, such as processing hundreds of documents sequentially, the digest token expires mid-execution. Subsequent POST or file upload requests immediately fail with HTTP 403 Forbidden:

```json
{
  "odata.error": {
    "code": "-2130575252, Microsoft.SharePoint.SPException",
    "message": {
      "lang": "en-US",
      "value": "The security validation for this page is invalid and might be corrupted. Please use your browser's Back button to refresh the page and try your operation, or contact your administrator."
    }
  }
}
```

To prevent pipeline failures, any custom connector or agent wrapper communicating with the SharePoint REST API must maintain an active token cache, track the digest creation timestamp, and preemptively call `/_api/contextinfo` before the timeout window closes.

## How to Navigate Folders and Retrieve Files Using REST Endpoints

The SharePoint REST API uses server-relative URLs to navigate folder trees and retrieve document assets. A server-relative URL represents the path to a site or asset starting from the host root, such as `/sites/Engineering/Shared Documents/Specifications`.

### Navigating Folders with `GetFolderByServerRelativeUrl`

The primary entry point for directory operations is the `GetFolderByServerRelativeUrl` method on the `web` object. To inspect the contents of a folder, send a GET request targeting the server-relative path:

```http
GET https://contoso.sharepoint.com/sites/Engineering/_api/web/GetFolderByServerRelativeUrl('Shared%20Documents/Specifications')/Files
Authorization: Bearer {access_token}
Accept: application/json;odata=nometadata
```

To retrieve both folders and files in a single pass, applications must make separate calls to `/Folders` and `/Files` on the target container.

The REST interface also supports batching multiple calls into a single HTTP round-trip using OData `$batch` requests. The SharePoint Online (and on-premises SharePoint 2016 and later) REST service supports combining multiple requests into a single call to the service by using the OData $batch query option. This capability allows batching folder inspection and property queries into a multipart MIME payload, reducing round-trip connection overhead for high-latency integrations.

### Downloading File Contents

Accessing a file involves two distinct REST patterns depending on whether you need metadata or raw bytes:

1. **Retrieving File Metadata:** Target the file resource without the binary stream operator to inspect file size, author, timestamps, and check-out status:

```http
GET https://contoso.sharepoint.com/sites/Engineering/_api/web/GetFileByServerRelativeUrl('/sites/Engineering/Shared%20Documents/Specifications/System_Spec.pdf')
Authorization: Bearer {access_token}
Accept: application/json;odata=nometadata
```

2. **Retrieving Binary File Bytes:** Append `/$value` to the file URL. The endpoint streams the raw file payload with the appropriate MIME content-type:

```http
GET https://contoso.sharepoint.com/sites/Engineering/_api/web/GetFileByServerRelativeUrl('/sites/Engineering/Shared%20Documents/Specifications/System_Spec.pdf')/$value
Authorization: Bearer {access_token}
```

### Uploading Files and Chunked Sessions

Uploading files through the SharePoint REST API requires matching the upload pattern to the asset size:

* **Simple Uploads for Standard Files:** Standard files can be posted directly to the `Files/add` endpoint of the destination folder:

```http
POST https://contoso.sharepoint.com/sites/Engineering/_api/web/GetFolderByServerRelativeUrl('Shared%20Documents/Specifications')/Files/add(url='Report.pdf',overwrite=true)
Authorization: Bearer {access_token}
X-RequestDigest: {form_digest_value}
Content-Type: application/octet-stream
Content-Length: {file_byte_size}

<binary-file-content>
```

* **Chunked Upload Sessions for Large Binaries:** Direct single-request file uploads fail on large binaries due to request timeouts and gateway payload limits. Large assets require initiating an upload session using `StartUpload`, appending subsequent byte slices with `ContinueUpload`, and finalizing the file state via `FinishUpload`. Each chunk call requires tracking upload offsets and passing a unique session GUID.

### Essential SharePoint REST File Endpoints

The table below summarizes the essential endpoints required for file and folder management in SharePoint Online:

| Operation | HTTP Verb | Endpoint Path | Key Headers |
|---|---|---|---|
| Get Form Digest | POST | `/_api/contextinfo` | `Authorization`, `Content-Length: 0` |
| List Folder Files | GET | `/_api/web/GetFolderByServerRelativeUrl('{path}')/Files` | `Authorization`, `Accept: application/json` |
| List Subfolders | GET | `/_api/web/GetFolderByServerRelativeUrl('{path}')/Folders` | `Authorization`, `Accept: application/json` |
| Get File Metadata | GET | `/_api/web/GetFileByServerRelativeUrl('{path}')` | `Authorization`, `Accept: application/json` |
| Download File Content | GET | `/_api/web/GetFileByServerRelativeUrl('{path}')/$value` | `Authorization` |
| Simple File Upload | POST | `/_api/web/GetFolderByServerRelativeUrl('{path}')/Files/add(url='{name}',overwrite=true)` | `Authorization`, `X-RequestDigest`, `Content-Type` |
| Delete File | POST | `/_api/web/GetFileByServerRelativeUrl('{path}')` | `Authorization`, `X-RequestDigest`, `X-HTTP-Method: DELETE` |
| Search Library | POST | `/_api/search/query` | `Authorization`, `Content-Type: application/json` |

## Why AI Agents Struggle with Direct SharePoint REST Retrieval

Autonomous AI coding agents, data extraction pipelines, and retrieval-augmented generation (RAG) assistants encounter steep architectural friction when interacting directly with the SharePoint REST API. Connecting an LLM framework directly to SharePoint endpoints exposes significant limitations in prompt efficiency, network latency, and service availability.

### Token Bloat from OData Schema Wrapping

When an AI agent queries a folder to discover relevant files, it must parse the directory JSON into its working memory. Even when requesting `odata=nometadata`, SharePoint Online includes dozens of internal metadata attributes for every file object: GUID identifiers, XML schema markers, complex numeric permission masks, and date stamps.

In a document library folder containing dozens of files, the raw JSON payload consumes thousands of tokens of context space. The agent spends its context window processing system metadata before extracting any actual document sentences. This schema density dilutes prompt attention, increases retrieval latency, and quickly inflates inference costs across iterative reasoning loops.

### Latency in Recursive Directory Traversal

Enterprise file structures are deeply nested. A company's technical specifications may reside four or five folder levels below the library root:

```text
/Shared Documents/Engineering/Hardware/2026/Prototypes/Schematics/
```

The SharePoint REST API does not provide a single, recursive flat-file listing endpoint out of the box. To discover files across a document library, an agent must execute sequential HTTP queries:
* Call `GetFolderByServerRelativeUrl('Shared Documents')/Folders` to locate child directories.
* Iterate through each returned folder and make subsequent GET calls to inspect children.
* Queue additional HTTP calls for every subfolder branch.

For a library with multiple nested folders, an agent must issue dozens of synchronous HTTP GET requests simply to compile an index of available files. Network round-trips quickly accumulate, turning a simple user question into an extended directory crawl.

### HTTP 429 Throttling and Service Limits

SharePoint Online protects tenant infrastructure from resource exhaustion by enforcing dynamic rate limits. Automated agents that issue rapid bursts of recursive lookups or bulk file downloads trigger aggressive throttling thresholds.

For requests that an application makes, including Microsoft Graph, CSOM, or REST calls, SharePoint Online returns HTTP status code 429 ("Too many requests") or 503 ("Server Too Busy"), and the requests will fail.

When SharePoint issues an HTTP 429 or 503 response, it includes a `Retry-After` header indicating the number of seconds the application must pause before retrying. Autonomous agents that fail to parse this header and continue issuing requests risk having the application registration blocked entirely at the tenant level. Implementing compliant backoff and jitter algorithms inside an agentic framework adds substantial code complexity.

### Lack of Native Semantic Vector Grounding

The SharePoint REST API provides keyword search capabilities via `/_api/search/query`, allowing applications to issue Keyword Query Language (KQL) expressions. However, KQL relies on keyword matching, wildcard tokens, and managed property filters.

Modern AI agents require semantic search: the ability to match concepts based on vector embeddings regardless of exact terminology. A user asking an agent to find the updated liability limits in vendor master agreements will miss relevant files if the documents use the phrase contractual indemnification ceilings and the query only searches literal keywords. Translating natural language prompts into effective KQL queries requires complex query planning and frequently yields incomplete document recall.

## How Workspace Synchronization and Remote MCP Connect Documents to Agents

Rather than writing complex, fragile REST wrappers that handle recursive crawling, digest refreshes, and rate limits inside your agent code, modern engineering teams decouple document storage from agent retrieval. The reader keeps their existing files in SharePoint, OneDrive, Dropbox, or Box, while an intelligent workspace handles synchronization, background indexing, and model context protocol (MCP) serving.

### How Cloud Sync Bridges SharePoint Libraries

In this architecture, team files remain safely in their primary system of record. Cloud Sync connects workspaces with Google Drive, Dropbox, Box, and OneDrive (one-way or two-way, on a schedule or on demand, never continuous or real-time; SharePoint document libraries are accessed through the OneDrive connector).

Once connected, files synchronize into a shared, org-owned Fastio workspace. This approach provides several key operational benefits:

* **Elimination of Traversal Overhead:** Workspaces maintain an updated, unified file catalog. Agents no longer execute recursive HTTP calls across nested SharePoint folders.
* **Shielding from Rate Limits:** Agents query the workspace rather than issuing high-frequency REST calls to SharePoint Online, avoiding HTTP 429 throttling blocks and `Retry-After` delays.
* **Preserved System of Record:** Human team members continue creating, editing, and sharing documents within their standard SharePoint libraries without altering corporate workflows.

### Workspace Intelligence and Hybrid Search

When files land in an intelligent workspace, Fastio auto-indexes their contents upon arrival. Intelligence Mode provides hybrid search, combining full-text keyword indexing, semantic vector embeddings, and search-by-metadata-value into a single retrieval interface.

When an AI agent searches for information, it does not download raw PDF binaries or parse through verbose OData metadata envelopes. Instead, the agent queries the workspace and receives precise, compact semantic passages along with citations referencing the exact source documents. For structured extraction, [Metadata Views](/product/document-data-extraction/) turn unstructured documents into typed schemas (Text, Integer, Decimal, Boolean, URL, JSON, Date & Time) without requiring brittle OCR templates or manual extraction scripts.

### Remote MCP Server Integration

Agents connect to Fastio workspaces using the Model Context Protocol (MCP) over Streamable HTTP. Fastio hosts a remote MCP server, eliminating the need to run local daemons or bridge processes.

Connecting an AI agent or development environment takes the standard endpoint URL:
* **Claude Apps and General Clients:** Connect with OAuth at `https://mcp.fast.io/mcp/tools`.
* **Coding Agents in IDEs and Terminals:** Claude Code, Cursor, Cline, Devin Desktop, and GitHub Copilot connect to `https://mcp.fast.io/mcp/code`.
* **ChatGPT and Codex:** Install the Fastio plugin from the ChatGPT plugin directory, or configure a custom server at `https://mcp.fast.io/mcp/operations`.
* **Autonomous Scripts and Server Daemons:** When running headless code or framework agents (such as LangGraph or custom Python scripts), authenticate by passing a scoped API key as `Authorization: Bearer <api_key>` on the connection.

For complete setup instructions across each client environment, refer to the [Fastio MCP documentation](https://mcp.fast.io/docs).

### Benchmarking Connector Performance

The performance of cloud storage connectors directly impacts agent execution speed and token consumption. In storage connector tests evaluating Claude Cowork performance against major cloud storage repositories, SharePoint was not measured at all. For the cloud providers that were tested, the [connector comparison published at Fast.io](https://fast.io/benchmarks/) measured Fastio as the fastest and the lowest cost of the providers tested, with accuracy at parity across the evaluated platforms.

By offloading document indexing and search retrieval to an intelligent workspace over remote MCP, agents access enterprise SharePoint documents without consuming valuable reasoning tokens on HTTP transport boilerplate.

## When to Choose Direct REST Calls versus Workspace MCP Retrieval

Architecting integrations between enterprise documents and software systems requires evaluating where your code executes and what operations it performs. Both direct SharePoint REST integration and workspace-mediated MCP retrieval serve distinct engineering purposes.

### When to Use Direct SharePoint REST API Calls

The native SharePoint REST API remains the appropriate choice for:

* **Site Administration and Governance:** Automations that provision site collections, adjust list permission inheritance, manage site groups, or modify content type inheritance.
* **SharePoint Framework (SPFx) Web Parts:** Client-side components executing directly within the SharePoint browser context, where user identity and `__REQUESTDIGEST` values are natively available in the DOM.
* **Deterministic Line-of-Business Forms:** Applications performing structured CRUD operations against custom SharePoint list columns where document text extraction and semantic understanding are unnecessary.

### When to Use Workspace Sync with Remote MCP

Decoupling storage via workspace synchronization and remote MCP is the superior pattern for:

* **AI Coding Assistants and Autonomous Agents:** Enabling tools like Claude Code, Cursor, or Cline to search enterprise documentation, architectural blueprints, and compliance records during software development.
* **Cross-Functional Team Collaboration:** Providing a shared substrate where human teammates use standard web interfaces while autonomous agents read and write workspace assets via MCP.
* **Multi-Agent Coordination:** Managing concurrent agent interactions using per-file version history, where every modification is preserved and accessible.
* **Auditing and Operational Oversight:** Tracking agent and human actions through a detailed activity log that records workspace events without relying on fragmented SharePoint audit exports.
* **Client and Partner Handoff:** Sharing curated project outputs using branded shares (Send, Receive, or Exchange) with per-recipient access controls and optional download restrictions.

### Getting Started with Intelligent Workspaces

Setting up an intelligent workspace to bridge your SharePoint document libraries takes minutes. Monthly plans start with a 14-day free trial, which requires a credit card and ends early if trial credits run out. Check all tiers and allowances on the [workspace pricing](/pricing/) page:

| Plan | Monthly Billing | Annual Billing | Included Seats & Workspaces | Storage & Max Upload | AI Credits / Month |
|---|---|---|---|---|---|
| Starter | $9.99/mo | $99/year | 3 seats, 5 workspaces | 250 GB storage, 25 GB upload | 100,000 |
| Business | $49.99/mo | $499/year | 10 seats, 50 workspaces | 5 TB storage, 50 GB upload | 600,000 |
| Enterprise | $199.99/mo | $1,999/year | 30 seats (extra $1/seat up to 200), 200 workspaces | 25 TB storage, 100 GB upload | 3,000,000 |

Credits meter AI retrieval and extraction work, while storage and seats remain included in the plan.

By establishing an indexed workspace layer between SharePoint and your AI agents, engineering teams eliminate authentication digest failures, prevent 429 throttling errors, and equip agents with fast, citation-backed semantic retrieval.

## Frequently asked questions

### What is the difference between the SharePoint REST API and Microsoft Graph API?

The SharePoint REST API is a specialized service providing low-level access to SharePoint-specific objects, list column structures, and server-relative URL paths. Microsoft Graph is a unified API spanning Microsoft 365 services, including files, mail, calendar, and Teams. Graph is recommended for general cross-service applications, while SharePoint REST is used for deep site configuration and legacy list operations.

### How do I authenticate with the SharePoint REST API?

External applications authenticate using OAuth 2.0 through Microsoft Entra ID. Register an application in Entra ID, grant SharePoint API permissions, and request a Bearer token via the client credentials flow. Read operations require only the Bearer token, while modifying operations (POST, PUT, DELETE) also require acquiring an X-RequestDigest token from the /_api/contextinfo endpoint.

### Why do POST requests to the SharePoint REST API fail with a 403 Forbidden error?

POST, PUT, and DELETE operations fail with a 403 error if the X-RequestDigest header is missing, invalid, or expired. Form digest tokens have a default lifetime of 1800 seconds (30 minutes). Automated scripts and agents must query /_api/contextinfo to refresh the FormDigestValue before executing state-changing calls.

### How do I access SharePoint document libraries via REST API?

Document libraries are accessed using the GetFolderByServerRelativeUrl endpoint on the web object. For example, sending a GET request to /_api/web/GetFolderByServerRelativeUrl('Shared Documents/Subfolder')/Files retrieves the metadata of all files within that library directory.

### Can AI agents query SharePoint documents using the REST API?

AI agents can query SharePoint documents via REST, but they encounter significant hurdles: verbose OData metadata bloat that consumes context tokens, multi-step latency from recursive folder traversal, and strict HTTP 429 throttling limits. A more resilient alternative is syncing document libraries to an indexed workspace and querying via remote MCP.

### How does SharePoint Online throttle REST API requests?

When an application exceeds request thresholds, SharePoint Online returns HTTP status code 429 (Too Many Requests) or 503 (Server Too Busy). Responses include a Retry-After header indicating how many seconds the application must wait before retrying. Persistent high-volume requests can result in tenant-level application blocks.

## Sources

- [Microsoft Learn: Working with Folders and Files with REST](https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins/working-with-folders-and-files-with-rest): The SharePoint REST service supports combining multiple requests into a single call using the OData batch query option.
- [Microsoft Learn: Avoid getting throttled or blocked in SharePoint Online](https://learn.microsoft.com/en-us/sharepoint/dev/general-development/how-to-avoid-getting-throttled-or-blocked-in-sharepoint-online): SharePoint Online returns HTTP status code 429 or 503 when application requests exceed service usage limits.

## About Fast.io

Fast.io provides shared workspaces where people and AI agents work on the same files, with built-in semantic search and citation-backed chat over what they hold. Agents reach it through a remote MCP server, a REST API at https://api.fast.io/current/, and a command line client published on npm as @vividengine/fastio-cli. MCP setup is at https://mcp.fast.io/docs: Claude and most MCP clients connect to https://mcp.fast.io/mcp/tools, ChatGPT to https://mcp.fast.io/mcp/operations, and coding agents to https://mcp.fast.io/mcp/code.