Documentation

Integrating Content

Integrating Content

Once your content is modeled and created in SleekCMS, the next step is getting it into your website, app, or frontend. SleekCMS provides three mechanisms for this: a content API for reading your data, publish triggers for automating external workflows, and environments for managing content versions.

Together, these give you a complete integration layer. The API delivers your content. Triggers notify your build and deployment systems when content changes. Environments let you control which version of content is live, staged, or in progress.

This page introduces all three and explains how they work together. Implementation details, configuration, and client library usage are covered in the linked sub-pages.

Content API

The content API is the primary way to consume SleekCMS content in your own frontend. It delivers your entire site's content — pages, entries, images, options, and configuration — as structured JSON, accessible via a single authenticated endpoint.

How It Works

You authenticate with a site token and request content from a specific environment. The API returns a JSON payload containing all of your site's published content in one response:

GET https://pub.sleekcms.com/{site-id}/{environment}
Authorization: {site-token}

The response is a single payload with this top-level structure:

{
  "pages": [ ... ],
  "entries": { ... },
  "images": { ... },
  "options": { ... },
  "config": { ... },
  "_tag": "..."
}

pages — An array of all page records across all page models. Each page object contains its field data, a _path property for routing, and a _slug for collection pages.

entries — An object keyed by entry handle. Single entries resolve to an object, entry collections resolve to an array of objects. Referenced entries are also resolved inline within page data.

images — Named images registered at the site level, accessible by key.

options — Option sets accessible by handle, each containing an array of label-value pairs.

config — Site-level configuration including the site title, origin URL, and subdirectory setting.

_tag — A version identifier for the content snapshot. This changes whenever content is published to the requested environment.

Client Libraries

While you can call the API directly with any HTTP client, SleekCMS provides official client libraries that handle authentication, caching, environment resolution, and typed access to your content.

@sleekcms/client — The core JavaScript/TypeScript client. Available via npm or CDN. Offers two client modes: a sync client that prefetches all content (ideal for static site generation) and an async client that fetches on demand (ideal for server-side rendering).

import { createSyncClient } from '@sleekcms/client';

const client = await createSyncClient({
  siteToken: 'your-site-token',
  env: 'latest'
});

const page = client.getPage('/about');
const posts = client.getPages('/blog');
const footer = client.getEntry('footer');
const slugs = client.getSlugs('/blog');

@sleekcms/react — React hooks for client-side content fetching. Wraps the async client with loading states, error handling, and automatic refetching — designed for React SPAs and client components.

import { SleekCMSProvider, usePage } from '@sleekcms/react';

function App() {
  return (
    <SleekCMSProvider siteToken="your-site-token">
      <AboutPage />
    </SleekCMSProvider>
  );
}

function AboutPage() {
  const { data, loading } = usePage('/about');
  if (loading) return <p>Loading...</p>;
  return <h1>{data?.title}</h1>;
}

Both libraries support environment selection, language targeting for internationalized content, and custom cache adapters for controlling how content is stored between requests.

→ Content API → @sleekcms/client → @sleekcms/react

Publish Triggers

Publish triggers are automated actions that fire when you publish content. They let you connect SleekCMS to your external build and deployment pipelines — so that when content changes, your website rebuilds, your CDN cache invalidates, or any downstream system gets notified.

What Triggers Do

A trigger sends an HTTP request to a URL you configure. This can be a webhook endpoint, a build hook, or any URL that accepts an HTTP call. When triggered, it tells the receiving system that content has changed and action is needed.

Common Use Cases

GitHub Actions — Trigger a GitHub Actions workflow to rebuild your static site when content is published. Your workflow pulls fresh content from the API, runs your build process, and deploys the result.

Netlify deploys — Call a Netlify build hook to trigger a site rebuild. Netlify pulls your repository, builds the site with the latest content, and deploys it to their CDN — all initiated by the publish trigger.

Custom webhooks — Call any HTTP endpoint. This could be a Slack notification, a cache purge on your CDN, an indexing request for your search service, or any system that needs to know when content changes.

How Triggers Fit the Workflow

Triggers bridge the gap between content management and content delivery. The typical flow is:

Editor publishes content
        │
        ▼
SleekCMS fires publish trigger(s)
        │
        ▼
External system receives webhook
        │
        ▼
Site rebuilds / cache purges / action executes

You can configure multiple triggers on a single site. Each trigger fires independently, so a single publish action can simultaneously kick off a Netlify deploy, notify a Slack channel, and purge a CDN cache.

Trigger access can be restricted per editor using fine-grained access controls. This means you can allow senior editors to fire production build triggers while preventing other editors from triggering deploys.

→ Automating using Triggers → Customizable Access

Environments

Environments are how you manage content versions in SleekCMS. An environment is a named alias that points to a specific snapshot of your content. When you access content through the API, you request it from an environment — and the environment determines which version of the content you receive.

The latest Environment

Every site has a built-in latest environment that always points to the current state of your content. When you create or edit content and publish, latest reflects those changes immediately. Most integrations start with latest and it's the default when no environment is specified.

// These are equivalent — both fetch the current content
const client = await createSyncClient({
  siteToken: 'your-site-token',
  env: 'latest'
});

const client = await createSyncClient({
  siteToken: 'your-site-token'
});

Named Environments

Beyond latest, you can create named environments that point to specific content snapshots. A named environment captures the state of your content at a point in time and holds it there until you explicitly update it.

This is how you decouple content editing from content delivery. Editors work on content freely — adding pages, editing entries, reordering blocks — and latest reflects every change in real time. But your production site can point to a named environment like production that only updates when an admin explicitly promotes content to it.

Staging and Production Workflows

Named environments enable multi-stage publishing workflows. A common setup:

latest — The working state. Every edit is reflected here immediately. Use this for internal previews and content review.

staging — A promotion target. When content is ready for QA or stakeholder review, promote latest to staging. Your staging site pulls from this environment, showing exactly what will go live.

production — The live content. When staging is approved, promote it to production. Your production site pulls from this environment, and nothing changes on the live site until this promotion happens.

Each environment is an independent snapshot. Editing content after promoting to staging changes latest but does not affect staging until the next promotion. This gives content teams a safe space to work without risking the live site.

Environments in the API and Client

The environment is specified when creating a client or making an API request. The API URL includes the environment name, and the client libraries accept it as a configuration option:

// Fetch content from the production environment
const client = await createSyncClient({
  siteToken: 'your-site-token',
  env: 'production'
});

GET https://pub.sleekcms.com/{site-id}/production
Authorization: {site-token}

The resolveEnv option on the client resolves an environment alias to its underlying version tag. This is useful for CDN cache invalidation — when the environment points to a new snapshot, the resolved tag changes, producing a different cache key and ensuring fresh content is served.

const client = createAsyncClient({
  siteToken: 'your-site-token',
  env: 'production',
  resolveEnv: true  // Resolves to version tag for cache busting
});

→ Environments & Content Versions

How the Three Work Together

The API, triggers, and environments form a complete content delivery pipeline. Here's how they connect in a typical production setup:

Content is created and edited in SleekCMS. Every change is immediately available through the latest environment for preview and internal review.

When content is ready, an admin promotes it to a named environment like production. The content snapshot at that moment becomes the production content.

The promotion fires publish triggers — a Netlify build hook, a GitHub Actions workflow, or any configured webhook. The external system receives the notification and initiates a rebuild.

The build system fetches content from the production environment using the content API (via @sleekcms/client or a direct HTTP call). It generates the site with the promoted content and deploys the result.

The end-to-end flow:

Edit content → Promote to environment → Trigger fires → Build fetches from API → Site deploys

This pipeline works with any frontend framework, any hosting provider, and any build system. SleekCMS handles the content management and notification layer. Your existing tools handle the build and deployment.

What's Next