Sentry Port

Purpose

This is the Harbor reference integration for the Sentry REST API.

Use it when:

• building Sentry actions in Harbor
• extending the Dock / Hub Sentry entry
• teaching Codex or OpenClaw how to map an error-triage API into Harbor Ports and Harbor Actions without turning Harbor into a generic observability admin proxy

Harbor Port worksheet

Product

• Product: Sentry REST API
• Publisher slug: sentry
• Publisher name: Sentry
• Category: Observability
• Tags: sentry, errors, issues, monitoring, triage

Safe Harbor Port metadata

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

Sentry is a good Harbor fit when we keep organization targeting explicit, issue filters typed, and resolution writes reviewable.

Good Harbor Sentry starter actions:

• fixed GET reads for organization project inventory
• bounded GET issue listing with typed filters for project, query, time range, and pagination
• one reviewable PUT route for issue resolution
• requestBodyMode: "none" for reads
• requestBodyMode: "json" for the bounded resolve request body
• resultMode: "json_summary" for all starter actions

Avoid for now:

• broad organization admin or team-management surfaces
• arbitrary metric, discover, or search passthroughs
• bulk issue mutations and delete flows before policy review
• generic route forwarding across the whole Sentry API

Starter Sentry actions

Automatic read actions

• list-projects -> GET /api/0/organizations/{organizationIdOrSlug}/projects/
• list-issues -> GET /api/0/organizations/{organizationIdOrSlug}/issues/

Approval-friendly write actions

• resolve-issue -> PUT /api/0/organizations/{organizationIdOrSlug}/issues/{issueId}/

Why these actions

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

• stay on stable REST endpoints under one fixed Sentry API origin
• keep organization and issue targeting explicit through bounded path templates
• use typed query parameters for reviewable issue triage instead of arbitrary search forwarding
• expose issue resolution as a named capability instead of generic authenticated HTTP access

Action Model notes

At execution time, callers supply values by location:

• input.path.organizationIdOrSlug for all starter actions
• input.query for list-projects and list-issues
• input.path.issueId for resolve-issue
• input.body for the issue update payload

Example project listing request:

{
  "path": {
    "organizationIdOrSlug": "acme"
  }
}

Example issue listing request:

{
  "path": {
    "organizationIdOrSlug": "acme"
  },
  "query": {
    "query": "is:unresolved level:error",
    "statsPeriod": "24h",
    "limit": 25
  }
}

Example resolve request:

{
  "path": {
    "organizationIdOrSlug": "acme",
    "issueId": "1234567890"
  },
  "body": {
    "status": "resolved"
  }
}

For resolve-issue, keep the body bounded to fields you actually intend to support, such as:

• status
• statusDetails

Safety note for issue resolution

resolve-issue stays on require_approval because Sentry status changes affect active alerting, issue visibility, and downstream response workflows. Harbor should treat that as an explicit, reviewable capability.

Suggested operator workflow

1. Import the Sentry Dock entry from Dock / Hub.
2. Configure the local Sentry bearer token in Harbor Node.
3. Use list-projects to discover available projects.
4. Use list-issues to inspect current issue state and confirm filters.
5. Keep resolve-issue on require_approval unless there is a very clear local policy reason not to.

Suggested agent workflow

1. Inspect the existing Sentry Harbor Port.
2. Inspect live actions and drafts.
3. Propose additional fixed Sentry routes 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 Sentry token
• widen Sentry into a generic observability or admin proxy
• add bulk mutation coverage without review
• hide organization targeting behind arbitrary route input

Current update strategy

For now, Sentry updates are manual:

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

• Sentry API overview: https://docs.sentry.io/api/
• List an organization's projects: https://docs.sentry.io/api/organizations/list-an-organizations-projects/
• List an organization's issues: https://docs.sentry.io/api/events/list-an-organizations-issues/
• Retrieve an issue: https://docs.sentry.io/api/events/retrieve-an-issue/
• Update an issue: https://docs.sentry.io/api/events/update-an-issue/