Vercel Port

Purpose

This is the reference integration for Harbor http_api Action Model authoring for Vercel.

Use it when:

• building Vercel actions in Harbor
• extending the Dock / Hub Vercel entry
• teaching Codex or OpenClaw how to map a deployment platform API into Harbor Ports and Harbor Actions

Harbor Port worksheet

Product

• Product: Vercel API
• Publisher slug: vercel
• Publisher name: Vercel
• Category: Infrastructure
• Tags: vercel, deployments, projects, hosting, ci

Safe Harbor Port metadata

• Kind: http_api
• Label: Vercel API
• Description: Vercel API connection managed locally through Harbor.
• Base URL: https://api.vercel.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

Vercel is a good Harbor fit when we stay on fixed project and deployment routes and keep deployment payloads inside input.body.

Good Harbor Vercel actions:

• fixed GET routes like /v10/projects
• stable deployment list routes like /v6/deployments
• fixed POST routes like /v13/deployments
• requestBodyMode: "none" for reads
• requestBodyMode: "json" for deployment creation
• resultMode: "json_summary" for all starter actions

Avoid for now:

• environment variable administration
• domain, team, billing, or firewall configuration surfaces
• large sourceless deployment payload patterns without review
• automatic deployment creation without explicit policy

Starter Vercel actions

Automatic read actions

• list-projects -> GET /v10/projects
• get-deployments -> GET /v6/deployments

Approval-friendly write actions

• create-deployment -> POST /v13/deployments

Why these actions

These routes fit Harbor's Action Model well because they:

• stay under one fixed Vercel API origin
• use stable versioned REST routes
• let Harbor keep deployment creation behind explicit approval
• avoid generic shell or CI proxy behavior
• keep hidden auth entirely local to Harbor Node

Suggested operator workflow

1. Import the Vercel Dock entry from Dock / Hub.
2. Configure the local Vercel API token in Harbor Node.
3. Validate list-projects first to confirm local auth.
4. Use get-deployments to inspect current project state before enabling writes.
5. Keep create-deployment on require_approval unless your Harbor Guard policy deliberately allows the exact deployment flow.

Suggested agent workflow

1. Inspect the existing Vercel Harbor Port.
2. Inspect live actions and drafts.
3. Propose additional fixed-route actions only.
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 API token
• widen Vercel into a generic arbitrary HTTP proxy
• bypass review for deployment-creating actions

Current update strategy

For now, Vercel updates are manual:

• update the Dock / Hub integration document in apps/hub/catalog/integrations/vercel/vercel-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

Official reference starting points

• Vercel REST API overview: https://vercel.com/docs/rest-api
• Vercel list projects: https://vercel.com/docs/rest-api/reference/endpoints/projects/retrieve-a-list-of-projects
• Vercel list deployments: https://vercel.com/docs/rest-api/reference/endpoints/deployments/get-a-list-of-deployments
• Vercel create deployment: https://vercel.com/docs/rest-api/reference/endpoints/deployments/create-a-new-deployment