Documentation

Field types

Blobify supports 14 field types. Every type except taxonomy can be marked translatable: true, including blocks. A translatable value is stored as a locale map such as { "en": value, "is": value }.

required is valid on every type except boolean. A boolean already has a true or false value, so a required flag has no useful meaning.

Type reference

Type	Stored value	Important configuration
`text`	String	`appearance: "color"` is an optional editor hint
`slug`	String	`sourceField`, `unique`
`richtext`	Root AST	`allowedNodes`, `allowedMarks`, `headingLevels`, `allowedModels`, `allowedBlocks`, `allowAssets`
`number`	Number	No type-specific option
`boolean`	Boolean	Cannot be `required`
`datetime`	ISO datetime or `YYYY-MM-DD`	`dateOnly: true` stores a date only
`select`	String or string array	`options`, plus `multiple: true` for several values
`asset`	Asset reference	`accept`, `spaceScope`, `spaces`
`array`	Primitive array	Strings and numbers only
`reference`	Content reference or reference array	`model` or `models`, `multiple`, `spaceScope`, `spaces`
`taxonomy`	Array of `{ scheme, id }` concept references	`scheme`, `multiple`, `maxItems`, `rootConcept`, `allowedConcepts`
`link`	Internal, asset, or external link object	`model` or `models`, `allowExternal`, `allowAssets`
`blocks`	Block object or block array	`allowedBlocks`, `multiple`, optional `translatable` block trees
`json`	Any JSON value	Escape hatch for data without an editor schema

All fields can also use the common properties label, description, defaultValue, and groupId. groupId applies to fields in a model schema, not fields in a block schema.

Text and slug

Use text for names, titles, short descriptions, and labels. The appearance option changes only the editor control. It does not change the stored string.

json

code

{
  "title": {
    "type": "text",
    "required": true,
    "translatable": true
  },
  "brandColor": {
    "type": "text",
    "appearance": "color",
    "defaultValue": "#2563eb"
  },
  "slug": {
    "type": "slug",
    "sourceField": "title",
    "unique": true,
    "required": true
  }
}

unique is supported on text and slug. A translatable unique field is unique per locale. A non-translatable unique field is unique globally. Saving the model derives a required field index for the unique field.

Numbers, booleans, dates, and selects

json

code

{
  "price": { "type": "number", "required": true },
  "featured": { "type": "boolean", "defaultValue": false },
  "publishedAt": { "type": "datetime" },
  "eventDate": { "type": "datetime", "dateOnly": true },
  "categories": {
    "type": "select",
    "options": ["news", "guide", "release"],
    "multiple": true
  }
}

A regular datetime is stored as an ISO 8601 string. A date-only field is stored as a string such as 2026-07-13. A single select stores one option string. A multiple select stores an array of option strings.

Assets

An asset field stores a semantic reference, not a final media URL:

json

code

{
  "coverImage": {
    "type": "asset",
    "accept": "image"
  }
}

The accepted filters are image, video, media, pdf, document, and file. Omitting accept allows every file type.

When you create or edit content, write the reference into the field:

json

code

{
  "coverImage": { "type": "asset", "assetId": "mrcrushtyods56" }
}

A translatable asset field wraps the whole reference per locale:

json

code

{
  "coverImage": {
    "en": { "type": "asset", "assetId": "mrcrushtyods56" },
    "is": { "type": "asset", "assetId": "kkgluggi01" }
  }
}

A reference can also carry per-use framing:

json

code

{
  "type": "asset",
  "assetId": "img_456",
  "focalPoint": { "x": 0.28, "y": 0.52 }
}

spaceId is optional for cross-space references. Per-use focalPoint and crop data can frame an image without modifying the original. Localized alternative text belongs to the shared asset metadata document, not the content-field reference. See Content JSON.

Stored reference versus resolved media

The content document keeps the reference exactly as written, so API reads and MCP reads (getContent, findContent) return { "type": "asset", "assetId": "..." } and nothing else: no URL, no dimensions, no alt text. The generated client resolves each reference against the public asset catalog and fills in url, width, height, duration, alt, title, description, contentType, filename, and a resolved poster for video. Use the client for rendering rather than composing a bucket URL from an asset ID.

To get an asset ID, pick an existing asset in the asset library, or upload a new file. Over MCP that is findAssets for an existing file and the request, PUT, confirm upload flow for a new one. See MCP server.

References and links

A reference points to content by model and ID. Set either model for one target model or models for a polymorphic field. Do not set both.

json

code

{
  "author": { "type": "reference", "model": "author" },
  "related": {
    "type": "reference",
    "models": ["article", "page"],
    "multiple": true
  }
}

Stored references are semantic:

json

code

{
  "model": "author",
  "id": "author_1"
}

A link field can store one of three tagged shapes:

json

code

{
  "internal": { "type": "internal", "model": "page", "id": "page_1" },
  "asset": { "type": "asset", "assetId": "file_1" },
  "external": { "type": "external", "url": "https://example.com" }
}

Use spaceScope: "current" for the current space, spaceScope: "all" for any space in the organization, or spaceScope: "selected" with a spaces array.

Taxonomy

A taxonomy field assigns concepts from one organization-level scheme. Labels, hierarchy, and translations live in the scheme, so the content stores only concept IDs.

json

code

{
  "topics": {
    "type": "taxonomy",
    "scheme": "topics",
    "multiple": true,
    "maxItems": 10,
    "rootConcept": "nature"
  }
}

scheme is required. maxItems caps the count from 0 to 50, and exceeding it is the one taxonomy rule that blocks a write. rootConcept, or allowedConcepts for several subtrees, restricts the picker to part of the tree.

The stored value is always an array, even with multiple: false:

json

code

{ "topics": [{ "scheme": "topics", "id": "volcanoes" }] }

A taxonomy field cannot be translatable, because concepts are language-independent. It is always included in summaries, and it cannot be a field index or a list-index sort source. A model may define at most 10 taxonomy fields. See Taxonomies.

Arrays, blocks, and JSON

An array contains only strings or numbers. Use a multiple reference for repeatable content entities and blocks for repeatable embedded structures.

json

code

{
  "keywords": { "type": "array" },
  "sections": {
    "type": "blocks",
    "multiple": true,
    "allowedBlocks": ["hero-block", "quote-block"]
  },
  "integrationConfig": { "type": "json" }
}

Blocks default to multiple: true. With multiple: false, the field stores one block object. A non-translatable blocks field shares its structure across locales and can contain translatable inner fields. A translatable blocks field stores a separate block value for each locale.

Use json sparingly. It accepts arbitrary JSON, but the dashboard cannot provide the same structured editing and schema validation as normal fields.

Rich text

Rich text stores a root AST. It supports paragraphs, headings, lists, blockquotes, code, horizontal rules, asset nodes, embedded blocks, and internal content references. Schema options can restrict the allowed surface.

json

code

{
  "body": {
    "type": "richtext",
    "translatable": true,
    "allowAssets": true,
    "allowedBlocks": ["callout-block"],
    "allowedModels": ["article", "page"],
    "allowedMarks": ["bold", "italic", "code"]
  }
}

For the stored AST and block-node examples, see Content JSON.