Skip to content

Configuration

Reference for the project configuration the consent runtime applies.

When the OptinStack script loads, it fetches your published project configuration and exposes the resolved result through the public window.OptinStack API. You do not configure the runtime by editing data on the page; you configure it in the dashboard, and the script applies it automatically.

Configuration is managed in the OptinStack dashboard. The reference below describes the shape of what the runtime applies, useful when reading window.OptinStack.config for debugging or custom integrations.

Published configuration is hostname-aware. Webflow, Framer, and custom sites use the same entitlement rules—platform choice never elevates features. Free can activate on each eligible hostname by default. A paid subscription attaches to one hostname and can move once to a registered, verified production hostname. Unassigned registered hostnames do not publish or serve runtime configuration. See Domain Scans for details.

window.OptinStack.config

After await window.OptinStack.ready, the resolved configuration is available read-only:

PropertyTypeDescription
config.siteobjectYour published site config: policies, trackers, presentation, compliance
config.policyobjectThe consent policy matched for the current visitor's region

config.site sections

SectionDescription
identitysiteId (project ID) and revision (config version)
scopePage targeting (pages: '*' or path list)
policyConsent policies, categories, GPC signals, renewal settings
inventoryTracker list for blocking and preferences UI
presentationTheme, legal links, locale strings, interaction (scroll lock), vendor list
complianceReserved compliance configuration. OptinStack is not currently an IAB TCF CMP and does not expose __tcfapi.

scope.pages (page targeting)

Control which paths show the banner and enforce consent UI:

ValueBehavior
'*' (default)All pages
Path listOnly matching pathnames (for example ['/shop', '/checkout'])

Off-target pages still load the runtime for API access, but the banner is not shown for that visit. Configure targeting in the dashboard.

policy.policies[]

Each policy defines region-specific consent behavior:

PropertyTypeDescription
idstringStable policy identifier (e.g. 'opt-in', 'dont-sell')
consentModel'opt-in' | 'opt-out' | 'informational'Consent model (defaults and decision semantics)
uiVariant'opt-in' | 'opt-out' | 'informational' | 'dont-sell'Banner UI (includes Do Not Sell presentation)
scope.regionsstring[]ISO region codes or 'global' / 'eu'

At runtime, window.OptinStack.mode reflects consentModel and window.OptinStack.uiVariant reflects uiVariant.

policy.renewal

PropertyTypeDescription
promptOnExpiryboolean (optional)Re-show the banner when consent expires
ttlDaysnumberConsent cookie expiration in days
shareAcrossSubdomainsbooleanShare consent across subdomains
record.securebooleanRequire HTTPS for consent cookies

See Consent Cookie for the stored cookie format and how shareAcrossSubdomains affects subdomain access.

presentation.locale and languages

English is the fixed source language. You can enable secondary locales from the dashboard (23 languages total, including English). Locale strings power banner and preferences copy. The runtime resolves the visitor language from html lang (then falls back to English when a locale is not enabled). Language packs are generated on publish and loaded from the CDN, not as a separate script install. Need a language that is not listed? Contact us to request it.

presentation.interaction.scrollLock

Optional background scroll lock while the banner or preferences UI is open (both, banner, preferences, or off depending on dashboard settings). Configure this in the dashboard; read it from config.site.presentation only for debugging.

Vendors

Vendor / provider definitions used by preferences and the tracker declaration appear under presentation (for example presentation.vendors / providers). They are managed from your tracker inventory and provider metadata in the dashboard.

Policy matching

The runtime evaluates policies in this priority order:

  1. Region match: a policy whose scope.regions contains the visitor's detected region
  2. EU match: if the visitor is in the EU and a policy includes 'eu'
  3. Global fallback: a policy with 'global' in scope.regions

Projects with region rules use the most specific matching policy available. Projects without region-specific rules fall back to the global policy.

Regional rules and geo-targeted banner behavior require a plan that includes geo-targeting. Projects without that entitlement use the published global policy.

When configuration takes effect

Changes you make in the dashboard apply to new visits after you publish. Existing visitors keep their stored consent until it expires or they change it.

Was this helpful?