Working with Schema Import/Exports and Recipes

TLDR

Recipes and the Import/Export plugin in DatoCMS helps you avoid repetitive setup, standardize models across projects, and onboard faster. Like way faster. They reduce manual work and help scale content architecture across teams and environments.

What you can do with this combo:

• Onboard new devs with actual working schema instead of docs and a blank project

• Spin up new projects or micro-sites using fully-fledged models and blocks you've created before

• Keep structure consistent across projects, teams, and brands

• Extend existing schema elements into new ones with slight tweaks

• Recover deleted or deprecated models without starting over (⚠️ provided you keep backups, don't @ me)

• Build frontend component libraries backed by reusable schema

If you've ever worked across more than one DatoCMS project, this setup probably saves you hours.

But first. What're we talking about?

ICYMI, we recently rolled out the Schema Import and Export plugin not too long ago, which lets you export one or multiple models/block models as JSON files for reimport into another DatoCMS project. WITH all relevant relations, if you so choose.

This means, you can:

• Export single or multiple models/block models as JSON files

• Import models into different DatoCMS projects

• Smart conflict resolution with guided instructions

• Automatic plugin dependency detection and inclusion

• Safe import operations that preserve existing schema

This unlocks really fun use cases by itself, but having this plugin installed ALSO let's you easily import some readymade models and blocks to kickstart common projects that need things like a blog post or a newsletter signup.

Which is why we doubled down on schema imports by introducing Schema Recipes - a curated selection of ready-to-use models and blocks that you can import into your projects.

The first wave has common marketing blocks and models for:

• Global settings for things like navs and branding

• Blog post with authors

• Simple marketing landing pages built with blocks

• Case studies to flex your wins

• A simple newsletter signup connected to your external service, and

• A simple (and annoying, depending on how you look at it) marketing pop-up

Just check any of them out, hit "import" and we'll move it into whichever project you choose.

Nifty, eh?

Anyways...

For added context, when we say "recipes" it can either mean the community ones available via the marketplace, OR whatever schema you export and save as a JSON file to be reused across projects.

And also, the real magic kicks in when you pair these schema exports with frontend component libraries. Say your dev team builds a reusable HeroBanner component. You can keep the corresponding JSON schema export in the same repo. Anyone starting a new project can pull both in, the schema and the frontend, and have it running in minutes. 🤯

That’s what makes it work long-term. It’s not just about spinning up new DatoCMS models, it’s about standardizing content + presentation in a predictable, maintainable way. it can either mean the community ones available via the marketplace, OR whatever schema you export and save as a JSON file to be reused across projects.

OK, moving on.

Why structure matters

When you manage more than one DatoCMS project, or even just one really large one, the last thing you want to do is manually recreate models by hand. Why waste hours setting up the same blog, the same page builder, or the same SEO meta fields across projects?

Recipes and the Schema Import/Export plugin solve this. Recipes let you define reusable configurations for models and fields. Schema Import/Export gives you safe, conflict-aware migrations of actual model definitions between projects, with all dependencies handled.

Looking at how this works in practice

Onboarding new devs

If you're onboarding a new dev to your project, instead of asking them to poke around a production schema and reverse-engineer your work, you could just:

• Start a fresh DatoCMS project

• Import the blog, hero, and modular page builder models using JSON exports from your main project

• Drop in a few recipes to add global settings, favicon fields, and meta tag configs

• Let them play around

Now they have something they can actually build and test against.

Want them to understand how a multi-block landing page works? It’s already there.

Need to build previews or test image components? No need to fake fields or guess validation logic, it’s all imported.

They get real models, with real structure, ready to plug into your existing codebase if needed.

Spinning up new projects

You’ve got a marketing website, a campaign page, or a new market going live. You don’t want to redo the same structure again because you've spent way too long perfecting one project with all the presentation options and validations.

• Create recipes to scaffold common structures (landing pages, marketing pop-ups, reusable CTAs)

• Use the Import/Export plugin to bring in specific shared components from another project (e.g. FAQs, testimonials, pricing blocks)

• Run a migration script to bring in all the relevant content and assets into the new project structure without breaking a sweat.

Sounds vague? Let's imagine your team is launching a new product or site under the same umbrella brand.

You run multiple DatoCMS projects, maybe for different brands, maybe for different regions, and every team keeps naming the same thing slightly differently. That’s a problem. Especially when your frontend expects specific field keys or block structures.

With schema exports, you define your blocks once, like CtaBlock, NewsletterSignup, or PromoBanner, export them, and distribute the JSON to other teams or environments. The plugin safely merges the schema into each project. No accidental overrides. No duplicate field errors. Just consistent blocks, ready to go.

You don’t need to create the hero block from scratch or guess which field type the image uses. Just export it from the last project, import it here, and move on.

In fact - we recently collab'd with the fine folks at Bejamas to explore this exact use case. They built a gorgeous new Astro theme called Multilaunch to handle multiple projects for different brands under the same corporate structure, something that would be a breeze to manage with the plugin. Check out everything that covers!

If you’ve got localized versions to roll out (where just introducing i18n into your parent project doesn't make sense), it’s even better: same models, same logic, just localised content. The structure is already battle-tested.

Extending existing schema

Who says you always gotta be spinning up a new project for making the most of the plugin?

Let's say you got a really big and complicated website, and there's a very specific case study model with 50+ fields to showcase all the incredible work you did with some customers.

But now marketing wants to recreate this for showcasing work done with partners too, just that they'd need a few tweaks to the fields and 1-2 changes.

You really gonna sit there and make the whole model from scratch? Again? Nah fam.

Instead of rebuilding, you export the existing model, import it into your project, rename it to PartnerCase, tweak the field labels or validations, and publish. Done.

You keep consistency where it matters, and customize only what you need. Much faster than duplicating models by hand.

Recovering and restoring projects

Say someone deleted a model. Or you sunset a block last month that marketing suddenly wants to use again, but you don’t want to guess how it was set up.

If you’ve got a JSON export of that model from periodic backups, you’re covered (general life best practices to retain some things, just to be safe). Drop it into the Import/Export plugin, review the schema summary, and it’ll bring the block back exactly as it was: same fields, same validations, same plugin dependencies, same appearances. They'd never even know it was gone.

This is especially useful for blocks that were used across multiple pages or components, things that take time to reconstruct. You don’t need to dig through version history or re-read changelogs. Just re-import the schema and continue using it immediately.

Know what's even better? The plugin will tell you if anything in the incoming schema overlaps with your current project setup. So if you’re reviving an older block in a project that’s evolved since, you’ll see what might conflict before you confirm anything.

If you’re smart about keeping exports of your schemas (e.g. in your repo or backup folder), this becomes a lightweight version of schema version control. You’re not reinventing anything. You’re just rolling forward with the old work you already vetted.

Using the plugin is really a super-safe way to scale your schema. This plugin won’t overwrite anything. It only adds new models or blocks and shows you conflicts before anything is applied. It pulls in any dependencies automatically, related blocks, required plugins, field appearance settings, and validations, without you having to double-check everything manually.

It’s schema portability with guardrails. You keep control. And your team doesn’t waste hours manually replicating things project to project.

And if you’re just starting out, the Recipes are a solid base layer. Import them, tweak what you need, and move on to the actual build.

Future you will thank current you.