Publishing channels

Publishing channels push or expose document content to external systems when documents change — complementary to Webhooks (which notify about events) and Export (manual one-off downloads).

Prerequisites

• Capability Publishing (or team admin)
• Server env: PUBLISHING_ENCRYPTION_KEY (see Installation)
• For Git mirrors: optional GIT_MIRROR_ALLOWED_HOSTS for non-default hosts

Access

Settings → Publishing — list of channels, delivery log, create/edit wizard.

Transport types

Transport	How it works	Best for
Pull	Consumer fetches content itself via the token-secured Pull API (Bearer token)	Static sites, SSR apps, simple integrations
Webhook	Orimora POSTs document payload to your URL on change	CMS updates, custom pipelines
Git mirror	Orimora commits/pushes Markdown to a Git repository	Docs sites (GitHub Pages, GitLab CI)

Scope

Each channel targets content by:

• Collection — one folder and its documents
• Tag — all documents with a specific tag

You must explicitly choose a collection or tag (no “entire workspace” wildcard).

Format

Format	Description
markdown	Markdown files (default for Git mirror)
json	TipTap JSON
html	Rendered HTML (where supported)

Pull channel setup

1. Create channel → transport Pull, format Markdown. Optionally add a deploy hook URL (see below).
2. Publish documents to the channel with “Send to channel…” — the Pull-API serves exactly that curated set (never an unpublished document)
3. Create a token on the channel — treat it like a password
4. Your consumer fetches on a schedule or at build time. The ready-made Pull API URL is shown on the channel card with a copy button.

Note

What is the token for — and what not? Only the consumer (the system calling the Pull API) needs the token. Publishing itself — “Send to channel…” — runs on your login session and needs no token. A channel without a token is still a dead end: nobody can fetch. The UI warns you on publish when that is the case.

Deploy hook: rebuild static sites automatically

Static generators (Starlight, Hugo, Astro …) only pick up new content on their next build. Add your host’s build hook URL to the pull channel and Orimora POSTs to it after every publish, triggering the rebuild automatically:

• Netlify: Site configuration → Build & deploy → Build hooks
• Vercel: Project → Settings → Git → Deploy Hooks
• Cloudflare Pages: Settings → Builds & deployments → Deploy hooks
• Coolify: POST /api/v1/deploy?uuid=<app-uuid> — additionally requires an Authorization header (Bearer <api-token>); use the optional header field below the hook URL on the channel

Server-rendered consumers (SSR/ISR) don’t need a hook — they fetch at request time. The hook is best-effort: if it fails, the publish still succeeds; the error shows on the channel.

How do I know it worked?

A pull channel deliberately creates no delivery on publish — content only becomes visible once a consumer fetches it. Three signals confirm success:

1. Right after publishing: the dialog confirms “Content is ready on the Pull API” (and whether the deploy hook fired).

2. “Last pulled” on the channel card: stamped on every authenticated Pull-API request — the honest end-to-end confirmation.

3. Manually via curl (values from the channel card):

   curl -H "Authorization: Bearer <token>" \
     "https://your-instance.example/api/v1/published/<channel-id>/documents"

   You must see your published documents as JSON.

Webhook transport setup

Similar to Webhooks but sends document payloads for publishing, not generic event envelopes. Configure URL and optional signing secret. Failed deliveries may auto-pause the channel (PUBLISHING_CHANNEL_* env vars).

Git mirror setup

1. Transport Git mirror
2. Repository URL (GitHub, GitLab, Bitbucket, Gitea, Codeberg supported by default)
3. Branch and optional path prefix
4. Provide credentials (PAT or deploy key) — stored encrypted

Orimora pushes Markdown on document changes. Ensure the token has push access to the target branch.

Caution

Git mirror failures (auth, branch protection) pause the channel faster than generic webhooks — check delivery logs in Settings.

Delivery log

Webhook and Git-mirror channels show recent deliveries: status, HTTP code, duration, error message. Use this to debug failed pushes or webhook responses. Pull channels have no deliveries by design — use “Last pulled” on the channel card instead (see above).

Comparison: webhooks vs publishing

Feature	Developers → Webhooks	Settings → Publishing
Purpose	Event notifications	Content sync
Payload	Event envelope + model snapshot	Document content in chosen format
Transports	HTTP POST only	Pull, webhook, Git mirror
Scope	Per event subscription	Per collection or tag

See also

• Webhooks — event-driven automation
• Export — manual download
• Configuration — PUBLISHING_* and GIT_MIRROR_ALLOWED_HOSTS
• Permissions & groups — Publishing capability