Class DropboxProvider

constructor

• new DropboxProvider(options?: DropboxProviderOptions): DropboxProvider

  Parameters

  • Optionaloptions: DropboxProviderOptions

  Returns DropboxProvider

Readonlyauth

Readonlymanifest

download

• download(
      ctx: PluginContext,
      ref: SourceFileRef,
      options?: DownloadOptions,
  ): Promise<ArrayBuffer>

  Downloads a file's bytes via files/download on content.dropboxapi.com — a direct, authenticated, non-redirecting POST (see the citation on downloadContent() in http-client.ts), never a pre-signed URL the way Microsoft Graph requires.

  A revisionId is honored directly: Dropbox's path argument accepts the form "rev:<rev-id>" to address a specific historical revision (the separate, older rev request parameter on this endpoint is deprecated in favor of embedding it in path — Dropbox Community guidance and dropbox/revision-browser's reference implementation, checked 2026-08-15). A rev string is globally unique to one file's one revision, so this needs no separate metadata lookup the way source-msgraph's download() does to validate ref.revisionId against the item's current one — an invalid or mismatched rev is rejected by Dropbox itself (surfaced here as a DropboxHttpError) rather than silently serving the wrong bytes.

  Parameters

  • ctx: PluginContext
  • ref: SourceFileRef
  • Optionaloptions: DownloadOptions

  Returns Promise<ArrayBuffer>

listContainers

• listContainers(
      ctx: PluginContext,
      _projectId: string,
      parentId?: string,
      options?: ListOptions,
  ): Promise<Page<SourceContainer>>

  List containers within a project. parentId omitted means top level.

  The shape of the result is governed by capabilities.containerListing: direct-children returns only immediate children, flat-subtree returns the whole descendant set flattened with parentId links intact.

  Parameters

  • ctx: PluginContext
  • _projectId: string
  • OptionalparentId: string
  • Optionaloptions: ListOptions

  Returns Promise<Page<SourceContainer>>

listFiles

• listFiles(
      ctx: PluginContext,
      _projectId: string,
      containerId: string,
      filter?: FileFilter,
      options?: ListOptions,
  ): Promise<Page<SourceFile>>

  List files in a container. Whether descendants are included is governed by capabilities.listFilesIsRecursive.

  Parameters

  • ctx: PluginContext
  • _projectId: string
  • containerId: string
  • Optionalfilter: FileFilter
  • Optionaloptions: ListOptions

  Returns Promise<Page<SourceFile>>

listProjects

• listProjects(
      ctx: PluginContext,
      options?: ListProjectsOptions,
  ): Promise<Page<SourceProject>>

  List projects visible to the authenticated identity.

  Providers reporting projectsAreDiscoverableOnly may return a partial or empty page when query is absent; the host then prompts the user to search or paste a URL rather than presenting the result as complete.

  Parameters

  • ctx: PluginContext
  • Optionaloptions: ListProjectsOptions

  Returns Promise<Page<SourceProject>>

listRevisions

• listRevisions(
      ctx: PluginContext,
      ref: SourceFileRef,
      options?: ListOptions,
  ): Promise<Page<SourceRevision>>

  files/list_revisions does paginate, just not via an opaque cursor token the way files/list_folder/search_v2 do: Dropbox's ListRevisionsResult.has_more and ListRevisionsArg.before_rev (its files.stone API spec) form a real continuation mechanism — "Call list_revisions again with before_rev equal to the revision of the last returned entry to retrieve the rest." Revisions come back newest-first (see provider.test.ts), so the last entry of a page is its oldest, and before_rev set to that rev asks for the next-older page. This provider surfaces that as Page.cursor like every other paged method here: the opaque value it hands back is simply the last entry's rev, and options?.cursor is forwarded straight through as before_rev (before_rev is only honored in mode: 'path', which this call already uses). limit is capped at 100, not files/list_folder's 2000 — see clampRevisionsPageSize.

  Parameters

  • ctx: PluginContext
  • ref: SourceFileRef
  • Optionaloptions: ListOptions

  Returns Promise<Page<SourceRevision>>

searchFiles

• searchFiles(
      ctx: PluginContext,
      _projectId: string,
      query: string,
      filter?: FileFilter,
      options?: ListOptions,
  ): Promise<Page<SourceFile>>

  Optional: server-side file search within a project.

  Parameters

  • ctx: PluginContext
  • _projectId: string
  • query: string
  • Optionalfilter: FileFilter
  • Optionaloptions: ListOptions

  Returns Promise<Page<SourceFile>>

testConnection

• testConnection(ctx: PluginContext): Promise<ConnectionTestResult>

  Optional: test the connection and return a diagnostic message.

  Parameters

  • ctx: PluginContext

  Returns Promise<ConnectionTestResult>

watchRevisions

• watchRevisions(
      ctx: PluginContext,
      refs: readonly SourceFileRef[],
      cursor?: string,
      options?: ListOptions,
  ): Promise<RevisionWatchResult>

  Watches for changes via files/list_folder/continue's cursor, Dropbox's change-feed equivalent of Graph's /delta (per the manifest's changeDetection doc comment) rather than polling the given refs.

  With no cursor yet, this establishes one via files/list_folder/get_latest_cursor (recursive: true at the account root) — a dedicated endpoint that returns only a cursor, with no entries fetched, so establishing a baseline doesn't cost sweeping the whole account. That first call reports no events (nothing has "changed" relative to a baseline just established); only subsequent calls, passing that cursor back in, report real deltas.

  Documented limitation: Dropbox's DeletedMetadata (what a deleted entry decodes to — see dropbox-types.ts) carries no id field, only name/path_lower. This provider addresses every tracked SourceFileRef by opaque id (see pathArgFor's doc comment), so a deletion reported by the cursor feed cannot be matched back to a tracked ref by id — deleted entries are therefore silently skipped rather than guessed-matched by name/path, which could misfire on a same-named file elsewhere. Updates and new content are unaffected: FileMetadata entries always carry id. A host relying on this provider for deletion detection specifically should not assume it fires.

  Parameters

  • ctx: PluginContext
  • refs: readonly SourceFileRef[]
  • Optionalcursor: string
  • Optionaloptions: ListOptions

  Returns Promise<RevisionWatchResult>