Dev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunitySubmit a ticketLog In
GitHubNuGetDev CommunitySubmit a ticket

Content type versions

Every piece of content created in Optimizely Content Marketing Platform (CMP) relates to the latest version of the content type. Content type versions track and manage changes made to the structure of a content type. Each content type (like a blog post, product, or recipe) has a history of modifications, letting you see a history of changes and restore previous versions.

If the following changes occur to a content type, a field definition version can be updated instead of creating a new version. Changes outside of these conditions must create a new content type.

  • Change the name of a field.
  • Change the description of a field.
  • Order the field.
  • Change a currently required field to an optional (non-required) field.
  • Change an internationalization requirement to optional.
  • Add an optional field to the content type.

You can also merge field definition versions in the following advanced cases:

  • Merge string fields
  • Relax boundary validations for date, choice, and number fields
  • Relax list boundaries (lower a minimum or raise a maximum)
  • Relax string length boundaries (increase max length, decrease min length; applies for rich text field also)
  • Remove validation patterns
  • Allow additional types of assets for the library field.
  • Allow new content types for the content type relation field.

Migrate a content's content type version

The following are APIs for migrating content's content type version.

  • Supervised Content Migration APIIt accepts a new version for the content with the target content type version. The content type version has to belong to the original content type.

  • Managed Content Migration API – This API facilitates bulk content migration, specifically targeting the migration of content type versions to the latest version of the respective content type. However, successful migration depends on the automatic migration capability of the new versions of the content types. The following factors contribute to managed migration:

    • Add a required field with a default value.
    • Add a non-required field (it does not matter whether there is a default value).
    • Mark a non-required field as required, which has a default value.
    • Expand the referenceable content types associated with a reference field.
    • Change a field from singular to list.
    • Remove a field.

When managed migration does not work, use supervised migration to migrate the content's content type version.

Content type versions in Optimizely Graph

Every content type version is a separate schema in Optimizely Graph. When querying for a content type, you should query against the base type in a schema. The versions typically have a suffix of Vn where n is a positive integer of the version's sequence, such as V1,V2, and so on.

Leverage instances to test models

When using OCC, you should consider having at least one additional instance on top of the production instance. Use the additional instance for development purposes as a test bed when modeling content types. Also, take advantage of the content type APIs to copy content types from one instance to another, which gives you greater control in developing, testing, and delivering content types to production.

The following reasons make managing content types as source code a powerful practice. This approach promotes consistency, reliability, control, and adaptability in managing your content structure—essential when scaling content operations.

  • Version control – Tools like Git provide robust version tracking for your content models. You can view a detailed history of changes and easy rollback options and collaborate on adjustments.
  • Automation – Defining content types as code enables seamless integration into continuous integration or continuous deployment (CI/CD) pipelines. Changes can be tested, deployed, and potentially rolled back automatically.
  • Infrastructure as code alignment – Standardizes how you manage configuration across your project alongside traditional code components.
  • Auditability and transparency – Modifications to content types are logged the same way as any code changes to improve record-keeping and accountability for content structure decisions.
  • Portability – Code-based content types facilitate migration between environments (dev, staging, production) to minimize inconsistencies and manual errors.