How to Integrate Google Drive, SharePoint, and Box: What It Really Takes

Building integrations for Google Drive, SharePoint, and Box sounds straightforward on paper. You authenticate the user, list the files, and download the content. In reality, file storage APIs are a maze of undocumented edge cases, fragmented authentication flows, and complex UI requirements.

If you want to provide a high-quality user experience, you cannot just build a custom dropdown menu of files. You must implement the native file pickers from each vendor. This forces your engineering team to bridge frontend UI components with backend OAuth flows, handle chunked uploads for large files, and normalize entirely different data models.

Here is a technical breakdown of what it actually takes to integrate Google Drive, SharePoint, and Box individually, followed by an objective look at how a unified file storage API changes the architecture.

The Deceptive Complexity of Native File Pickers

A native file picker is a vendor-provided UI component that allows users to browse, search, and select files directly from their cloud storage within your application.

Implementing them is mandatory for user trust and UX, but it introduces immediate architectural friction. You are no longer just making backend HTTP requests; you are embedding third-party JavaScript or iframes into your frontend and securely passing access tokens between the client and server.

Google Drive: The Picker API and Export Quirks

Google separates its UI and data layers. To build a proper integration, you must enable both the Google Drive API and the Google Picker API in your Google Cloud Console.

The Auth Handoff: The Google Picker runs on the frontend. Once a user selects a file, the picker returns the file ID. However, to actually download or manipulate that file, your backend needs the OAuth access token. You must carefully pass this token from your frontend to your backend or retrieve it from your secure session store before making the request with the Authorization: Bearer {token} header.

The MIME Type Trap: You cannot directly download Google Workspace documents (Google Docs, Sheets, Slides) using the standard alt=media query parameter.

// This works for standard files (PDFs, images)
const response = await drive.files.get({
  fileId: '12345',
  alt: 'media'
});
 
// This will FAIL for a Google Doc. You must use the export method instead.
const response = await drive.files.export({
  fileId: '12345',
  mimeType: 'application/pdf' // Must specify a conversion format
});

SharePoint & OneDrive: The v8 Picker and Graph API Maze

Microsoft recently migrated developers to the OneDrive File Picker v8. Older versions relied on a simple JavaScript SDK, but v8 shifted to an iframe-based architecture that requires MSAL.js (Microsoft Authentication Library) for token management.

Multi-Tenant Headaches: To use the v8 picker in a B2B SaaS product, your Azure AD app registration must be configured for "Accounts in any organizational directory (Any Azure AD directory - Multitenant)". You are responsible for handling the token acquisition via MSAL and passing it into the iframe via postMessage.

Chunked Uploads: Microsoft Graph API is notoriously strict about file sizes. You can upload files up to 250MB in a single PUT request. If a file is 251MB, the request will fail.

// You must create an Upload Session for large files
POST /drives/{drive-id}/items/{item-id}/createUploadSession

You then have to slice the file on your backend and upload it in sequential byte chunks, handling retries for any network interruptions.

Box: UI Elements and Strict Token Scopes

Box provides React components via NPM (box-ui-elements) for their Content Picker. While the developer experience is generally better than Microsoft's, Box enforces strict security boundaries.

Token Exchange: You should never pass a master Box OAuth token to the frontend. Instead, you must use Box's Token Exchange endpoint to generate a downscoped token that only has access to the specific folder the user is browsing.

Additionally, Box splits its API traffic. Standard metadata requests go to api.box.com, but file uploads must be routed to upload.box.com. Mixing these up will result in frustrating CORS errors or 404s.

The Case for a Unified File Storage API

If your product roadmap requires integrating all three of these platforms, your engineering team will spend months normalizing these quirks. You have to build an abstraction layer that translates Google's files.export, Microsoft's createUploadSession, and Box's upload.box.com into a single internal service.

This is exactly what a Unified API does. By using Truto's Unified File Storage API, you interact with a single, normalized schema.

Normalizing the Data Model

Truto abstracts the underlying storage systems into two primary resources: Drives and Drive Items.

• Drives: A collection of files and folders. A user might have access to multiple Drives (e.g., their personal OneDrive and a shared SharePoint Document Library).
• Drive Items: The actual files and folders. Truto normalizes the metadata, allowing you to differentiate between a file and a folder simply by checking the type attribute.

{
  "id": "normalized_id_123",
  "name": "Q4_Report.pdf",
  "type": "file",
  "size": 1048576,
  "parent_id": "normalized_folder_456"
}

Handing the Native Pickers

Instead of implementing Google Picker, Microsoft v8 Picker, and Box UI Elements separately, Truto embeds these native experiences directly into the Truto Link SDK. When your user connects their account, they interact with the vendor's native UI (ensuring security and familiarity), but your backend only receives standard Truto IDs.

Recent updates to the Truto Link SDK even enable folder selection as the default behavior across Google Drive and SharePoint, eliminating another layer of configuration.

Permissions and Webhooks

Checking who has access to a file is drastically different across platforms. Truto provides a unified Permissions resource, allowing you to query user access levels without writing platform-specific logic.

Similarly, Truto normalizes event streaming. Instead of configuring Google Push Notifications, Microsoft Delta Queries, and Box Webhooks, you subscribe to a single Truto webhook endpoint that emits standardized events when files are created or modified.

The Trade-offs: Radical Honesty

Using a unified API is not a magic fix for everything. You are trading granular, vendor-specific control for engineering velocity.

If your core product is a dedicated Google Drive management tool that requires deep manipulation of Google-specific sharing permissions and internal Workspace metadata, a unified API might abstract away the exact features you need.

However, if file storage is just a feature of your product—for example, you are building an ATS that needs to pull resumes from a candidate's cloud storage, or an AI tool that ingests documents for RAG (Retrieval-Augmented Generation)—building these integrations from scratch is a massive waste of engineering resources.

Strategic Next Steps

Building file storage integrations in-house means committing to a permanent maintenance burden. APIs deprecate (as seen with Microsoft's v8 picker), rate limits change, and your engineering team becomes responsible for maintaining infrastructure that doesn't differentiate your core product.

Evaluate your use case. If you just need to list, upload, and download files reliably across multiple vendors, offload that complexity.