Managing content in Metabind Studio

Content management in Metabind Studio is the day-to-day editor surface — define content types, create entries, organize them in folders and tags, publish to production. This guide covers the workflow.

​

Content types: the schema

A content type defines the shape of an entry. Field types include: Content types are versioned. Editing a content type’s schema produces a draft; publishing the type makes the new schema available to all entries. To create a content type:

1. Open the Types tab in Metabind Studio.
2. Click +.
3. Enter a name and description, and pick a layout component.
4. Click Create.

​

Content entries: the data

Once a content type exists, editors create entries:

1. Open the Content tab.
2. Click + New entry.
3. Pick the content type.
4. Fill the fields in the editor; references and assets are picker-driven.
5. Save as draft, or publish.

Entries follow a draft → published lifecycle:

• Draft. Editable. Visible only in Metabind Studio (and to authenticated draft API consumers).
• Published. Read-only at the API surface. Editing creates a new draft on top.
• Unpublished. Removed from the published API but kept as draft.

​

Folders and tags

Both are searchable and filterable. Tags are lighter-weight; folders impose structure.

​

Search

The Content tab includes a search bar. Search is content-type-aware — narrow to a single type, filter by tag or folder, sort by created/updated date. For programmatic search, use the REST search API or GraphQL query.

​

Publishing

Click Publish on an entry; just that one updates. Publishing an entry makes it visible at the production API. Publishing a content type makes its schema available; existing entries don’t migrate automatically — you’d republish them after the schema change.

​

Migration when content types change

When a content type’s schema changes (e.g., adding a required field), existing entries need to migrate:

• Add an optional field? Existing entries continue to work; the new field is null until edited.
• Add a required field? Existing entries are flagged; you provide a default or migrate per-entry.

For bulk migrations, the REST API has /content/migrate and /content/bulk-migrate endpoints.

​

Content versions

Every entry tracks versions. Each save is a new version; publishing pins the published version.

• Version history. View every save with timestamp and author.
• Diff. Compare any two versions side-by-side.
• Roll back. Promote a previous version to current.

Versions are read-only after creation. The audit trail is immutable.

​

Locales

Each entry has a single locale, stored in metadata.locale (e.g., en-US). Entries don’t hold per-locale field values, and there is no fallback to a default locale.

​

Permissions

Project roles control content management:

• Viewer. Can browse content, can’t edit or publish.
• Editor. Can create, edit, publish drafts.
• Owner. Editor permissions plus content type schema edits and bulk operations.

For finer permissions (per-folder access, per-content-type access), use Roles in the REST API.

​

Related