Skip to main content

Connectors

Bowrain governs content where it already lives. A connector links a workspace to a system that holds source content, brings that content into a project so the workspace's voice, terms, and content memory apply to it, and publishes approved results back to where they came from.

No single connector is the way in. A workspace can run several at once — a marketing site, a design file, and a product repository can all converge under one governed vocabulary.

The connector row

ConnectorWhat it holdsWhere it runsDirection
WordPressSite posts — title, body, excerptServer-sideIn and back out
HubSpotCMS page title and meta descriptionServer-sideIn and back out
FigmaDesign text layersServer-sideIn only
GitHub / GitLabRepository content filesServer-sideIn, back out as a pull/merge request
kapiA developer's working checkoutOn the developer's machine, or in CIIn and back out

Everything above the last row runs server-side: nobody installs anything, nothing is checked out, and the workspace reaches the source system directly over its API. The last row is the developer path — a person or a CI job working in a repository, driving content in and out from where they already are.

Content platformswordpress · hubspotfetch over the APIconverge in the workspacepublish backDesign toolsfigmafetch text layersconverge in the workspaceexport from the editorCode repositoriesgithub · gitlab · gitpush webhookconverge server-sidedeliver a pull requestA developer's checkoutkapikapi push / kapi upconverge on the serverresults land in the tree

Peer routes into the same workspace. The server-side routes need no checkout at all; the last is the developer and CI path.

What a connector does

  1. Fetch — the connector reads source content from the external system and delivers it into the project.
  2. Converge — the workspace catches the content up: reuse what memory already holds, draft the rest, check everything against the voice profile and the workspace's terms, and park what needs a person. See Keeping content caught up.
  3. Publish — approved results go back to the system they came from.
fetchpublishSource systemcontent platform · design · repository · checkoutBowrain workspacegoverned content storePeople & agentsweb · desktop · MCPSource systemcontent platform · design · repository · checkoutBowrain workspacegoverned content storePeople & agentsweb · desktop · MCPConnector

Every connector is the same round trip: source in, governed work in the middle, approved results back out.

Managing connectors

Server-side connectors are scoped to a workspace and managed from a project's Connectors view in the web app: add one there, browse the content it can see, fetch it into the project, and publish results back. Saved credentials are write-only — used for sync, never displayed again. The same operations are available through the workspace connectors API for scripting. Both surfaces require the manage connectors permission.

Sync is explicit: content moves when you select Fetch now or Publish, or call the corresponding endpoints. A fetch does not emit an event, so automation rules do not react to it — the convergence orchestrator subscribes to push completion. Catch fetched content up by starting a run or a flow, or let the project's server.converge policy produce and review targets.

The GitHub/GitLab connector is configured through the workspace connectors API, or from a project's Connectors page once the server has a GitHub App. The plain git and local file connectors are server-side building blocks with no web-app surface — they back the repository connector and server-hosted directories. The kapi connector needs no server-side configuration at all: it authenticates as the developer and connects a project from the command line.

Choosing a route for a repository

Source files in a repository can arrive either way, and the choice is about who drives:

  • GitHub / GitLab when nobody wants a pipeline. A push webhook triggers the server, and results arrive as one open pull/merge request that every delivery updates in place. There is no CI configuration in the repository and no CLI on anyone's machine.
  • kapi when a developer wants the work under their own hand — running it locally before a commit, watching progress stream into their terminal, or gating a release in CI with an explicit exit code.

They are not exclusive. A repository can deliver through GitHub while a developer also runs kapi locally against the same project.

Next steps