Direct answer: "Microsoft 365 Backup API" can mean two different architectures. The Microsoft 365 Backup Storage APIs operate Microsoft's native protection and restore service for registered backup applications. General Microsoft Graph workload APIs read supported Microsoft 365 objects so a product can store and restore them through its own architecture. Choose the first when you want Microsoft's protected-service storage and restore model; choose the second only when the product can prove object coverage, storage controls, synchronization, and write-back fidelity.
Architecture Decision Matrix
| Decision | Backup Storage APIs | General Graph extraction |
|---|---|---|
| Primary purpose | Control protection policies, protection units, recovery points, and restore sessions in Microsoft 365 Backup. | Read supported workload objects and, where supported, write restored objects through product-specific workflows. |
| Storage boundary | Data remains within the Microsoft 365 trust boundary and follows the native product model. | Defined by the backup provider; external hosting alone does not prove immutability or an air gap. |
| Supported scope | Microsoft documents Exchange mailboxes, OneDrive accounts, and SharePoint sites. | Endpoint and object specific; no single "Graph backup" permission or fidelity guarantee exists. |
| Retention and recovery points | Defined by Microsoft 365 Backup and documented per workload. | Defined by the product's scheduling, successful collection, storage, and retention implementation. |
| Restore | Microsoft restore-session and workload behavior. | Provider must implement and test every supported destination and conflict path. |
| Best fit | Registered applications building on the native Backup Storage platform. | Products that intentionally operate a separate managed or customer-operated storage architecture. |
Microsoft publishes the current backupRestore resource model under /solutions/backupRestore. It includes service status, protection policies, protection units, restore-point search, restore sessions, and offboarding operations. Eligibility, permissions, API version, regions, and behavior must be checked at implementation time; an old Syntex-era example is not a current specification.
Backup Storage API Control Procedure
- Confirm eligibility and billing: Identify the registered Backup Controller application, owning tenant, billing responsibility, supported market, and current API version.
- Record permissions: Capture delegated or application permissions, administrator consent, granting identity, grant date, and review owner. Use least privilege rather than a broad Global Administrator identity for routine operations.
- Enable and verify service state: Record the returned service status. Do not continue merely because an enable request returned HTTP success.
- Create workload-specific policies: Treat Exchange, OneDrive, and SharePoint policies and protection units separately. Record policy identifiers and lifecycle state.
- Validate protection units: Reconcile intended mailboxes, accounts, and sites against units actually protected. Save failures and exclusions.
- Search recovery points: Retain both search results and protection-unit identifiers for which no recovery point was found.
- Create and activate a restore session: Validate draft state, destination, scope, and operator approval before calling the documented restore-session activation operation.
- Accept the recovery: Verify restored objects and metadata against scenario-specific criteria. API completion is not business acceptance.
General Graph Collection Procedure
General Graph is a collection of workload APIs, not a backup protocol. Required application permissions, pagination, delta support, deletion signals, version access, throttling, and restore writes differ by handler. Maintain an object registry rather than claiming complete coverage at the Exchange, OneDrive, SharePoint, or Teams label.
For each registered object handler:
1. Verify permission and tenant consent.
2. Enumerate the initial collection through every @odata.nextLink.
3. When supported, persist the complete opaque @odata.deltaLink.
4. Record collection start, completion, item count, errors, and usable snapshot ID.
5. On the next run, replay the saved deltaLink without editing its token.
6. If state is invalid or expired, follow the endpoint's documented resynchronization path.
7. Test restore separately; readable data does not prove write-back fidelity.Microsoft's delta query guidance requires clients to follow pagination until a delta link is returned and then reuse that opaque URL. Delta availability and limitations are resource specific. A product must not infer version-history capture, intermediate-state capture, or restore support merely because a drive or list supports delta.
Throttling and Batch Handling
| Condition | Required handling | Evidence |
|---|---|---|
| HTTP 429 | Honor Retry-After where supplied; use documented backoff when it is absent. Do not immediately retry. | Endpoint, tenant, attempt count, wait value, final state. |
| JSON batch | Limit a batch to 20 requests and inspect every inner response. A batch-level 200 does not mean all requests succeeded. | Per-request status and retry queue. |
| Partial pagination | Do not commit a successful baseline until all pages complete or the product explicitly records a partial failure. | Page count, next link, item errors, snapshot state. |
| Permission failure | Stop the affected handler, identify the missing permission, and require approved re-consent. | Error, affected scope, approver, resolution timestamp. |
| Unsupported object | Record an explicit coverage gap; do not silently map it to workload coverage. | Object type, requirement, product decision. |
See Microsoft's current Graph throttling guidance and JSON batching documentation. Microsoft Graph can throttle reads and writes at different thresholds. No backup product should promise zero throttling.
Implementation Evidence Record
| Architecture selected | [Backup Storage API / general Graph / combined product] |
|---|---|
| Version and source check | [API version, official documentation URLs, verification date] |
| Authorization | [App ID, tenant, permission set, consent identity/date, credential owner] |
| Protection or collection state | [Policy/unit or handler/snapshot IDs, timestamps, failures] |
| Recovery test | [Scenario, source point, destination, timing, fidelity, acceptance] |
| Known limitations | [Unsupported object, throttling behavior, export/exit limit, owner] |
North Brook Vault Coverage and Limits
North Brook Vault's published architecture is a managed SaaS service with provider-managed infrastructure and storage and object-specific Microsoft Graph handlers. It supports scheduled full or delta-aware collection where the relevant resource permits it, service-side job monitoring, retention policies, and selective restore for supported handlers. Exact permission and handler support must be validated in the tenant preflight and pilot.
North Brook Vault does not provide customer-operated API infrastructure, customer-selected S3 or on-premises storage, native Object Lock enforcement, OneDrive file version-history capture, PST/PDF/ZIP export, compliance reports, or a zero-throttling guarantee. Teams messages and channel structures may be collected by supported handlers but are not restorable. Review the storage boundary and the operating checklist before approval.
Go/No-Go Decision
Proceed only when the selected architecture has a current permission model, complete protection-unit or object registry, explicit partial-failure handling, a deletion and offboarding path, and a successful representative restore. Reject any proposal that treats an API response, backup job, or workload label as proof of recoverability.
Review managed backup architecture Discuss an API and permission consultation Estimate managed-service pricing