Dropbox Port

Purpose

This is the Harbor reference integration for the Dropbox API.

Use it when:

• building Dropbox actions in Harbor
• extending the Dock / Hub Dropbox entry
• teaching Codex or OpenClaw how to map a storage API with RPC-style HTTP methods into Harbor Ports and Harbor Actions without turning Harbor into a generic file tunnel

Harbor Port worksheet

Product

• Product: Dropbox API
• Publisher slug: dropbox
• Publisher name: Dropbox
• Category: Storage
• Tags: dropbox, storage, files, folders, productivity

Safe Harbor Port metadata

• Kind: http_api
• Label: Dropbox API
• Description: Dropbox API connection managed locally through Harbor.
• Base URL: https://api.dropboxapi.com/
• Auth mode: header_token
• Auth header name: Authorization
• Auth token prefix: Bearer

Hidden local config

• authToken

Harbor stores the token locally only. Dock / Hub manifests must never contain it.

Harbor action design notes

Dropbox's file methods are RPC-style HTTP routes rather than classic REST paths. They still fit Harbor well because:

• the routes are fixed and reviewable
• each starter action maps to a named Dropbox capability
• Harbor can use bounded JSON request bodies instead of arbitrary URL editing
• the auth model is still a simple bearer token stored locally

Good Harbor Dropbox starter actions:

• fixed POST reads for folder listing and metadata inspection
• explicit POST writes for folder creation
• requestBodyMode: "json" for all starter actions
• resultMode: "json_summary" for all starter actions

Avoid for now:

• content upload and download flows that need other Dropbox API hosts or special transport handling
• giant batch or async job surfaces
• broad file mutation coverage before operator review
• generic request forwarding across the Dropbox API

Starter Dropbox actions

Automatic read actions

• list-folder -> POST /2/files/list_folder
• get-metadata -> POST /2/files/get_metadata

Approval-friendly write actions

• create-folder -> POST /2/files/create_folder_v2

Why these actions

These routes fit Harbor's current safe model well because they:

• cover the operator loop of browsing folders, targeting a file or folder by path, and creating a reviewed folder
• stay on one fixed Dropbox API origin
• use explicit named capabilities instead of arbitrary route input
• keep Dropbox auth entirely local to Harbor Node

Action Model notes

For this Dropbox starter set, execution input goes in input.body.

Example folder listing request:

{
  "body": {
    "path": "",
    "recursive": false,
    "include_deleted": false,
    "include_has_explicit_shared_members": false
  }
}

Example metadata request:

{
  "body": {
    "path": "/Projects/Q2 Plan"
  }
}

Example folder creation request:

{
  "body": {
    "path": "/Projects/New Harbor Folder",
    "autorename": false
  }
}

Keep request bodies bounded to the fields you actually intend to support. For the starter set, the important fields are:

• path
• recursive
• include_deleted
• include_has_explicit_shared_members
• autorename

Suggested operator workflow

1. Import the Dropbox Dock entry from Dock / Hub.
2. Configure the local Dropbox bearer token in Harbor Node.
3. Use list-folder and get-metadata to verify access and resolve target paths first.
4. Keep create-folder on require_approval unless there is a very clear local policy reason not to.

Suggested agent workflow

1. Inspect the existing Dropbox Harbor Port.
2. Inspect live actions and drafts.
3. Propose additional fixed Dropbox methods only when the route and body shape remain bounded and reviewable.
4. Validate and test drafts.
5. Request publish instead of self-publishing unless Harbor explicitly allows it.

Agents should never:

• ask Harbor for the stored Dropbox token
• widen Dropbox into a generic arbitrary file transport surface
• hide Dropbox paths inside unreviewable freeform transport fields
• add upload or download flows without reviewing host, content, and transport implications first

Current update strategy

For now, Dropbox updates are manual:

• update the Dock / Hub Dropbox integration document in apps/hub/catalog/integrations/dropbox/dropbox-api.json
• bump the manifest version when the action set changes materially
• re-import into Harbor or create new drafts from the updated Dock entry

Scope notes

These starter actions typically need:

• files.metadata.read
• files.content.write

The exact Dropbox permission model still depends on whether the app is app-folder scoped or full-Dropbox scoped, so operators should configure the minimum permission set that supports their intended actions.

Official reference starting points

• Dropbox HTTP overview: https://www.dropbox.com/developers/documentation/http/overview
• Dropbox JavaScript SDK reference root: https://dropbox.github.io/dropbox-sdk-js/Dropbox.html
• filesListFolder: https://dropbox.github.io/dropbox-sdk-js/Dropbox.html
• filesGetMetadata: https://dropbox.github.io/dropbox-sdk-js/Dropbox.html
• filesCreateFolderV2: https://dropbox.github.io/dropbox-sdk-js/Dropbox.html