Introduction
Sedgemark documentation
Sedgemark is a headless CMS. You model your content in a workspace, write in a dashboard, and read it back over an HTTP API from whatever you are building: a static site, an app, or an AI agent.
What Sedgemark is
“Headless” means Sedgemark stores and serves your content but does not render your website. There are no themes and no templates. You decide what your content looks like; Sedgemark decides how it is structured, stored, versioned between draft and published, and delivered.
That split is the whole point. Your site can be an Astro build, a Next.js app, a native client, or three of those at once, and all of them read the same content from the same place. Changing how the site looks never means migrating content, and changing the content never means redeploying a CMS.
Every workspace is fully isolated: its own database, its own users, its own API keys, its own storage. Nothing is shared between workspaces except the software itself.
The vocabulary
These words appear on every page that follows.
| Term | What it means |
|---|---|
| Workspace | Your isolated tenancy, reached at its own subdomain: {your-workspace}.sedgemark.app. That hostname is also the base URL of your API, so every request you make is already scoped to you. |
| Collection | A structure you define: blog_post, product, author. It has a name, a slug, a list of typed fields, and a visibility of public, gated, private, which decides what reading it over the API needs: see Content API → Visibility. Every entry belongs to exactly one collection and shares its shape. |
| Slug | The machine-readable name of a collection, a field or a form: blog_post for “Blog Post”. Sedgemark derives it from the display name, and it is what appears in API paths and JSON keys. Slugs use underscores, never dashes. |
| Field | One typed slot on a collection: text, rich text, a number, a date, a media reference, a relation to another collection, and so on. See the field type table. |
| Entry | One row of a collection: one blog post. Every entry is either a draft or published, and the HTTP API only ever returns published entries. The MCP tools call an entry an item ( list_items, get_item); they are the same thing. |
| Media asset | An uploaded file. A media field stores the asset’s id, not a URL; you turn one into a URL with the media endpoint. |
| Form | A public, unauthenticated endpoint your own site can POST into: a contact form or a newsletter signup. It is the only way anything writes to Sedgemark without a key. See Forms. |
| API key | A bearer token carrying a set of permission grants. Keys read private content, authenticate the MCP server, and generate the TypeScript client. See Authentication. |
Three ways to work with your content
They are the same content and the same permission model underneath. Which one you reach for depends on what you are building.
- The HTTP API. Plain
GETrequests returning JSON, at/api/v1. Call it from a build step, a server or a script. It sends no CORS headers, so it is not a browser-facing API. Start at Content API. - A generated TypeScript client. Sedgemark writes a typed client for your collections, so your editor knows your field names and your build fails when you rename one out from under the site. There is also an Astro content-layer loader. See TypeScript client.
- The MCP server. Every workspace exposes a Model Context Protocol endpoint, so an AI agent can read your schema, draft content into it, and manage forms, all inside its own tool loop, with a key whose scope you chose. See MCP server.
The HTTP API is read-only for content.
There is no POST /api/v1/blog_post. Content is written from the dashboard
or through the MCP tools; the single exception is form submission, which is a public
write that can never read or modify anything else.
Everything in these docs
Getting started
HTTP API
Content API
Read published entries: endpoints, pagination, field types and the system columns on every row.
Media
Turn a media field id into an image URL, and read an asset’s dimensions and MIME type.
Forms
The one public write endpoint: descriptors, validation, anti-spam and CORS.
Errors & rate limits
Status codes, error body shapes and the shared per-IP request budget.
Platform features
Integrations
TypeScript client
A generated, fully typed client for your own collections, plus the Astro content-layer loader.
MCP server
Connect an AI agent to a workspace: transport, auth, and all 28 tools.
Webhooks
Event list, payload shapes, custom headers, payload formats, signature verification and debouncing.
Auto-rebuild on publish
Wire a webhook to a GitHub Actions workflow so publishing an entry triggers a build and a redeploy.