Netlify Port

Purpose

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

Use it when:

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

Harbor Port worksheet

Product

• Product: Netlify API
• Publisher slug: netlify
• Publisher name: Netlify
• Category: Infrastructure
• Tags: netlify, hosting, sites, deployments, build-hooks

Safe Harbor Port metadata

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

Netlify is a good Harbor fit when we stay on fixed site inventory routes and keep writes limited to explicit, reviewable build-hook creation.

Good Harbor Netlify actions:

• stable GET routes like /sites and /sites/{site_id}
• site-scoped deployment reads like /sites/{site_id}/deploys
• fixed POST routes like /sites/{site_id}/build_hooks
• requestBodyMode: "none" for reads
• requestBodyMode: "json" for build-hook creation
• resultMode: "json_summary" for all starter actions

Avoid for now:

• full deploy upload flows
• environment-variable management
• DNS, SSL, service-instance, and team administration surfaces
• broad build execution or ZIP upload automation without review

Starter Netlify actions

Automatic read actions

• list-sites -> GET /sites
• get-site -> GET /sites/{site_id}
• list-site-deploys -> GET /sites/{site_id}/deploys

Approval-friendly write actions

• create-build-hook -> POST /sites/{site_id}/build_hooks

Why these actions

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

• stay under one fixed Netlify API origin
• use stable REST paths with clear site scoping
• provide enough visibility to inspect hosting state before writes
• keep the write path narrow and easily reviewable
• keep hidden auth entirely local to Harbor Node

Suggested operator workflow

1. Import the Netlify Dock entry from Dock / Hub.
2. Configure the local Netlify personal access token in Harbor Node.
3. Validate list-sites first to confirm local auth.
4. Use get-site and list-site-deploys to inspect site state and recent deploy history.
5. Keep create-build-hook on require_approval unless your Harbor Guard policy deliberately permits that exact automation path.

Suggested agent workflow

1. Inspect the existing Netlify Harbor Port.
2. Inspect live actions and drafts.
3. Propose additional fixed-route site or deploy 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 Netlify into a generic arbitrary HTTP proxy
• bypass review for deploy-adjacent write actions

Current update strategy

For now, Netlify updates are manual:

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

• Netlify API getting started: https://docs.netlify.com/api-and-cli-guides/api-guides/get-started-with-api/
• Netlify OpenAPI reference: https://open-api.netlify.com/
• Netlify site endpoints: https://open-api.netlify.com/
• Netlify build hook endpoints: https://open-api.netlify.com/