Skip to main content

Integrations

Documentation Map​

Integrations

Contract Format​

Every integration entry in this document uses the same required fields:

  • Direction
  • Type
  • Surface
  • Auth
  • Stability
  • Versioning
  • Owner

Optional supporting fields may be added after the required set when they improve clarity.

Field meaning:

  • Direction
    • inbound
    • outbound
    • bidirectional
  • Type
    • REST API
    • webhook
    • callback
    • MCP
    • database contract
    • file contract
    • other
  • Surface
    • concrete endpoint, file, script, contract root, or route family
  • Auth
    • actual auth requirement today
  • Stability
    • stable
    • internal
    • experimental
    • planned
  • Versioning
    • how the surface is versioned today
  • Owner
    • system that owns the contract surface

Implemented Internal Integrations​

Frontend To Backend​

  • Direction:
    • inbound
  • Type:
    • REST API
  • Surface:
    • /api/v1/*
  • Auth:
    • operator session cookie
  • Stability:
    • internal
  • Versioning:
    • route prefix v1; no separate public compatibility promise
  • Owner:
    • Mission Control v2 backend
  • Mode:
    • read-write
  • Trigger:
    • operator UI actions

MCP To Backend​

  • Direction:
    • inbound
  • Type:
    • MCP
  • Surface:
    • mission-control-mcp -> backend.app.mcp.mission_control_server:main
  • Auth:
    • configured operator context over the same product API contract
  • Stability:
    • internal
  • Versioning:
    • tied to the Mission Control product contract and package version
  • Owner:
    • Mission Control v2 backend
  • Mode:
    • read-write
  • Trigger:
    • MCP tool calls
  • Tool families:
    • project and task board reads/writes
    • planning cycle/module/page sync calls
    • delivery review queue, release readiness, and health summary reads
    • delivery review follow-up task creation and provider gate actions
  • Verify path:
    • backend/tests/test_planning_delivery.py::test_mcp_server_exposes_first_wave_tools

Backend To PostgreSQL​

  • Direction:
    • outbound
  • Type:
    • database contract
  • Surface:
    • DATABASE_URL
  • Auth:
    • database credentials via DATABASE_URL
  • Stability:
    • internal
  • Versioning:
    • schema/versioning follows backend models and migrations
  • Owner:
    • Mission Control v2 backend
  • Mode:
    • read-write
  • Trigger:
    • every persisted read or mutation

Implemented External Integrations​

Repo Providers: Gitea, GitHub, GitLab​

  • Direction:
    • bidirectional
  • Type:
    • REST API
  • Surface:
    • provider API clients plus /api/v1/projects/{project_id}/integrations/{provider}/*
  • Auth:
    • provider OAuth configuration or stored access tokens
  • Stability:
    • stable
  • Versioning:
    • provider-specific external API versions; Mission Control side stays under /api/v1
  • Owner:
    • external provider APIs for remote state, Mission Control v2 for local operator contract
  • Mode:
    • read-write
  • Trigger:
    • operator actions, sync runs, OAuth flows, repo-page sync

Plane API​

  • Direction:
    • bidirectional
  • Type:
    • REST API
  • Surface:
    • /api/v1/projects/{project_id}/integrations/plane/*
  • Auth:
    • PLANE_API_TOKEN
  • Stability:
    • internal
  • Versioning:
    • Mission Control side under /api/v1; remote Plane capability surface depends on the target instance API
  • Owner:
    • Plane for remote planning/task state, Mission Control v2 for local sync contract
  • Mode:
    • read-write
  • Trigger:
    • sync runs, operator actions, planning reconciliation

Plane Webhook​

  • Direction:
    • inbound
  • Type:
    • webhook
  • Surface:
    • /api/v1/projects/{project_id}/integrations/plane/webhook
  • Auth:
    • PLANE_WEBHOOK_SECRET
  • Stability:
    • internal
  • Versioning:
    • Mission Control side under /api/v1; payload shape depends on the sending Plane instance
  • Owner:
    • Plane emits, Mission Control v2 validates and consumes
  • Mode:
    • callback
  • Trigger:
    • Plane issue/task events
  • Secret transport:
    • preferred header X-Plane-Webhook-Secret
    • compatibility fallback X-Webhook-Secret
    • legacy query fallback ?secret=
  • Verify path:
    • backend/tests/test_api.py::test_plane_webhook_rejects_wrong_secret
    • backend/tests/test_api.py::test_plane_webhook_accepts_legacy_secret_transports

Warp Setup Import​

  • Direction:
    • inbound
  • Type:
    • REST API
  • Surface:
    • /api/setup-import
  • Auth:
    • Bearer token matching PLANE_API_TOKEN
  • Stability:
    • internal
  • Versioning:
    • Warp posts Mission Control setup payloads using the current v1 contract shape
  • Owner:
    • jhf-warp emits the setup payload, jhf-pattern validates and materializes the bounded work item
  • Mode:
    • callback
  • Trigger:
    • Warp mission-control setup delivery
  • Runtime readback:
    • authenticated setup-import now has to materialize both the Mission Control work item and the OpenClaw PM skill projection under ~/.openclaw/workspace/jhf-pattern/projects/openclaw-runtime-live
    • the bounded lead task and workspace NEXT_AUTONOMOUS_ACTION.md files are refreshed through the PM skill sync path instead of leaving runtime-managed agents on stale LIVE-* board state
  • Verify path:
    • python -m pytest -q backend/tests/test_setup_import_api.py

n8n API And Operator Webhook​

  • Direction:
    • bidirectional
  • Type:
    • REST API
  • Surface:
    • /api/v1/projects/{project_id}/integrations/n8n-expert*
    • /api/v1/projects/{project_id}/integrations/n8n-operator*
  • Auth:
    • N8N_API_KEY and deployment-specific webhook configuration
  • Stability:
    • experimental
  • Versioning:
    • Mission Control side under /api/v1; remote n8n contract depends on the target API and configured webhook payloads
  • Owner:
    • n8n for remote automation state, Mission Control v2 for local orchestration contract
  • Mode:
    • read-write
  • Trigger:
    • operator workflow actions, workflow build/publish, webhook dispatch

OpenClaw Runtime Dispatch​

  • Direction:
    • outbound
  • Type:
    • webhook
  • Surface:
    • OPENCLAW_RUNTIME_DISPATCH_WEBHOOK_URL
  • Auth:
    • deployment-specific secret or proxy rules outside this repo
  • Stability:
    • internal
  • Versioning:
    • no explicit standalone version contract in this repo
  • Owner:
    • runtime endpoint outside this repo; Mission Control v2 owns the dispatch call site
  • Mode:
    • control
  • Trigger:
    • task, handoff, and operator flows

Release Packaging Contracts​

Release Bundle Build​

  • Direction:
    • outbound
  • Type:
    • file contract
  • Surface:
    • scripts/build-release-bundle.sh
  • Auth:
    • none
  • Stability:
    • internal
  • Versioning:
    • artifact version derives from pyproject.toml
  • Owner:
    • Mission Control v2 repository
  • Mode:
    • build
  • Trigger:
    • release verification or manual packaging

Release Compatibility Matrix​

  • Direction:
    • inbound
  • Type:
    • file contract
  • Surface:
    • COMPATIBILITY_MATRIX.md
  • Auth:
    • none
  • Stability:
    • internal
  • Versioning:
    • updated with the product version and release-policy changes
  • Owner:
    • Mission Control v2 repository
  • Mode:
    • read-only
  • Trigger:
    • operator review, release verification, downstream compatibility planning

ClawLedger Approval Callback​

  • Direction:
    • inbound
  • Type:
    • callback
  • Surface:
    • canonical spindle pending read:
      • GET /api/approvals/jhf-spindle/pending
    • clawledger callback and decision writes:
      • /api/approvals/clawledger
  • Auth:
    • shared secret
  • Stability:
    • internal
  • Versioning:
    • no standalone public version contract; tied to current callback payload expectations
  • Owner:
    • ClawLedger emits, Mission Control v2 consumes
  • Mode:
    • callback
  • Trigger:
    • approval events
  • Secret transport:
    • header X-ClawLedger-Token
  • Protected routes:
    • canonical:
      • /api/approvals/jhf-spindle/pending
    • primary clawledger routes:
      • /api/approvals/clawledger
      • /api/approvals/clawledger/pending
      • /api/approvals/clawledger/sync
      • /api/approvals/clawledger/{project_id}/{task_key}/decision
      • /api/approvals/clawledger/decision
    • deprecated compatibility aliases:
      • /api/v1/approvals/jhf-spindle/pending
      • /api/v1/approvals/clawledger/pending
  • Verify path:
    • backend/tests/test_api.py::test_clawledger_routes_reject_wrong_shared_secret
    • backend/tests/test_api.py::test_list_pending_spindle_approvals_uses_canonical_alias

OIDC Login​

  • Direction:
    • bidirectional
  • Type:
    • callback
  • Surface:
    • /api/v1/auth/oidc/*
  • Auth:
    • OIDC client configuration
  • Stability:
    • internal
  • Versioning:
    • tied to the configured OIDC provider and current /api/v1 auth routes
  • Owner:
    • OIDC provider for identity assertions, Mission Control v2 for session handling
  • Mode:
    • auth
  • Trigger:
    • operator login flow

Implemented File And Discovery Contracts​

Repo Markdown Page Contract​

  • Direction:
    • bidirectional
  • Type:
    • file contract
  • Surface:
    • README.md
    • docs/*.md
    • /api/v1/projects/{project_id}/planning/pages/*
  • Auth:
    • repo-provider credentials and operator session for local triggers
  • Stability:
    • experimental
  • Versioning:
    • tied to current repo file layout and /api/v1 planning page routes
  • Owner:
    • source repository for files, Mission Control v2 for local page projection
  • Mode:
    • read-write
  • Trigger:
    • planning page sync actions

Runtime And Integration Environment Contract​

  • Direction:
    • inbound
  • Type:
    • file contract
  • Surface:
    • .env.example
    • docker-compose.v2.yml
    • docs/ENVIRONMENT_AND_RUNTIME_CONTRACT.md
  • Auth:
    • none
  • Stability:
    • internal
  • Versioning:
    • tied to the repository version and current deployment contract
  • Owner:
    • Mission Control v2 repository
  • Mode:
    • read-only
  • Trigger:
    • setup, deploy, and recovery work

Runtime Discovery Surfaces​

  • Direction:
    • inbound
  • Type:
    • REST API
  • Surface:
    • /healthz
    • /readyz
    • /versionz
    • /contractz
    • /fabric-presencez
    • /fabric-compatibilityz
    • /fabric-manifest.json
  • Auth:
    • none
  • Stability:
    • stable
  • Versioning:
    • tied to the deployed Mission Control version; endpoints themselves are intentionally simple and read-only
  • Owner:
    • Mission Control v2 backend
  • Mode:
    • read-only
  • Trigger:
    • polling by operators, CI, or future discovery tooling

Runtime Metrics Export​

  • Direction:
    • inbound
  • Type:
    • REST API
  • Surface:
    • /metrics
  • Auth:
    • none
  • Stability:
    • stable
  • Versioning:
    • Prometheus text exposition format plus stable metric names documented in operations docs
  • Owner:
    • Mission Control v2 backend
  • Mode:
    • read-only
  • Trigger:
    • metrics scraping, operator checks, or dashboard polling

OpenAPI Description​

  • Direction:
    • inbound
  • Type:
    • other
  • Surface:
    • /openapi.json
    • /docs
    • /redoc
  • Auth:
    • deployment-dependent, usually none
  • Stability:
    • internal
  • Versioning:
    • derived from the current FastAPI app and /api/v1 route set
  • Owner:
    • Mission Control v2 backend
  • Mode:
    • read-only
  • Trigger:
    • schema exploration

Fabric-Relevant Positioning​

Mission Control v2 is not a Fabric control plane.

Today this repository provides:

  • an operator-ui
  • a supporting service
  • read-only discovery surfaces that Fabric can poll later
  • a read-only shared-service attachment view via manifest, presence, compatibility, and contract surfaces

Today this repository does not provide:

  • Fabric registration
  • Fabric event emission
  • Fabric policy execution
  • Fabric-owned write paths into Mission Control

Fabric Shared-Service Attachment View​

  • Direction:
    • inbound
  • Type:
    • other
  • Surface:
    • /fabric-manifest.json
    • /contractz
    • /fabric-presencez
    • /fabric-compatibilityz
  • Auth:
    • none
  • Stability:
    • internal
  • Versioning:
    • manifest schema 1
    • presence / compatibility contract schema 1
  • Owner:
    • Mission Control v2 repository
  • Mode:
    • read-only
  • Trigger:
    • Fabric or comparable shared-service discovery polls

Planned But Not Implemented​

Fabric Registration​

  • Direction:
    • outbound
  • Type:
    • other
  • Surface:
    • not implemented
  • Auth:
    • not defined yet
  • Stability:
    • planned
  • Versioning:
    • not defined yet
  • Owner:
    • future Fabric integration layer, not current Mission Control runtime
  • Mode:
    • control
  • Trigger:
    • future explicit registration flow

Fabric Event Emission​

  • Direction:
    • outbound
  • Type:
    • webhook
  • Surface:
    • not implemented
  • Auth:
    • not defined yet
  • Stability:
    • planned
  • Versioning:
    • not defined yet
  • Owner:
    • future Fabric integration layer, not current Mission Control runtime
  • Mode:
    • control
  • Trigger:
    • future normalized event publication

Verify Paths​

Existing integration and discovery documentation can be verified today through:

  • /healthz
  • /readyz
  • /versionz
  • /contractz
  • /fabric-presencez
  • /fabric-compatibilityz
  • /fabric-manifest.json
  • /metrics
  • backend/tests/test_settings_regression.py
  • scripts/fabric-selfcheck.sh

These are verify paths only. They are not an active Fabric control contract.

License: AGPLv3

Helpifyr: https://helpifyr.com