Integrations

Auto-rebuild on publish

A static build only reflects content as of the last time it ran. This is the recipe for closing that gap: publish an entry, and a GitHub Actions workflow rebuilds and redeploys automatically, with no polling and no cron.

The shape of it

Three pieces, in order: a Sedgemark webhook fires on publish, GitHub’s repository_dispatch API turns that into a workflow run, and the workflow rebuilds your site and runs sedgemark deploy at the end. Each piece is independent and documented on its own page: this page is the wiring between them.

1. The webhook

Create a webhook (from the dashboard, or the equivalent POST /api/dashboard/webhooks call shown here), subscribed to content.published and content.unpublished, targeting GitHub’s dispatch endpoint for your repository:

http

POST /api/dashboard/webhooks
Content-Type: application/json

{
  "url": "https://api.github.com/repos/acme/site/dispatches",
  "events": ["content.published", "content.unpublished"],
  "format": "github_repository_dispatch",
  "debounce_ms": 3000,
  "debounce_scope": "webhook",
  "headers": {
    "Authorization": "Bearer ghp_your_fine_grained_pat",
    "Accept": "application/vnd.github+json"
  }
}

Setting	Why
format: github_repository_dispatch	Reshapes the delivered body to what GitHub's API requires. See below. Full format reference: Webhooks → Payload format.
headers.Authorization	A GitHub personal access token. Needs Contents: read and write on the target repository; that's the permission the dispatches endpoint checks. A fine-grained PAT scoped to just this repo is the least you can hand out.
headers.Accept	application/vnd.github+json: GitHub’s documented Accept header for this API version.
debounce_ms: 3000, debounce_scope: "webhook"	Publishing several entries in a burst (a bulk edit, a migration) should trigger one rebuild, not one per entry. Sedgemark waits 3 seconds after the last matching event in the whole webhook before delivering, collapsing the whole burst into a single dispatch.

Full header rules (the 10-header cap, why values are never readable back, the denylist) are on Webhooks → Custom headers.

2. What GitHub receives

github_repository_dispatch sends this shape rather than the full entry: GitHub’s API rejects a body missing event_type and caps client_payload at 10 top-level properties, so the full entry would not fit and is not what triggers a rebuild anyway:

json

{
  "event_type": "sedgemark.content.published",
  "client_payload": {
    "event": "content.published",
    "collection": "blog_post",
    "entryId": "9f8c1a2b-4d5e-4f60-8a71-2c3d4e5f6071",
    "timestamp": "2026-08-04T15:04:05.000Z"
  }
}

event_type is always sedgemark.{event}; that is what a workflow’s types: list matches against below.

3. The Actions workflow

yaml

# .github/workflows/rebuild.yml
name: Rebuild on publish

on:
  repository_dispatch:
    types: [sedgemark.content.published, sedgemark.content.unpublished]

# A second dispatch while one run is still building supersedes it rather
# than queuing behind it: you want the SITE that reflects the latest
# content, not every intermediate state built and deployed in order.
concurrency:
  group: rebuild
  cancel-in-progress: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx sedgemark deploy
        env:
          SEDGEMARK_API_KEY: ${{ secrets.SEDGEMARK_API_KEY }}

repository_dispatch always runs against your default branch: the payload carries no ref, so the workflow builds and ships whatever is on main at the moment it runs, not necessarily the commit that existed when the entry was published.
concurrency with cancel-in-progress means a second publish while a build is still running cancels the stale one rather than queuing behind it: you want the site to reflect the latest content, not every intermediate state deployed in order.
SEDGEMARK_API_KEY here needs sites:write, the same key sedgemark deploy always needs, stored as an Actions secret, never committed.

Not on GitHub Actions? The default format already works elsewhere

If your build lives on a platform that triggers off a bare authenticated POST to a fixed URL (a Netlify or Vercel build hook, a GitLab pipeline trigger token), the reshaping above is unnecessary. Point the webhook at that URL with the default sedgemark format; those receivers ignore the request body entirely and trigger off the URL alone, so there is nothing to satisfy about its shape.

What you will and will not see

A failed build surfaces only in the CI provider. Sedgemark only knows whether GitHub accepted the dispatch call: a 2xx from the dispatches endpoint. Whether the workflow itself then succeeds, fails, or never runs a deploy step at all is invisible to Sedgemark; check your Actions run log.
A successful deploy appears in Settings → Sites: the dashboard’s own deployment history, same as a deploy run by hand.
Allow a short propagation window. Cloudflare’s edge picks up a new deployment quickly but not instantly; if you check the live URL in the same second a workflow finishes, give it a few moments before assuming the rebuild did not go out.