office365-rest-python-client for Microsoft 365 and SharePoint

Why office365-rest-python-client separates Graph and SharePoint

office365-rest-python-client addresses a specific problem in Python applications that work with Microsoft 365: the service APIs expose different clients, models, authentication choices, and areas of coverage. Rather than presenting them as interchangeable endpoints, the library provides `GraphClient` for Microsoft Graph and `ClientContext` for SharePoint REST API v1. This distinction matters because SharePoint administration and certain SharePoint resources have more complete representation through `ClientContext`, while cross-service Microsoft 365 work belongs under Microsoft Graph.

`GraphClient` is intended for Outlook, OneDrive, Teams, OneNote, Planner, To Do, Entra ID, Intune, Purview, Bookings, reports, and security APIs. The README describes this as the modern cross-service route for OneDrive. `ClientContext` targets SharePoint lists, items, files, folders, search, permissions, site and tenant administration, taxonomy, and webhooks. The choice is therefore determined by the Microsoft API and the objects an application needs, not merely by the fact that both clients produce Python objects.

The project targets Python 3.8 and later. Its package metadata describes the release as beta and includes classifiers for Python versions from 3.8 through 3.15. Core dependencies include `msal`, `pytz`, `requests`, and `typing-extensions`. Optional dependency groups add Azure Blob and cryptography support under `azure`, DuckDB support under `duckdb`, and additional packages for examples. This is a broad client library rather than a small wrapper around one endpoint.

Deferred Graph queries and typed Microsoft 365 models

Query construction is deferred. According to the README, applications can chain `.select()`, `.filter()`, `.expand()`, `.top()`, and `.order_by()` before calling `.execute_query()`, which sends the request. This gives code a query-builder shape while retaining explicit control over when network access occurs.

Results are represented as typed Python classes rather than generic dictionaries. The documented `GraphClient` models include `DriveItem`, `Team`, `Message`, `Event`, `User`, `Group`, and `PlannerTask`. The `ClientContext` models include `List`, `ListItem`, `File`, `Folder`, `Web`, `Site`, and `User`. This design reduces arbitrary string-key handling in application code, although the exact response still depends on the Microsoft endpoint, requested fields, permissions, and returned data.

The repository contains product-oriented example directories for administration, authentication, backup and restore, communications, data, Entra ID, insights, Intune, OneDrive, OneNote, Outlook, patterns, Planner, Purview, reports, security, SharePoint, Teams, and To Do. The README describes these as runnable examples and states that there are more than 700. Their presence helps an engineer find a service-specific starting point, but it does not prove that every endpoint or operation is covered. Confirm that the exact resource and query pattern required by the application is represented.

Installing office365-rest-python-client and loading a SharePoint site

The package can be installed from PyPI. The README also documents installation with `uv` and directly from the Git repository. Choose the source that matches the application's dependency and deployment process.

pip install office365-rest-python-client

For a project that uses `uv`, the documented command adds the package to the project dependencies.

uv add office365-rest-python-client

To install the default branch directly from source, use the Git URL shown in the README.

pip install git+https://github.com/vgrem/office365-rest-python-client.git

A first SharePoint use requires a site URL and an authentication choice. The README's certificate example uses `ClientContext` with a tenant, client ID, certificate thumbprint, and PEM file. Replace the documented placeholder values with credentials registered for the target tenant. `with_client_certificate()` establishes app-only access, after which `ctx.web.get().execute_query()` retrieves the web object and `print(web.title)` displays its title.

from office365.sharepoint.client_context import ClientContext

ctx = ClientContext("https://contoso.sharepoint.com/sites/team").with_client_certificate(
    "contoso.onmicrosoft.com",
    client_id="00000000-0000-0000-0000-000000000000",
    thumbprint="AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00",
    cert_path="./private.pem",
)

web = ctx.web.get().execute_query()
print(web.title)

The expected observable result is the title of the SharePoint web associated with the supplied site URL. Authentication must succeed first, and the app registration must be allowed to access that site.

Choosing interactive, device-code, certificate, or secret authentication

Authentication is not uniform across the two clients. The README states that modern flows authenticate through Microsoft Entra ID using MSAL, with support for delegated user access and app-only application access. For `ClientContext`, the documented options include certificate, interactive, device code, username and password, custom token, browser cookies, and NTLM for on-premises SharePoint.

Certificate authentication is the documented app-only path for SharePoint REST API v1. Interactive and device-code flows provide delegated access and support MFA. Username and password is listed as delegated access, while ROPC appears in the authentication guidance as a flow that requires MFA to be turned off. This is an operational constraint that affects whether a login can succeed.

The README records authentication retirements: SharePoint ACS app-only access was retired in April 2026, and SAML-based authentication was retired in May 2026. It directs users to certificate, interactive, or device-code flows and points to modern authentication examples under `examples/sharepoint/auth/modern/`. For `GraphClient`, the documented choices include client secret, certificate, interactive, device flow, and ROPC.

There is a direct API boundary here. The README says SharePoint app-only access requires a certificate and that SharePoint REST API v1 does not accept a client secret. Applications needing secret-based app-only access should use `GraphClient`. Authentication failures can therefore result from choosing a valid Microsoft 365 flow for the wrong client.

Async use and repository examples for first integrations

The README includes an `Async / await` section, confirming that asynchronous usage is part of the library's documented feature set. The displayed README does not include the async code block or the exact client method names, so an application should follow the current async section or the relevant example rather than assume that a synchronous method can simply be renamed. Authentication, request execution, and result retrieval can all affect where an `await` is required.

The repository's `examples/` tree is organized around Microsoft products and operational tasks. This gives a new adopter concrete paths for Outlook, Teams, OneDrive, Entra ID, Intune, Purview, reports, SharePoint, and other services. It also includes authentication, backup and restore, communication, and data examples. The README's service directory points to `examples/sharepoint/` for SharePoint and the broader `examples/` tree for Graph-oriented work.

A first integration should be selected by endpoint and permission model. For SharePoint REST work, begin with `ClientContext`. For a cross-service Microsoft Graph request, begin with `GraphClient`. Then inspect the matching authentication example and ensure the app registration, delegated or application permissions, tenant policy, and target site or service match the request. The package supports Python 3.8 and later, so dependency and type-checking configuration may need review when the host environment is not current.

SharePoint REST API v1 as the alternative to GraphClient

The clearest documented alternative is to choose the other client in the same library. `ClientContext` speaks SharePoint REST API v1, while `GraphClient` speaks Microsoft Graph at `graph.microsoft.com`. This is not a cosmetic naming difference. The former is positioned for SharePoint lists, files, folders, permissions, taxonomy, site and tenant administration, and webhooks. The latter covers Outlook, Teams, OneDrive, OneNote, Planner, To Do, Entra ID, Intune, Purview, reports, security, and other Graph services.

For SharePoint-only work, the README advises preferring `ClientContext` because its SharePoint coverage has higher fidelity. For OneDrive, both clients can address files, but `GraphClient` is described as the modern cross-service path. A single application that combines SharePoint administration with Outlook or Teams operations may need both clients rather than forcing every operation through one interface.

The tradeoff is that an application built around `ClientContext` cannot assume Microsoft Graph semantics, and an application built around `GraphClient` cannot assume complete SharePoint REST coverage. Resource URLs, permissions, response shapes, pagination, and available operations must be checked against the selected API. The repository provides separate API references for SharePoint REST and Microsoft Graph, which reinforces that the client choice defines the service contract.

Release status, licensing, and operational limits

The repository is not archived, and its last push was on 2026-10-13. Recent releases listed in the repository are `v3.2.0` on 2026-09-27, `v3.1.0` on 2026-09-13, and `v3.0.0` on 2026-08-02. The package version in `pyproject.toml` is `3.2.0`. This indicates recent project activity, but users still need to read `CHANGELOG.md` and inspect the relevant release notes before upgrading because API changes, authentication changes, and model changes can affect an integration.

The project uses the MIT license. The package metadata identifies it as `OSI Approved :: MIT License`. That is repository licensing information, not legal advice. The license file should be reviewed for terms that apply to redistribution or incorporation in a particular product.

The main operational limits are service and permission boundaries. Microsoft API availability, tenant configuration, app consent, certificate management, MFA policy, and the retirement of ACS and SAML flows can affect an application even when the Python code is unchanged. The README does not document a rollback procedure, a compatibility matrix for every Microsoft Graph endpoint, or equal coverage across all Microsoft 365 services. The examples and typed models should be checked against the exact endpoint needed before migration.

For a new deployment, pin and review the intended package version, copy `.env.example` when working with the repository's scripts, and run `python -m tests.doctor` after configuring credentials. The examples expect an app registration with tenant, client ID, and admin username, while secrets and passwords must be supplied separately.

Editorial conclusion

Adopt this library when the application targets Microsoft Graph services such as Outlook, Teams, OneDrive, Entra ID, or Intune, or when SharePoint REST API v1 is specifically required. Do not choose it as an abstraction that hides the difference between those APIs or as a replacement for an official Microsoft SDK whose scope has not been checked. Before adoption, verify the required API, authentication flow, tenant permissions, Python version, and the matching file under `examples/`. For SharePoint app-only work, verify certificate access first because SharePoint REST API v1 does not accept a client secret.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vgrem/office365-rest-python-client on GitHub