← all adapters

dropbox-style

simulates Dropbox API 2

restadapter v0.1.08 routes

verification

VMVM tier — no SDK suite yet· surface 8 · not implemented 8 · differs 4

use it

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

# then
$ stunt up

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

how to mock the Dropbox API locally

Install stunt, paste the service block above into stunt.yaml, run stunt up — then point your client at localhost instead of Dropbox 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 Dropbox API 2 surface — the data is fake, the behavior is real.

backing stores

entries

api surface (8)

generated from the adapter manifest — exactly what boots, nothing more · covers 11% of the real API's 72 routes (derived from spec dropbox-api-spec files.stone + users.stone (every route POST — API v2 is RPC-style, Stone declares no verb))

8 routes
POST/2/files/upload
POST/2/files/download
POST/2/files/list_folder
POST/2/files/get_metadata
POST/2/files/create_folder
POST/2/files/delete
POST/2/files/get_temporary_link
POST/2/users/get_current_account

VM-verified behaviors (17)

  • upload takes the JSON {path, content} convenience body (documented deviation)
  • the real RPC upload (Dropbox-API-Arg header + raw octet-stream body) lands identically
  • re-uploading an existing path answers the real mode:"add" conflict
  • mode overwrite replaces in place; autorename forks a suffixed path
  • list_folder returns the whole path-prefix subtree, not one level
  • the root listing spans everything; unknown and file paths carry distinct 409 tags
  • paging slices the filtered subtree by body cursor, ignoring query strings
  • download streams raw bytes by path and by id, with metadata alongside
  • folders and unknown paths decline under the 409 path envelope
  • get_temporary_link pairs the file's metadata with the synthetic link
  • a presented bearer must be registered: unknown and expired tokens get distinct 401 tags
  • an absent Authorization header stays open (documented deviation)
  • create_folder mints folder metadata and conflicts case-insensitively
  • get_current_account returns the synthetic /2/users snapshot
  • deleting a folder removes its entire subtree from every read path
  • trash tombstones audit the exact cascade batch
  • delete is permanent: a re-created path is a brand-new entry

Not implemented (8)

  • No move or copy endpoints (/2/files/move_v2, /2/files/copy_v2)
  • No upload sessions for large files (/2/files/upload_session/*)
  • No file search (/2/files/search_v2)
  • No thumbnails or previews (get_thumbnail_b64, get_preview)
  • No shared links or sharing folder endpoints (/2/sharing/*)
  • No file history (list_revisions, restore, copy_reference)
  • No users/get_space_usage or users/get_account batch
  • No /2/files/list_folder/continue or list_folder/get_latest_cursor

Differs from the real API (4)

  • requests with no Authorization header are accepted; real Dropbox requires auth
  • upload takes JSON {path, content}; real /2/files/upload posts raw bytes + Dropbox-API-Arg
  • list_folder returns the entire path-prefix subtree in one response
  • get_temporary_link mints a synthetic URL that does not serve the content
want more of the Dropbox 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.