How do I mock the Google Drive API locally?

Install stunt, add a one-service block to stunt.yaml (adapter: embedded:drive-style), and run stunt up. You get a local, stateful stand-in for Google Drive API v3 — 13 routes over rest — with no remote account, no network, and no bills.

Is the Google Drive API mock data synthetic?

Yes — entirely. The adapter returns generated data only; stunt's adapter lint rejects real-looking secrets and PII at build time. It simulates the shape and behavior of Google Drive API (routes, status codes, pagination, webhooks), never real records.

← all adapters

drive-style

simulates Google Drive API v3

restadapter v0.2.013 routes

verification

SDKverified with google-api-go-client v0.293.0· surface 13 · not implemented 7 · differs 5

use it

# add to stunt.yaml
services:
  drive:
    adapter: embedded:drive-style

# then
$ stunt up

The embedded: source extracts this adapter from the binary — no git clone, fully offline.

how to mock the Google Drive API locally

Install stunt, paste the service block above into stunt.yaml, run stunt up — then point your client at localhost instead of Google Drive API. It works offline, keeps state across requests and restarts, and every response is synthetic: the route shapes, status codes, pagination, and webhook delivery follow the real Google Drive API v3 surface — the data is fake, the behavior is real.

backing stores

files

api surface (13)

generated from the adapter manifest — exactly what boots, nothing more · covers 12% of the real API's 64 routes (derived from sdk google-api-go-client @ v0.293.0)

13 routes

GET/o/oauth2/auth

POST/o/oauth2/token

POST/upload/drive/v3/files

PUT/upload/drive/v3/files/{upload_id}

DELETE/upload/drive/v3/files/{upload_id}

GET/drive/v3/files

POST/drive/v3/files

GET/drive/v3/files/{id}

PATCH/drive/v3/files/{id}

DELETE/drive/v3/files/{id}

GET/drive/v3/about

GET/drive/v3/changes/startPageToken

GET/drive/v3/changes

SDK-verified behaviors (8)

✓Files.List returns the seeded folder
✓Files.Create + Files.List round-trip
✓Files.Get returns the created metadata (int64 size decodes)
✓Files.Update renames the file
✓Files.List q= filters by mimeType and parents
✓Files.List PageSize + PageToken walk pages
✓Files.Delete then Get -> googleapi 404
✓Changes.List replays mutations from startPageToken

Not implemented (7)

No permissions/sharing endpoints on files (GET/POST/DELETE permissions)
No comments or replies endpoints (/files/{id}/comments)
No file copy (POST /files/{id}/copy) or export (GET /files/{id}/export)
No revisions endpoints (/files/{id}/revisions)
No shared drives endpoints (/drives); no supportsAllDrives handling
No push notification channels (files.watch, changes.watch, channels/stop)
No generateIds, apps list, or batch (multipart/mixed) request support

Differs from the real API (5)

uploads take JSON {name, content, parents}; real Drive uses multipart/related bodies
list q is a limited field/op subset; queries outside it 400 rather than running
orderBy honors only the first recognized key; real Drive applies every key
metadata-only files.create defaults mimeType to the folder type when absent; real Drive defaults to a plain file
?alt=media on a content-less file returns 404; real Drive serves 200 with an empty body

full scorecard →

want more of the Google Drive API surface? adapters are YAML + Starlark — the authoring guide covers adding routes, fixtures, and state machines. Open an issue for anything big first, or just file a PR — merged routes ship in the next release.