Slack Web Port

Purpose

This is the Harbor reference integration for the Slack Web API.

Use it when:

• building Slack actions in Harbor
• extending the Dock / Hub Slack entry
• teaching Codex or OpenClaw how to map an RPC-style API into Harbor Ports and Harbor Actions without turning Harbor into a generic chat proxy

Harbor Port worksheet

Product

• Product: Slack Web API
• Publisher slug: slack
• Publisher name: Slack
• Category: Messaging
• Tags: slack, messaging, chat, collaboration, workspace

Safe Harbor Port metadata

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

Slack's Web API is HTTP-based but RPC-style rather than strictly REST-shaped. It still fits Harbor well because:

• every starter action stays on one fixed origin
• method URLs are explicit and reviewable, like /conversations.list
• query inputs can be typed with Harbor's Action Model
• write methods such as chat.postMessage can use bounded JSON bodies
• Harbor never needs to expose raw auth or arbitrary full-route editing

Good Harbor Slack starter actions:

• fixed GET reads for workspace conversations and user lists
• explicit POST writes for message posting
• requestBodyMode: "none" for reads
• requestBodyMode: "json" for writes
• resultMode: "json_summary" for all starter actions

Avoid for now:

• giant Slack admin surfaces
• generic method-forwarding across the whole Slack API
• broad write coverage before operator review
• freeform transport escape hatches instead of typed query inputs and bounded JSON request bodies

Starter Slack actions

Automatic read actions

• list-conversations -> GET /conversations.list
• list-users -> GET /users.list

Approval-friendly write actions

• post-message -> POST /chat.postMessage

Why these actions

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

• cover the basic operator loop of finding conversations, resolving users, and sending a reviewed message
• keep the route surface small and explicit
• use Harbor's Action Model for typed pagination and filter values
• map cleanly to Slack's bearer-token auth model
• give Harbor an immediately useful messaging integration without becoming a generic Slack method executor

Action Model notes

At execution time, callers should supply values by location:

• input.query for list-conversations and list-users
• input.body for post-message

Example conversation listing request:

{
  "query": {
    "limit": 100,
    "exclude_archived": true,
    "types": "public_channel,private_channel"
  }
}

Example Slack user listing request:

{
  "query": {
    "limit": 50,
    "include_locale": true
  }
}

Example Slack message post request:

{
  "body": {
    "channel": "C0123456789",
    "text": "Hello from Harbor",
    "thread_ts": "1713472452.123456"
  }
}

For post-message, keep the JSON body bounded to the fields you actually intend to use, such as:

• channel
• text
• thread_ts
• reply_broadcast
• parse
• unfurl_links
• unfurl_media

Suggested operator workflow

1. Import the Slack Dock entry from Dock / Hub.
2. Configure the local Slack bearer token in Harbor Node.
3. Validate that the token has the Slack scopes needed for the actions you want to use.
4. Use list-conversations to discover channel IDs and list-users to inspect workspace users first.
5. Keep post-message on require_approval unless there is a clear local policy reason not to.

Suggested agent workflow

1. Inspect the existing Slack Harbor Port.
2. Inspect live actions and drafts.
3. Propose additional fixed Slack methods only when they 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 Slack token
• widen Slack into a generic method-forwarding proxy
• hide Slack method names behind vague labels
• add broad write or admin coverage without review

Current update strategy

For now, Slack updates are manual:

• update the Dock / Hub Slack integration document in apps/hub/catalog/integrations/slack/slack-web-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 usually need:

• channels:read
• groups:read
• im:read
• mpim:read
• users:read
• chat:write

The exact scope mix depends on which conversation types and write flows the local operator wants to enable.

Official reference starting points

• Slack Web API overview: https://docs.slack.dev/apis/web-api/
• Slack OAuth install flow: https://docs.slack.dev/authentication/installing-with-oauth/
• conversations.list: https://docs.slack.dev/reference/methods/conversations.list/
• users.list: https://docs.slack.dev/reference/methods/users.list/
• chat.postMessage: https://docs.slack.dev/reference/methods/chat.postMessage/