Recovery methodsTechnical

Dropbox, Google Drive and OneDrive Recovery APIs

Provider APIs make large-scale cloud recovery possible by exposing stable object IDs, revision history and change streams — but retention windows and restore capabilities differ by service, plan and account type, so no single API pattern covers every provider the same way.

Dropbox: file IDs and revision lookup

Dropbox's API exposes a filesListRevisions call that can look up an object's revisions either by path or by file ID, and the ID-mode lookup specifically keeps working across moves and renames — a genuinely useful property for recovery, since it means revision history doesn't get orphaned just because a file was reorganized. A matching filesRestore call brings a chosen revision back.

Dropbox: list_folder, DeletedMetadata and cursors

Dropbox's list_folder and its cursor-driven continuation calls can surface DeletedMetadata entries for items known to have been removed, distinct from an item simply not appearing in a listing. Combined with recursive enumeration, this lets a recovery tool build an inventory of what changed across a whole account tree rather than checking one file at a time.

Google Drive: the revisions resource and keepForever

Google Drive's revisions resource supports listing, retrieving, updating and deleting individual revisions of a file, and for binary files a revision can be marked keepForever. Google's own documentation notes that unpinned binary revisions can be automatically purged once newer content is uploaded, with up to 200 revisions eligible to be kept forever per file — so revision availability here is retention-dependent, not an unlimited historical archive.

Google Drive: native documents and binary files aren't identical

Google Docs, Sheets and Slides-native objects have different revision and content semantics from an uploaded binary file stored in Drive, and the API explicitly restricts some revision-deletion and keep-forever behavior to binary content specifically. A recovery process built for one category can behave unexpectedly if pointed at the other.

Google Drive: changes, page tokens and the trashed query

The changes.list and changes.getStartPageToken endpoints track namespace-level evolution, and Drive's search can query trashed = true directly — both useful before assuming a missing file is actually gone. Push notifications only signal that something changed; they carry no file content, metadata or path, so the application still has to query the API afterward.

OneDrive: versions through Microsoft Graph

Microsoft Graph exposes a driveItem versions endpoint for listing a file's previous versions, but Microsoft's own documentation notes that version-creation behavior can vary, retention can be finite, admin settings can differ by user or location, and older versions don't necessarily preserve complete metadata — version history here is a recovery source to check, not a guarantee of permanent history.

OneDrive: delta, deleted facets and resync

Graph's driveItem delta endpoint returns incremental synchronization changes, including a deleted facet for removed items, with nextLink and deltaLink values to page through or resume later. Microsoft documents cases where an old delta token returns 410 Gone and requires a fresh resync — which is why a client relying only on the latest stored token, without its own change records, doesn't have a durable audit trail.

OneDrive: restore API scope is limited

Graph exposes a driveItem restore operation for deleted items, but current documentation notes the direct restore functionality is available only for OneDrive Personal — not universally across OneDrive for Business or SharePoint. "The API can always restore deleted files" is exactly the kind of claim that breaks the moment account type or service changes.

Cross-provider principles that hold regardless of vendor

Authenticate read-only where possible; enumerate objects, deleted states and revisions before writing anything; request the minimum OAuth scope the discovery phase actually needs; and prefer stable, production API surfaces (Graph v1.0 rather than /beta, for instance) over experimental endpoints that can change without notice. This mirrors image-first storage recovery: look and record before you act.

Claim to avoid

"Dropbox, Google Drive and OneDrive APIs have identical restore semantics" is false in ways that matter — retention windows, revision limits and even whether a direct restore endpoint exists at all differ by provider, plan and account type. Confirm the specific service and account's actual capability before designing a recovery workflow around it.