Nuxt Advanced
IAB TCF
Turn on IAB TCF
IAB TCF is off until you turn it on. Add iab under the c15t key in
nuxt.config.ts; an empty object is enough:
With iab set, ConsentRoot renders the IAB banner and preference centre in
place of the standard ones while the visitor's policy uses the iab model and
names your CMP ID, and c15t installs __tcfapi. Configure the CMP ID and
vendors in your Inth project, or see
IAB TCF for a self-hosted backend. No extra
component or stylesheet is needed; the IAB components include their own
styles.
Without iab, or with iab: false or iab: { enabled: false }, IAB stays
off: no __tcfapi is installed, the app never loads @c15t/iab, and pages do
not prefetch it.
If a visitor's policy uses the iab model and the backend sends its vendor
list while IAB is off, the app throws an IABUnavailableError (code
C15T_IAB_UNAVAILABLE). The standard banner does not handle the IAB model,
so the visitor would otherwise get no working consent UI. A server render
fails and Nuxt renders its error page with status 500. On a page the browser
resolves itself, such as a prerendered page or one with ssr: false, the
module shows the same error page from the browser. Set iab, or remove the
iab model from the policy. A backend that answers gvl: null turns IAB off
for the request, and the policy runs as opt-in. See
troubleshooting.
Set iab in nuxt.config.ts rather than only in app.config.ts. The build
reads the module options to decide whether pages prefetch the IAB banner and
CMP. IAB set only in app.config.ts still works, but the browser fetches those
files only once the policy calls for them, so the CMP is ready later and, on
ssr: false pages, the IAB banner appears later. iab is read once, when the
app starts; changing it with updateAppConfig() has no effect.
To compose the IAB surfaces yourself, import
IABConsentBanner and
IABConsentDialog and
render them in place of ConsentRoot. For a custom preference centre, useConsentIabSelection()
reads the visitor's purpose and vendor selection and useConsentIabSave()
writes it and the TC String.
Restrict how vendors use a purpose
Publisher restrictions override a vendor's declared use of one purpose. Set
them under the module's iab option. The vendor IDs below are placeholders;
use vendors from your list whose declarations allow each restriction.
iab also takes publisherCountryCode, a vendors allowlist,
customVendors and cmpVersion. Fields you leave out come from the policy:
the CMP ID, custom vendors and vendor list arrive with /init. The CMP mounts
only while the visitor's policy uses the iab model.
Each restriction type has a requirement that depends on the vendor list:
restrictionType | Meaning | Allowed when the vendor |
|---|---|---|
0 | Purpose not allowed on any legal basis | declares the purpose for consent or legitimate interest |
1 | Consent required | declares the purpose for legitimate interest and lists it in flexiblePurposes |
2 | Legitimate interest required | declares the purpose for consent and lists it in flexiblePurposes |
Type 2 is never allowed for purposes 1, 3, 4, 5 and 6, which TCF allows
only with consent. TCF allows restrictions only in service-specific TC strings.
c15t always writes those, so the deprecated isServiceSpecific option has no
effect on restrictions.
c15t copies the restrictions when the CMP starts, so changing your array
afterwards has no effect.
c15t checks restrictions when the vendor list loads and again before each TC
String is encoded. Unsupported restrictions include type 3, which the spec
reserves, a vendor or purpose missing from the list, and a vendor with two
restriction types for one purpose. They are never dropped. Loading IAB
settings, saving and generating a TC String all reject with a
PublisherRestrictionError exported by @c15t/iab. On a createIAB handle
these are whenReady(), save() and generateTCString(). No TC String is
written and no consent is recorded. Retrying whenReady() does not fetch
another vendor list. The error lasts until a new vendor list is set up: with an
explicit gvl option that never happens, so saving keeps failing even if the
kernel later holds a different list. When the CMP follows the kernel's list
instead, a replacement list is checked again and saving works once it accepts
the restrictions. When a replacement vendor list makes a restriction
unsupported, c15t also clears the TC authority confirmed under the previous
list, so gated scripts stop until the configuration is fixed. Whenever c15t
withdraws the authority it confirmed, it also removes the TC String from the
euconsent-v2 cookie and localStorage entry. Because the check reads the
current vendor list, a vendor that stops declaring a purpose or its flexibility
makes a restriction invalid. Narrow a vendors allowlist and your restrictions
together.
Saved TC Strings carry the restrictions in their PubRestrictions section, and
__tcfapi('getTCData') reports them as publisher.restrictions, keyed by
purpose ID, then vendor ID. A stored TC String whose restrictions differ from
the current configuration is not restored. If the visitor's stored choice is
otherwise current, the banner opens again, as it does after a policy change,
and closes once the visitor saves. IAB gates that depend on the TC String stay
denied until then. c15t also removes the superseded TC String from the
euconsent-v2 cookie and localStorage entry, so vendors reading standard
storage do not pick it up. An unchanged configuration restores the stored TC
String without asking.
When reading a string written under TCF policy version 2 or 3, c15t accepts
type 2 for purposes 3 to 6, which those versions allowed. Strings c15t
writes always follow the current policy.
The React, Vue, Svelte and @c15t/browser/iab preference centres list each
vendor under the legal basis the restrictions leave it. A vendor whose purpose
now requires legitimate interest gets an objection control instead of a
consent toggle, and a prohibited purpose no longer lists the vendor. A
purpose whose vendors all use legitimate interest has no consent switch,
because turning one off would change nothing the vendors rely on; its
objection control is the opt-out. Such a purpose does not decide its c15t
category: the category follows the purposes in it that the visitor can
consent to. Legitimate interest never grants a category on its own. If none of
a category's purposes has a consent basis, nothing can consent to them, Accept
All included, so the category stays denied. See
categories under an IAB policy.
Stack switches
cover only the purposes some vendor processes on consent. Display-model rows
expose this as hasConsentBasis. Custom preference UIs can call
applyPublisherRestrictionsToGVL from @c15t/iab/headless, or pass
publisherRestrictions to processGVLForDialog, to get the same vendor
declarations. The configured restrictions are on the kernel's IAB state as
publisherRestrictions.
Consent-gated scripts, network rules and iframes with a vendorId also apply
the confirmed restrictions for that vendor:
- Type
0blocks a target that declares the purpose iniabPurposesoriabLegIntPurposes. - Type
1makes a purpose declared iniabLegIntPurposesrequire purpose and vendor consent. Legitimate interest no longer satisfies it. - Type
2makes a purpose declared iniabPurposesrequire purpose and vendor legitimate interest. Consent no longer satisfies it.
Types 1 and 2 block the target when the vendor list does not mark the
purpose as flexible for that vendor. Targets without a vendorId ignore
restrictions. A target that uses only legitimate interest once restrictions
apply is not blocked by a refused category, since it needs no consent; its
legitimate interest signals and the visitor's objection decide. GPC and strict
scope still block it, and the category stays refused for scripts that depend on
it. Accept All grants the vendor signal a restriction moves a purpose to,
including legitimate interest for a vendor that declares none. Legitimate
interest a restriction introduces applies until the visitor objects: the
preference centres show it as allowed, and saving without touching it encodes
it as allowed. introducedLegitimateInterest from @c15t/iab/headless lists
those purposes and vendors for custom preference UIs.
Vendor list during server rendering
For an IAB policy, the server HTML carries the banner's purpose names, vendor
count and a reference to the Global Vendor List, not the whole list. The banner
renders on the server with the same summary the browser shows. After
hydration, the IAB module fetches the full list and loads it before it saves a
TC String. In the default manifest() mode, the
module's init route serves the versioned list with a one-day public cache. Allow that
route, or your backend origin, in your CSP connect-src. See
Content Security Policy.
How the preference centre shows features
The stock IAB preference centres in React, Next.js, Vue, Svelte, Astro and the script tag follow TCF 2.4 and Policies v5.0.b. Special purposes stay in their locked section with a lock icon, because the visitor cannot object to them.
Features get their own section after the special purposes. It shows the IAB
standard text for features from the Global Vendor List's
standardTexts.features. If the list has no standard text, it shows the
iab.preferenceCenter.features.description translation. Each feature lists
its name, description, illustrations and the vendors that use it. The section has no switch, lock or vendor toggle, because
TCF forbids showing features next to a control that cannot be disabled.
The feature section follows the theme's spacing and typography tokens. Its disclosure arrows are decorative and stay out of the accessibility tree.
A custom preference UI gets the same rows from
resolveIABDialogDisplayModel in @c15t/iab/headless. essentialRows holds
the special purposes only. featureRows holds the features, with
locked: false and toggle: 'none', so render them without a control.
featuresStandardText is the standard text, or null when you should use the
translation.
Each vendor's privacy policy and legitimate interest links come from its
urls[] entry in the Global Vendor List. The stock preference centres pick
the entry for the language the banner shows, then English. A custom UI gets
the same links from resolveIABVendorUrls(vendor, language) in
@c15t/iab/headless, or from policyUrl and legitimateInterestUrl on the
vendors processGVLForDialog returns when you pass it language. Vendor lists
older than GVL v3 have a single policyUrl field, which c15t still reads.
Consent scope
c15t stores TCF choices per site and browser, which the TCF calls
service-specific scope. It does not sync TC strings across devices, and every
TC string it writes has IsServiceSpecific set to 1.
Do not use /consent/check or your own account data to skip the TCF banner on
another device. That turns the choice into multi-device scope, which the TCF
requires you to disclose in the first layer, and c15t does not show that
disclosure. The isServiceSpecific option is deprecated. c15t ignores it and
logs a warning when you pass false.
Verify IAB consent
Load a page under your IAB policy and confirm the IAB banner appears. In the
browser console, __tcfapi('getTCData', 2, console.log) returns a TC String
after you accept or reject. If Nuxt shows its error page with an
IABUnavailableError instead, iab is not set.