Documentation

Automating using Triggers

Publish triggers connect SleekCMS to your external build and deployment systems. When you publish content, triggers fire automatically — calling the APIs of services like GitHub, Netlify, or any custom webhook endpoint. This is how content changes flow from SleekCMS into your live website without manual intervention.

A trigger has two parts: a target that defines where the call goes and how to authenticate, and the trigger action that fires when content is published. You configure targets once, and SleekCMS calls them each time you publish.

This page covers how triggers work, the three supported target types, authentication and security, and how triggers fit into your publishing workflow.

How Triggers Work

The mechanism is straightforward. You configure one or more targets on your site — each pointing to an external service. When you publish content, you choose which environment to publish to and which target to trigger. SleekCMS calls the selected target's API, and the external service performs its action: a GitHub Actions workflow runs, a Netlify build starts, or a webhook endpoint processes the notification.

Publishing is a deliberate, selective action. You pick the environment, you pick the target. SleekCMS does not fire all targets automatically — you control exactly which external system gets notified on each publish. This means you can publish to staging and trigger only a staging webhook, then later publish to production and trigger a different target.

Triggers fire on publish actions only. Saving a draft or editing content does not fire triggers. Your external systems only rebuild when you intentionally publish and select a target.

Target Types

SleekCMS supports three target types. Each integrates with a different service and uses that service's native API for triggering actions.

GitHub Actions

A GitHub Actions target triggers a workflow in a GitHub repository. When fired, SleekCMS calls the GitHub API to dispatch a workflow event, which starts the specified workflow run.

This is the most common setup for static site generation. Your GitHub repository contains your frontend code (Next.js, Astro, 11ty, or similar), and the workflow pulls fresh content from the SleekCMS content API, builds the site, and deploys the result.

Configuration requires:

  • Repository — The GitHub repository that contains the workflow (e.g., your-org/your-site).
  • Workflow — The workflow file to trigger (e.g., build.yml).
  • Personal access token — A GitHub personal access token with permission to trigger workflow dispatches on the repository.

When triggered, SleekCMS sends a workflow_dispatch event to the GitHub API. Your workflow file must be configured to listen for this event:

# .github/workflows/build.yml
name: Build and Deploy

on:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build
        env:
          SLEEKCMS_SITE_TOKEN: ${{ secrets.SLEEKCMS_SITE_TOKEN }}
      - name: Deploy
        # Your deployment step

The workflow has full access to your repository and secrets, so your build script can fetch content from the SleekCMS API using your site token stored as a GitHub secret.

Netlify

A Netlify target triggers a site build on Netlify. When fired, SleekCMS calls a Netlify build hook URL, which starts a fresh build and deployment of your Netlify site.

This is the simplest setup if your site is already hosted on Netlify. Netlify build hooks are URLs that trigger a build when called — no authentication token management required beyond the hook URL itself.

Configuration requires:

  • Build hook URL — The Netlify build hook URL for your site. You generate this in your Netlify site settings under Build & deploy → Build hooks.

The build hook URL acts as both the endpoint and the credential — anyone with the URL can trigger a build. SleekCMS stores it encrypted.

When triggered, Netlify pulls your repository, runs your build command with the latest content, and deploys the result to its CDN. If your build script fetches from the SleekCMS content API, the rebuild automatically picks up the newly published content.

Custom Webhook

A custom webhook target calls any HTTP endpoint you specify. This is the flexible option — it works with any service that accepts incoming HTTP requests, from Slack and Discord to custom serverless functions and third-party automation platforms.

Configuration requires:

  • URL — The endpoint to call when the trigger fires.
  • Secret (optional) — An arbitrary secret string that SleekCMS sends with the request as the Authorization header. The receiving endpoint can verify this value to authenticate that the request came from SleekCMS.

When triggered, SleekCMS sends an HTTP request to the configured URL. If a secret is configured, it is included as the Authorization header value, allowing the receiving service to verify the request origin.

Common webhook uses:

  • CDN cache purge — Call your CDN's purge API to invalidate cached pages after content changes.
  • Search re-indexing — Notify your search service (Algolia, Meilisearch, Elasticsearch) to re-crawl and index updated content.
  • Team notifications — Post to a Slack or Discord channel when content is published, keeping the team informed of changes.
  • Custom automation — Call a serverless function that performs any post-publish logic specific to your workflow.

Security

Trigger targets store sensitive credentials — GitHub personal access tokens, Netlify build hook URLs, and webhook secrets. SleekCMS encrypts all target credentials at rest using a site-specific salt. The credentials are decrypted only at the moment a trigger fires and are never exposed in the admin interface after initial configuration.

GitHub Tokens

GitHub personal access tokens are encrypted at rest. The token is used to authenticate the workflow dispatch API call and is never visible after you save the target configuration. If you need to rotate the token, update the target with a new one.

Netlify Build Hooks

Netlify build hook URLs contain an embedded secret and are treated as credentials. They are encrypted at rest alongside other target secrets.

Webhook Secrets

For custom webhooks, you can specify an arbitrary secret string. SleekCMS sends this value as the Authorization header with every request to the webhook endpoint. Your endpoint should validate this header to ensure the request originated from SleekCMS and reject requests with missing or incorrect values.

# What the receiving endpoint sees
Authorization: your-configured-secret

The webhook secret is encrypted at rest using the same site-specific salt as other credentials. Choose a strong, unique secret for each webhook target.

Multiple Targets

A site can have multiple targets configured simultaneously. When publishing, you select which target to trigger for that specific publish action. You are not required to trigger all targets every time — you choose the one appropriate for the situation.

A typical multi-target setup might include:

  • A GitHub Actions target for rebuilding and deploying the production site.
  • A Netlify target for deploying a staging preview.
  • A custom webhook that posts a notification to a Slack channel.

Different team members might use different targets depending on the context. A content editor might trigger the staging Netlify target for review, while an admin triggers the GitHub Actions target for production deployment. Access controls determine which members can fire which targets.

Access Control

Trigger access can be restricted per editor using fine-grained access controls. By default, only admins can trigger targets. When fine-grained access is enabled for an editor, you can grant them permission to trigger specific targets — allowing a senior editor to trigger staging deploys while restricting other editors from initiating production builds.

This is configured in the site members settings, not in the target configuration itself. The targets are shared across the site; the access controls determine which members can select which targets when publishing.

→ Site Members → Customizable Access

Triggers and Environments

When publishing, you select both an environment and a target. The environment determines which content snapshot gets updated. The target determines which external system gets notified. These are independent choices made at publish time.

A typical workflow:

  1. Content editors create and edit content. The latest environment reflects all changes in real time.
  2. When content is ready, a user publishes to a named environment (e.g., production) and selects a target to trigger (e.g., the GitHub Actions target).
  3. The selected target fires — calling the GitHub API, Netlify build hook, or webhook endpoint.
  4. The external system receives the call and performs its action.

It's important to understand that the environment you publish to and the environment your scripts fetch from are independent. Publishing to production and triggering a GitHub Actions workflow doesn't force the workflow to fetch from production — your build script decides which environment to request from the content API. This gives you flexibility: a staging build triggered after a production publish could still fetch from staging for comparison, or a single workflow could fetch from multiple environments.

The environment published to is the content gate. The target triggered is the automation gate. Your build scripts control the rest.

→ Environments & Content Versions

What's Next