Configure region and regulation rules
MCP tool names below are written account.previewComplianceChange; some clients list them as account_previewComplianceChange.
GDPR starter #
A new app declares GDPR and leaves region detection, Consent Mode and Global Privacy Control off. Ask the site owner once whether to turn the starter on. Apply it only after they accept. An earlier request to "make the site compliant" is not that answer.
Read subscriptionType from account.createApp or from account.getDesign (meta.subscriptionType).
On Pro, preview then commit exactly:
{"geolocation": true, "googleConsentMode": true, "facebookConsentMode": true, "microsoftConsentMode": true, "gpcSupportMode": true}
Leave geolocationMethod unset. It is already automatic, so the platform's region matrix applies. Do not send geolocationRules.
On Free (Basic, or any value other than Pro), the live banner keeps region detection off and keeps Meta and Microsoft Consent Mode off. Apply only:
{"googleConsentMode": true, "gpcSupportMode": true}
Say, in the same question, that region detection and the Meta and Microsoft signals stay off on the Free plan. Do not change regulations or any consent-mode map. GDPR stays the only declared law. This does not make the site legally compliant.
The preview is the write. If it reports a deletion or a warning the owner did not accept, stop and show it.
1. Two separate decisions — don't conflate them #
| Decision | Setting | What it does |
|---|---|---|
| Which laws apply to this site at all | config.regulations.<key> — gdpr, ccpa, otherus, ukpecr, lgpd, pipeda, popia (all boolean) |
A site-wide declaration. Not visitor-specific by itself. |
| Whether visitors get different treatment depending on where they are | config.geolocation (boolean) + config.geolocationMethod (automatic|manual) + config.geolocationRules[] |
Turns on visitor-location-based branching and defines what each region gets. |
Read the app's current values first with account.getDesign before changing either — both live under config.*, and step 3 below depends on it.
2. Declaring applicable regulations — safe to merge #
account.previewComplianceChange then account.updateComplianceConfig with, for example, {"regulations": {"gdpr": true, "ccpa": true}}. This merges against whatever the app already has stored: setting lgpd in a later call does not erase gdpr/ccpa. See Verified below — this was a real bug until 2026-09-29.
3. Per-region behavior — geolocationRules, and its one real hazard #
To actually treat an EU visitor differently from a California visitor, turn on geolocation: true, set geolocationMethod: "manual" (see step 4 for why), and send the full geolocationRules array — one entry per regulation name, each with its own display / revoke / blocking / privacy / doNotSell booleans:
{
"geolocation": true,
"geolocationMethod": "manual",
"geolocationRules": [
{"name": "gdpr", "display": true, "revoke": true, "blocking": true, "privacy": true, "doNotSell": false},
{"name": "ccpa", "display": true, "revoke": true, "blocking": false, "privacy": false, "doNotSell": true}
]
}
This array replaces wholesale — it is never merged. Sending only the gdpr entry silently deletes every other region's rules. account.previewComplianceChange warns about this at preview time, but nothing warns you at commit time, so read the preview. Always fetch the app's current geolocationRules with account.getDesign first, edit only the one entry you mean to change, and send the whole list back.
Valid names are the same seven keys as regulations.* above, plus other: the rule for visitors who match no other enabled rule. US visitors are the exception: outside California they match otherus only when it is enabled, and otherwise get no rule at all, so other does not cover them. other is kept whatever regulations says, so keep it in the list.
4. geolocationMethod: "automatic" silently discards your custom rules #
automatic is the default. In automatic mode, the Cookie Compliance server overwrites whatever geolocationRules you last stored with its own built-in default matrix on every live read — your custom per-region rules never reach a visitor. Set geolocationMethod: "manual" in the same change if you want the array in step 3 to actually take effect.
5. The legacy fallback, and why it matters even if you never touch it #
The widget only uses geolocationRules when it's non-empty and regulations is also non-empty. If either is empty, it falls back to three flat buckets instead — geolocationEUblocking / geolocationUSblocking / geolocationORblocking (plus matching *display / *dontsell / *privacy / *revoke keys) — and in that fallback, CCPA and "other US" visitors get the exact same treatment. If a site owner wants California treated differently from the rest of the US, geolocationRules (step 3) is the only way; the legacy booleans can't express it.
Verified #
Live-tested against a non-production test app on 2026-09-29, with publish:false throughout and every result confirmed against the stored configuration, not just the tool's response:
regulations.gdpr/ccpawritten, thenregulations.lgpdwritten alone: the stored draft ends up with all three set. Writes toregulations.*merge.geolocationRuleswritten with 2 entries, then with a 1-entry list: the dropped entry is gone from the stored draft. Writes togeolocationRulesreplace the whole list.
Steps 4 and 5 describe the documented behaviour of the server and the banner and have not yet been confirmed in a live browser test. Re-check them if either changes.