Documentation last updated May 29, 2026
Adapter and release status
DatoCMS now has a dedicated public docs surface that separates the editor plugin lane from the frontend runtime delivered through Platform Core.
Current version
0.1.23
Delivery lane
Marketplace plugin
Compatibility notes
DatoCMS now has a dedicated public docs surface that separates the editor plugin lane from the frontend runtime delivered through Platform Core.
Key rollout changes
1. Treat DatoCMS as a headless CMS plus optional editor-side plugin lane.
2. Use Platform Core for the visitor-facing runtime in the frontend app.
3. Use the DatoCMS plugin for config preview, rollout guidance, and editor-side settings.
DatoCMS adapter: split plugin and frontend runtime model
Use this guide when DatoCMS is the content or configuration source but not the runtime layer where the consent banner actually renders.
- • Treat DatoCMS as a headless CMS plus optional editor-side plugin lane.
- • Use Platform Core for the visitor-facing runtime in the frontend app that renders DatoCMS content.
- • Use the standalone DatoCMS plugin for generated config preview and editor-side rollout guidance.
- • Register each live frontend hostname before publish.
Keep the runtime in the frontend app
The consent banner, settings reopen flow, audit, and runtime verification should still run in the frontend app that consumes DatoCMS content.
- • Generate `cookiezy-platform-core.zip` for the frontend runtime.
- • Use the DatoCMS headless scaffold plus the shared runtime assets.
- • Carry `siteKey`, `verifyUrl`, and `billingUrl` into the frontend runtime rather than trying to execute visitor consent logic inside DatoCMS.
Use the DatoCMS plugin for editor-side settings only
If editors need Cookiezy settings inside DatoCMS, add the standalone DatoCMS plugin lane and use it as a configuration surface, not as the storefront runtime.
- • Keep the plugin focused on editor-side settings and generated frontend config preview.
- • Do not position the plugin as the place where the storefront banner itself runs.
- • Use the generated config preview to align policy URL, locale routes, and optional integration identifiers with the frontend app.
Validate the live frontend that consumes DatoCMS content
After publish, verify the visitor-facing runtime on the real frontend hostname.
- • Banner appears on first visit.
- • Reject optional keeps optional categories blocked.
- • Accept all unlocks the configured categories.
- • Cookie policy audit renders on the frontend policy page.
- • Runtime verification returns `allowed: true` for the registered frontend hostname.
- • Frontend behavior stays aligned with the settings preview generated from DatoCMS.