CookiezyCookiezy
ProductPlatformsDocsPricingBlogContact
  1. Home/
  2. Docs/
  3. DatoCMS Adapter Setup

Documentation last updated May 29, 2026

Docs navigation

Overview

DocsDeveloper-first documentation for installing, configuring, and verifying Cookiezy across every supported adapter.Getting StartedCheck readiness, generate the right package, then ship the core flow.InstallationInstallation follows the same core pattern everywhere: generate the issued package, register the hostname, install the adapter, and validate runtime verification before launch.ConfigConfiguration keeps locale, policy, categories, layout, and licensing context in sync.

Reference

APIDeveloper-facing runtime methods, browser events, and verification-aware integration notes.

Adapters

Webflow Adapter SetupTechnical Webflow setup guide for Cookiezy: what you receive after purchase, where each file goes, and how to validate the runtime on a published Webflow site.Shopify Adapter SetupTechnical Shopify setup guide for Cookiezy: download Platform Core, deploy the theme app extension, expose the Theme Editor fields, and validate storefront consent behavior before publish.Wix Adapter SetupTechnical Wix setup guide for Cookiezy: install the private or unlisted Wix app, connect the correct Cookiezy account, publish the app-hosted runtime, and keep custom code only as a fallback.Hugo Adapter SetupTechnical Hugo setup guide for Cookiezy: generate the dedicated Hugo package, copy the issued config scaffold, align locale routes, and validate banner plus cookie audit behavior.Headless Adapter SetupTechnical headless setup guide for Cookiezy: boot the plain adapter, wire runtime verification, and validate the audit, settings, and restricted-mode recovery flow in custom frontends.WordPress Adapter SetupTechnical WordPress setup guide for Cookiezy: upload the plugin ZIP, configure licensing-aware settings, and validate shortcode-based settings and audit behavior.React Adapter SetupTechnical React setup guide for Cookiezy: load the plain adapter from the app shell, gate optional services with consent state, and validate SPA behavior.Next.js Adapter SetupTechnical Next.js setup guide for Cookiezy: load the plain adapter from the root layout, keep policy routing localized, and validate consent gating across App Router pages.Strapi Adapter SetupTechnical Strapi setup guide for Cookiezy: keep the runtime on the frontend, use Strapi as a configuration bridge, and map locale-aware policy URLs through the shared core model.DatoCMS Adapter SetupTechnical DatoCMS setup guide for Cookiezy: keep the visitor-facing runtime in the frontend app, use Platform Core for runtime assets, and use the standalone DatoCMS plugin only for editor-side configuration and generated frontend config preview.
Adapter versioningDatoCMS Adapter Setup

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.

Overview

DatoCMS adapter: split plugin and frontend runtime model

Cookiezy

Lightweight consent platform for modern websites.

Product

FeaturesPlatformsPricingDocsBlogContact

Legal

Cookie PolicyPrivacy PolicyTerms

Language

Privacy controls

© 2026 Cookiezy. All rights reserved.

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.
Step 1

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.
Step 2

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.
Step 3

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.