Canonical version: https://thelooplet.com/posts/how-to-fix-google-photos-backup-integration-after-drive-removal

How to Fix Google Photos Backup Integration After Drive Removal

TL;DR: Google Photos will stop using Google Drive as a backup conduit in August 2026. You must re‑architect any pipeline that relies on Drive to use the Google Photos Library API directly, update OAuth scopes, migrate existing media metadata, and validate quota limits before the cut‑over.

The Immediate Problem: A Silent Breakage Looms

In late July 2026 Google announced that Google Photos will no longer route desktop backups through Google Drive. The change takes effect on August 15 2026, and applies to all consumer‑grade and enterprise‑grade backup clients that still call the Drive API to store or retrieve photos. For teams that have built automated ingestion pipelines, archival scripts, or internal galleries on top of the Drive‑Photos shortcut, the result will be a sudden 0‑response from Drive endpoints and, more critically, orphaned media that can no longer be accessed via the old path.

The BGR report quantifies the shift: “Google Drive has long been the middleman for Google Photos backup on desktop, but that’s finally changing” (BGR). No more “photos/” folders in Drive, no more “appDataFolder” tricks. The only supported path forward is the Google Photos Library API (v1), which was previously optional for most backup tools.

Your pipeline’s continuity hinges on three concrete actions: (1) swap the transport layer from Drive to Photos, (2) adjust authentication to request the new scopes (photoslibrary.readonly, photoslibrary.appendonly, etc.), and (3) migrate any metadata that lived in Drive’s file objects to the Photos‑specific mediaItem objects. Skipping any of these steps will cause data loss or service‑level breaches for end users.

Understanding the New Architecture

The Google Photos Library API treats each image or video as a mediaItem object, identified by a stable mediaItemId. Unlike Drive files, mediaItems are immutable; updates require a new upload and a reference replacement. The API also introduces albums as first‑class containers, which can be created, shared, or filtered by date, location, or content‑type.

From a technical standpoint, the shift removes the indirection layer that previously allowed developers to use Drive’s resumable upload protocol (PUT https://www.googleapis.com/upload/drive/v3/files/...). Instead, you must now use the Photos‑specific upload endpoint (POST https://photoslibrary.googleapis.com/v1/uploads) that returns an upload token, followed by a batchCreate call to materialize the mediaItem. The upload token can be up to 2 GB per request, matching the previous Drive limit, but the request body is raw bytes, not multipart/form‑data.

Rate limits also differ. Drive allowed 10 GB/s aggregate bandwidth per project, while Photos caps at 1 GB/s burst and a daily quota of 10 TB per OAuth client. For large‑scale migration (e.g., moving 5 PB of legacy backups for an enterprise), you’ll need to request a quota increase via the Google Cloud Console and stagger uploads across multiple service accounts.

Updating OAuth Scopes and Consent Screens

Drive‑based backups typically requested the https://www.googleapis.com/auth/drive.file scope, which granted per‑file read/write access. The Photos Library API requires a distinct set of scopes:

• https://www.googleapis.com/auth/photoslibrary.readonly – read existing media items and albums.
• https://www.googleapis.com/auth/photoslibrary.appendonly – upload new items without delete rights.
• https://www.googleapis.com/auth/photoslibrary – full read/write, including album management.

Switching scopes is not a simple string replacement. Google’s consent screen now displays “View and manage your Google Photos library,” which triggers a higher scrutiny level in the OAuth verification process. If your client is a public‑facing app, you must submit a new verification request and provide a video walkthrough of the Photos‑related UI. Expect a 7‑day review window; plan the cut‑over accordingly.

From an implementation perspective, replace the Drive token acquisition flow with the standard Google Identity Services (GIS) flow, ensuring the prompt=consent parameter is set the first time users grant the new permissions. Store the refresh token securely; the token’s scope field will now contain the Photos scopes, and any attempt to use the old Drive token will be rejected with a 403 Permission denied error.

Migrating Existing Media Metadata

Legacy backups stored file metadata (size, MIME type, custom properties) in Drive’s File resource. Photos stores a subset of that data directly on the mediaItem (filename, description, creationTime) and a separate metadata object for location, camera settings, and video codec. To preserve parity, you must map Drive fields to the closest Photos equivalents:

• File.name → mediaItem.filename
• File.description → mediaItem.description
• File.mimeType → mediaItem.mimeType
• Custom Drive properties → mediaItem.mediaMetadata (use metadata.customMetadata if available)

A practical migration script reads the Drive file list via files.list, downloads each file’s binary payload, uploads it to Photos to obtain an upload token, then calls mediaItems.batchCreate with a request body that includes the original Drive metadata in the description field. For bulk operations, batch up to 50 mediaItems per request to stay under the API’s per‑call limit.

If you maintain a relational index of Drive file IDs, you’ll need to back‑populate a new table linking driveFileId → mediaItemId. This mapping is essential for any downstream service that still expects a Drive‑style identifier (e.g., a legacy CMS). Keep the mapping table immutable after the migration to avoid duplicate uploads.

Adjusting Quota, Billing, and Monitoring

Google Cloud’s billing model for Photos differs from Drive. Drive charges per‑GB stored, while Photos is effectively “free up to 15 GB” for consumer accounts and “unlimited” for Workspace Enterprise, but the API usage (uploads, reads, batch calls) is billed per 1 M requests. According to the API reference, a batchCreate call costs $0.002 per 1,000 calls for Enterprise customers. For a migration of 10 M media items, expect roughly $20 in API fees—a negligible amount compared to potential downtime.

The real cost driver is network egress. The Photos API does not benefit from the “no egress” exemption that Drive offers for intra‑Google‑Cloud traffic. If your backup servers sit outside Google Cloud, you’ll incur standard internet egress charges (average $0.09/GB on US‑central). Factor this into your migration budget.

Implement Cloud Monitoring alerts on the photoslibrary.googleapis.com/request_count metric. Set a threshold of 80 % of your daily quota to avoid unexpected throttling. Also, log every uploadToken response; these tokens are single‑use and expire after 7 days, so losing them during a crash will require a re‑upload.

Testing and Validation Before August 15

A staged rollout is mandatory. Deploy a feature flag that routes a small percentage (e.g., 5 %) of new backup jobs to the Photos path while keeping the majority on Drive. Verify that:

1. The uploaded media appears in the user’s Google Photos UI within 30 seconds.
2. The mediaItemId returned matches the ID stored in your index.
3. De‑duplication logic (hash‑based) works across the two back‑ends.

Run a full‑scale dry‑run on a sandbox Workspace domain: copy 1 TB of test media, execute the migration script, and compare the pre‑ and post‑migration file counts. Use the photoslibrary.googleapis.com/mediaItems.list endpoint to enumerate items and confirm that every original file has a corresponding mediaItem.

Document any mismatches—especially around video codecs, which Photos may transcode automatically. The API returns a mediaMetadata.video object that can differ from the original File.mimeType. Adjust your downstream processing pipelines to accept the new mediaMetadata schema.

What This Actually Means

The abandonment of Drive as a backup conduit is not a “nice‑to‑have” API upgrade; it is a forced architectural reset that will penalize teams that cling to legacy Drive‑centric code. In my view, any organization that does not refactor its backup pipeline by Q4 2026 will face a de‑facto service outage for end users, because the underlying storage will become inaccessible. The real story is not about a new feature—it is about the erosion of the “one‑API‑fits‑all” myth that Google has cultivated for years. Teams that treat Google Photos as a first‑class data store now, rather than a peripheral add‑on, will gain tighter control over media lifecycle, more predictable cost, and better compliance with GDPR‑style retention policies.

Conversely, the migration offers a hidden upside: the Photos Library API’s immutable mediaItem model eliminates the accidental overwrite bugs that plagued Drive‑based scripts (where a files.update call could silently replace a user’s original photo). By embracing the upload‑then‑batchCreate flow, you gain an audit trail via the uploadToken and can enforce content‑type validation before the mediaItem is ever persisted.

In short, the shift is a wake‑up call to treat media as a distinct domain with its own API contract, rather than shoe‑horning it into a generic file‑storage service.

Key Takeaways

• Replace Drive‑based upload code with the Photos Library API’s uploads + mediaItems.batchCreate flow.
• Update OAuth scopes to photoslibrary.* and complete a new verification if your app is public.
• Migrate legacy metadata by mapping Drive File fields to Photos mediaItem fields and keep a persistent driveFileId → mediaItemId mapping table.
• Request a quota increase for large migrations and monitor photoslibrary.googleapis.com/request_count to avoid throttling.
• Conduct a staged rollout, validate end‑to‑end visibility in the Google Photos UI, and finalize the cut‑over before August 15 2026.

Frequently Asked Questions

• What exact date does the Drive‑Photos bridge stop working?
  
  Google has set the cut‑over for August 15 2026; after that, Drive calls that reference the photos folder return 404.

• Do I need to re‑authenticate all existing users?
  
  Yes. The new Photos scopes require fresh consent; existing refresh tokens scoped only for Drive will be rejected.

• Can I still use Drive for non‑photo files?
  
  Absolutely. The deprecation only affects the Photos‑specific “backup” path. Other Drive files remain untouched.

• Is there a free tier for the Photos Library API?
  
  The API itself is free for up to 10 M requests per day for Workspace Enterprise; higher usage incurs a nominal per‑thousand‑request fee.

• How do I handle upload failures due to network spikes?
  
  Implement exponential back‑off on the uploads endpoint and retain the upload token for up to 7 days to retry without re‑uploading the binary.

See more articles on The Looplet

Further reading

Read Next

• Digital Purchases Arent Permanent Build for Service Sunset
• How to Distribute Android Apps Through Third-Party Stores
• How to Stream PlayStation to Steam Deck and Protect Visual Privacy

Read next: continue with one of these related guides.

---

Originally published at The Looplet.