> ## Documentation Index
> Fetch the complete documentation index at: https://docs.metabind.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Managing content in Metabind Studio

> Editor workflow for creating, organizing, and publishing content entries

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:

| Field | Use |
| - | - |
| Single-line text | Titles, names, short labels |
| Multi-line text | Body copy, descriptions |
| Number | Prices, counts, ratings |
| Boolean | Toggles (published/unpublished, featured) |
| Asset | An image, video, PDF, or 3D model |
| Reference | Link to another content entry |
| Group | A nested object with its own fields |
| List | Repeating items of any of the above |

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**.

<Note>
  **Screenshot needed:** Types tab with the schema editor open and several fields configured. Place at `/images/content/managing/content-type-editor.png`.
</Note>

## 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

| Surface | Use |
| - | - |
| **Folders** | Hierarchical containers — "Articles / 2026 / April" |
| **Tags** | Cross-cutting labels — "featured," "running shoes," "out-of-stock" |

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](/rest/content/search) or [GraphQL query](/content/querying/overview).

## 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`](/rest/content/migrate) and [`/content/bulk-migrate`](/rest/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](/rest/roles/overview).

## Related

<CardGroup cols={2}>
  <Card title="Querying content" icon="magnifying-glass" href="/content/querying/overview">
    APIs for client apps to read what editors create.
  </Card>

  <Card title="AI content creation" icon="wand-magic-sparkles" href="/content/ai-content-creation/overview">
    Using AI to draft and modify content.
  </Card>

  <Card title="REST API: Content" icon="code" href="/rest/content/overview">
    Programmatic content endpoints.
  </Card>

  <Card title="GraphQL API: Content" icon="diagram-project" href="/content/querying/overview">
    Flexible queries for client apps.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.