Publishd is the content backend behind every product WenHunt Group ships. One content model per product, one dashboard for every editor, and one fast API serving every app, site and surface in the group.
No boilerplate CMS to install, no database to run, no per-app rebuild. Define the shape, fill it in, fetch it anywhere.
Define the shape your product actually needs — events, venues, listings, articles, offers. Fields, relations, validation and localisation, versioned per project and changed without a migration.
Editors work in one place across every project they have access to. Draft, upload media, request review, schedule for 6am Saturday, hit publish. Nobody waits on a deploy.
Hit the REST or GraphQL API with a project key and get clean, typed JSON back — cached at the edge. Same content, same shape, whether it's a Next.js site, a SwiftUI app or a static build.
The parts you'd otherwise rebuild for every product — built once, shared across all of them.
Every project defines its own schema. A town app's "venue" and a marketplace's "listing" live side by side without leaking into each other — and evolve independently.
REST and GraphQL from the same content, with typed SDKs for JavaScript, Swift and Kotlin. Edge-cached responses, webhooks on publish, and previews for unreleased drafts.
Upload once, use everywhere. Automatic resizing, WebP and AVIF conversion, focal-point cropping and CDN delivery — with alt text and rights held against the asset, not the page.
Queue content for a date and time, embargo it until an announcement lands, or route it through review first. Full version history, side-by-side diffs and one-click rollback.
Scoped API keys per project and environment. Roles from read-only contributor to owner, granular down to a single content type, plus SSO and an audit log of who changed what.
Run every brand in the group from one workspace. Shared infrastructure, media and monitoring; isolated content, keys and editors. Add the next product in minutes, not sprints.
The dashboard is a client of the same public API you build against. Nothing is hidden behind it.
# Fetch the next two events for a town app
curl https://api.publishd.io/v1/entries \
-G -d type=event -d limit=2 -d sort=starts_at \
-H "x-publishd-project: localos" \
-H "authorization: Bearer pub_live_••••"
HTTP/2 200 · 41ms · x-publishd-cache: HIT
{
"data": [
{
"id": "evt_9wKq2n",
"type": "event",
"title": "Late Night At The Museum",
"starts_at": "2026-08-08T19:30:00+01:00",
"venue": { "name": "City Museum", "lat": 51.5072 },
"hero": "https://cdn.publishd.io/localos/museum.avif?w=1200",
"status": "live"
},
{ "id": "evt_4tBm7d", "title": "Riverside Market", … }
],
"meta": { "total": 37, "cursor": "eyJvIjoyfQ" }
}// npm i @publishd/client
import { createClient } from "@publishd/client";
const publishd = createClient({
project: "localos",
token: process.env.PUBLISHD_TOKEN,
});
const { data, meta } = await publishd.entries.list({
type: "event",
limit: 2,
sort: "starts_at",
expand: ["venue"],
});
data[0].title; // "Late Night At The Museum"
data[0].venue.name; // "City Museum"
meta.total; // 37
// Types are generated from your schema:
// npx publishd types --project localos// Swift Package: github.com/publishd/publishd-swift
import Publishd
let publishd = Publishd(
project: "localos",
token: Secrets.publishdToken
)
let events: [Event] = try await publishd.entries(
of: Event.self,
limit: 2,
sort: .ascending("starts_at"),
expand: ["venue"]
)
events.first?.title // "Late Night At The Museum"
events.first?.venue.name // "City Museum"
// Responses are cached on device and revalidated
// from the publish webhook, so the app opens instantly.Different content models, different audiences, different front-ends — one CMS, one set of infrastructure, one platform team.
LocalOS runs branded town apps and websites where every place gets its own identity, its own editors and its own local content. Each town is a separate Publishd project with its own model for venues, events and offers, and its own keys. They share one media library, one scheduling engine and one dashboard, so launching the next town is a configuration change rather than a codebase.
Turnstile models its content nothing like a town app does — and that's the point. It defines its own types, its own roles and its own publishing rules inside the same platform, pulling everything through the same API its team already knows. Adding a second product meant a new project and a new key, not a second CMS to run, patch and pay for.
Publishd isn't sold by the seat. It's the platform WenHunt Group runs its own products on — so every product inherits the same infrastructure, the same guarantees and the same security posture.
If you're building something new inside WenHunt Group, start here rather than standing up another CMS. Tell the platform team what you need to model and we'll have a project, API keys and a staging environment ready for you the same day.
Bringing a new product into the group? Get a project, keys and a staging environment the same day.