Sharing Content Types Across Multiple Client Sites

You run twelve client sites at your agency and each one has a blog, a team page, and a services section. When you improve the blog post content type by adding a reading time field or a related posts reference, you want that improvement on every site, not just the one you happen to be working on. Shared content type libraries make this tractable.

The Multi-Space Problem

ContentGrid gives each project its own space. Content is isolated per space, which is correct: you do not want client A's content appearing on client B's site. But schemas are also per-space, which means schema drift accumulates over time. The solution is to treat your shared content types as a package and push schema updates via migration scripts rather than manual dashboard edits.

• Define canonical content types in a shared schema-library/ repository or directory.
• Write migration scripts that apply changes to a list of target spaces.
• Run migrations against all spaces from CI when the shared library changes.
• Keep site-specific extensions separate from shared types.

Structuring the Schema Library

Organise your shared types in a dedicated repository that all client projects reference:

• Create a content-types/ directory with one file per shared content type.
• Each file exports a ContentGrid schema definition object: field names, field types, validations.
• Create a migrations/ directory for changes to shared types.
• Publish the schema library as a private npm package so client projects can install it as a dependency.

When a shared type changes, you bump the package version, update the migration, and run the migration against all registered spaces.

Running Migrations Across Multiple Spaces

Write a migration runner script that loops over your client space IDs:

• Store all client space IDs and API keys in a secrets manager or environment file, never in the repository.
• The runner reads the space list, initialises a ContentGrid Management client per space, and calls the migration up function for each.
• Log the result per space (success or failure) and send a summary to a Slack channel.
• On failure, the runner continues to the next space rather than stopping, so one problem client does not block the others.

Extending Shared Types Per Client

Clients often need site-specific fields on top of shared types. Handle this with an extension pattern:

• Shared types define core fields that apply everywhere.
• Each client space has a separate local migration that adds site-specific fields to the shared type.
• The shared library migration only touches fields it owns: it never removes or changes site-specific fields.
• Document which fields are shared and which are local so future developers know what to change where.

This setup takes a day to build but pays back quickly on teams managing four or more client sites. Schema changes that used to take a week across all sites now take an afternoon, and all sites stay consistent without manual copying.