Documentation

Blobify documentation

Guides and reference for building with Blobify, the headless and contentless CMS. Written for developers and content teams who publish JSON to their own bucket and read it directly.

The dashboard manages models, editing, publishing, permissions, and webhooks.

Your published content lives in your own bucket as JSON files.

Websites and apps read published content directly from the bucket.

Developers and services can automate Blobify through the API.

Start here

Get up and running

Set up storage, model your content, and publish for the first time.

Getting StartedCreate an organization, connect storage, model content, and publish your first entry.How Blobify WorksSpaces, content files, summaries, and lookups, and what your site reads straight from the bucket.

Core concepts

Model and store content

How schemas, documents, and read-optimized artifacts fit together.

Models & BlocksDesign content types, page builders, references, and reusable blocks.Field TypesEvery supported field type, what it does, and when to reach for it.Content JSONThe shape of draft and published documents, localized fields, and embedded rich text.Summaries & IndexesSummaries, exact lookups, and ordered feeds, and how each fits frontend reads.

Integrations and automation

Connect other tools

Drive Blobify from scripts, AI tools, and your own backend.

Automation APIUse API keys to validate, import, save drafts, and publish from scripts or tools.MCP ServerLet Claude, Cursor, and other AI tools author content through the MCP server.WebhooksHandle publish events and revalidate frontend caches with URLs and cache tags.SSOConnect your identity provider with OIDC or SAML for single sign-on.

Operations

Access and security

Understand roles and permissions across your organization.

Security & AccessRoles, spaces, API keys, and which actions need stronger permissions.

Under the hood

What Blobify publishes

Blobify writes stable JSON artifacts into your bucket for websites, apps, and automation.

Your bucket

S3 or Cloudflare R2

s3://your-bucket/

A space is an independent content area with its own content, assets, and published files.

Optional path-hardening segment for content JSON. Asset media stays outside it.

content

summaries

lookups

list-indexes

assets

schemas

routing

Drafts, history, and full schemas that only the dashboard and authenticated tools use.

schemas

spaces

routing

Storage boundaries

A few prefixes keep delivery artifacts and editing data organized.

Public delivery paths

Published content is read directly from these bucket paths.

Optional root prefix: many orgs, one bucket

Give each organization its own root prefix and the whole tree above nests under it, so a single bucket can host many orgs side by side. Every key lives under the prefix: content, summaries, indexes, routing, and even asset media. Without one, the org owns the bucket root.

Optional content prefix: path hardening

You can add a per-space content prefix to add an extra folder segment for content JSON, summaries, indexes, and the asset catalog JSON, making direct bucket URLs harder to guess. Asset files still stay in assets/media/.

Path hardening only. If your app fetches content JSON in the browser, the prefix can still be visible in network requests. SSR/ISR keeps it less obvious.

Private authoring scope: drafts stay out of sight

Everything editors work with, from drafts and history to full schemas and asset metadata, lives in one unguessable folder: {privateStoragePrefix}/. Only the dashboard and authenticated tools know the prefix; public readers never see it.

Secrecy, not enforcement, by default. One bucket rule (an S3 policy that omits the folder, or a Cloudflare rule that blocks it) upgrades it to enforced access control.