Skip to main content

​
Versioning & Status Management

Metabind uses a consistent versioning and status management system across Components, Content Types, and Content. All entities follow the same lifecycle pattern with minor variations in how they are published.

​
Entity Status States

All entities can exist in one of five status states:

​
Draft

Initial status for entities that have never been published.
  • Version is null (no version number yet)
  • lastPublishedVersion is null
  • Working status where changes can be made freely
  • Updates overwrite previous changes without creating versions
  • Remains in draft until first publication
{
  "status": "draft",
  "version": null,
  "lastPublishedVersion": null
}

​
Modified

Status for published entities with unpublished changes.
  • Version is null (working copy)
  • lastPublishedVersion contains the last published version number
  • Original published version remains unchanged and available
  • Can discard changes to revert to published version
  • Changes get new version number when published
{
  "status": "modified",
  "version": null,
  "lastPublishedVersion": 3
}

​
Published

Entities that have been published and are immutable.
  • Has a version number (sequential integers: 1, 2, 3, etc.)
  • Content is immutable and cannot be changed
  • Must create a working copy to make changes (status becomes ‘modified’)
  • Referenced by other entities or packages
{
  "status": "published",
  "version": 3,
  "lastPublishedVersion": 3
}

​
Unpublished

Previously published entities made unavailable.
Only available for Content Types and Content (not Components).
  • Version number remains unchanged
  • Not available for new usage but existing references maintained
  • Can be re-published or edited (creates ‘modified’ working copy)
{
  "status": "unpublished",
  "version": 3,
  "lastPublishedVersion": 3
}

​
Deleted

Soft-deleted entities.
  • Preserves complete version history
  • Maintains availability in existing packages/references
  • Can be restored to draft or modified status
  • Prevents inclusion in new packages or usage
{
  "status": "deleted",
  "version": 3,
  "lastPublishedVersion": 3
}

​
Version Management Rules

RuleDescription
Version NumbersSequential integers starting at 1
Draft EntitiesHave null version (no version number)
Published VersionsAre immutable and permanent
Version CreationOnly occurs during publication
Version HistoryAll versions are preserved permanently
Package ReferencesComponents in packages cannot be deleted

​
Publishing Flow

​
Creating a New Entity

  1. Starts in draft status with version null
  2. Can be modified freely without versioning
  3. First publication assigns version 1

​
Editing a Published Entity

  1. Creates working copy with status modified
  2. Working copy has version null
  3. Original published version remains available
  4. Next publication creates new version

​
Discarding Changes

  • Only works for modified status (not draft)
  • Reverts to last published version
  • Cancels all unpublished changes

​
Rollback Process

  1. Creates new working copy from any previous version
  2. Does not modify existing versions
  3. New version created when published
  4. Preserves complete version history

​
Key Differences by Entity Type

EntityHow PublishedCan Be UnpublishedVersion Trigger
ComponentsVia Package creationNoPackage inclusion
Content TypesExplicit publish actionYesPublish action
ContentExplicit publish actionYesPublish action

​
Components

Components are published automatically when included in a Package:
  • No explicit “publish component” action
  • Version assigned when package is created
  • All draft/modified components in project are published together

​
Content Types & Content

Content Types and Content are published explicitly: 
POST /v1/organizations/:orgId/projects/:projId/content-types/:id/publish
POST /v1/organizations/:orgId/projects/:projId/content/:id/publish
  • Requires explicit publish action
  • Can be unpublished later
  • Version assigned immediately on publish

​
Version History

All entities maintain complete version history: 
GET /v1/organizations/:orgId/projects/:projId/components/:id/versions
GET /v1/organizations/:orgId/projects/:projId/content-types/:id/versions
GET /v1/organizations/:orgId/projects/:projId/content/:id/versions
Response: 
{
  "data": [
    {
      "version": 3,
      "status": "published",
      "content": "...",
      "createdAt": "2024-03-20T10:00:00Z",
      "createdBy": "user123"
    },
    {
      "version": 2,
      "status": "published",
      "content": "...",
      "createdAt": "2024-03-15T10:00:00Z",
      "createdBy": "user123"
    }
  ]
}

​
Best Practices

Keep entities in draft status while actively developing. This allows unlimited changes without creating version history clutter.
Since packages publish all components, create them at meaningful milestones rather than after every small change.
Instead of manually recreating old content, use the rollback endpoint to create a working copy from any previous version.
Components referenced by packages cannot be deleted. Use the deleted status to prevent future use while maintaining existing references.