@c15t/nextjs 2.0.0-rc.6 → 2.0.0-rc.8

package/docs/components/consent-dialog.md

@@ -81,9 +81,36 @@ Hide the c15t branding in the dialog footer:
 <ConsentDialog hideBranding />
 ```
 
-## Compound Components
+## Styling First
 
-Build fully custom dialog layouts using sub-components:
+> ℹ️ **Info:**
+> If you are only changing visuals, stay with the stock dialog and use the theme system first. Start with tokens and slots such as consentDialogCard, consentDialogHeader, and consentDialogFooter. See Styling Overview.
+
+```tsx
+<ConsentManagerProvider
+  options={{
+    theme: {
+      colors: {
+        surface: '#fffdf8',
+        surfaceHover: '#f6f3ee',
+      },
+      slots: {
+        consentDialogCard: 'rounded-[32px] shadow-xl',
+        consentDialogHeader: 'gap-3',
+        consentDialogFooter: 'border-t border-black/10 px-6',
+      },
+    },
+  }}
+>
+  <ConsentDialog />
+</ConsentManagerProvider>
+```
+
+Dialog copy should be changed through `ConsentManagerProvider.options.i18n`, not by rebuilding the dialog structure.
+
+## Advanced: Compound Components
+
+Use compound components only when you need custom dialog markup while still keeping c15t primitives and policy-aware footer actions:
 
 ```tsx
 <ConsentDialog.Root>
@@ -94,7 +121,12 @@ Build fully custom dialog layouts using sub-components:
       <ConsentDialog.HeaderDescription />
     </ConsentDialog.Header>
     <ConsentDialog.Content>
-      <ConsentWidget />
+      <ConsentWidget.Root>
+        <ConsentWidget.Accordion type="single">
+          <ConsentWidget.AccordionItems />
+        </ConsentWidget.Accordion>
+        <ConsentWidget.PolicyActions />
+      </ConsentWidget.Root>
     </ConsentDialog.Content>
     <ConsentDialog.Footer />
   </ConsentDialog.Card>
@@ -109,6 +141,7 @@ Build fully custom dialog layouts using sub-components:
 * `ConsentDialog.Content` — Main content area (typically contains `ConsentWidget`)
 * `ConsentDialog.Footer` — Footer with optional branding (`hideBranding` prop)
 * `ConsentDialog.Overlay` — Backdrop overlay
+* `ConsentWidget.PolicyActions` — Renders policy-aware grouped dialog actions
 
 For a quick pre-composed layout, use the shorthand card:
 
@@ -118,6 +151,12 @@ For a quick pre-composed layout, use the shorthand card:
 </ConsentDialog.Root>
 ```
 
+`ConsentWidget.PolicyActions` uses stock c15t widget buttons and translations by default. Pass `renderAction` only when you need to customize the action mapping, and return stock widget button compounds if you want to preserve built-in behavior and copy.
+
+For fully manual control over dialog action rendering, use `useHeadlessConsentUI()` and map `dialog.actionGroups` yourself.
+
+If the stock dialog structure still works, prefer tokens, slots, and provider configuration instead.
+
 ## Props
 
 ### ConsentDialogProps

package/docs/components/consent-manager-provider.md

@@ -54,6 +54,7 @@ Event callbacks for consent actions.
 |:--|:--|:--|:--|:--:|
 |onBannerFetched|Callback\<OnBannerFetchedPayload> \|undefined|Called when the consent banner is fetched.|-|Optional|
 |onConsentSet|Callback\<OnConsentSetPayload> \|undefined|Called when the consent is set.|-|Optional|
+|onConsentChanged|Callback\<OnConsentChangedPayload> \|undefined|Called only when an explicit consent save changes the previously saved consent state.|-|Optional|
 |onError|Callback\<OnErrorPayload> \|undefined|Called when an error occurs.|-|Optional|
 |onBeforeConsentRevocationReload|Callback\<OnConsentSetPayload> \|undefined|Called before the page reloads when consent is revoked.|-|Optional|
 
@@ -325,7 +326,7 @@ In hosted mode (recommended), the backend resolves the correct policy automatica
 
 ### Fallback: Offline Policies
 
-When no backend is available, `ConsentManagerProvider` accepts `offlinePolicy.policyPacks` for local policy resolution:
+When no backend is available, `ConsentManagerProvider` accepts `offlinePolicy.policyPacks` for local policy resolution during development, testing, previews, or temporary backend outages:
 
 ```tsx
 <ConsentManagerProvider
@@ -376,6 +377,7 @@ When no backend is available, `ConsentManagerProvider` accepts `offlinePolicy.po
 Notes:
 
 * `offlinePolicy` is only used in `offline` mode.
+* Treat offline policies as a development/testing tool or resilience fallback, not the primary production source of truth.
 * `offlinePolicy.i18n` lets offline mode mirror hosted `messageProfile` and profile-local `fallbackLanguage` behavior.
 * Omitting `offlinePolicy.policyPacks` uses the built-in synthetic opt-in fallback banner. Hosted network fallback uses the same opt-in banner.
 * `offlinePolicy: { policyPacks: [] }` is explicit no-banner mode.

package/docs/components/consent-widget.md

@@ -35,22 +35,43 @@ export function PrivacySettingsPage() {
 
 Each consent category is rendered as an expandable accordion item. Clicking the category header expands it to show a description and any associated services. Users can toggle individual categories on or off using the switch control. The `necessary` category is always enabled and cannot be toggled.
 
-## Compound Components
+## Styling First
 
-Build fully custom widget layouts using sub-components:
+> ℹ️ **Info:**
+> Most widget customization should stay in the stock component. Use theme tokens and slots such as consentWidgetAccordion, consentWidgetFooter, and toggle before reaching for compound components. See Styling Overview.
+
+```tsx
+<ConsentManagerProvider
+  options={{
+    theme: {
+      colors: {
+        surface: '#fffdf8',
+        surfaceHover: '#f6f3ee',
+      },
+      slots: {
+        consentWidgetAccordion: 'rounded-3xl border border-black/10',
+        consentWidgetFooter: 'border-t border-black/10 px-6',
+        toggle: 'shadow-sm',
+      },
+    },
+  }}
+>
+  <ConsentWidget />
+</ConsentManagerProvider>
+```
+
+Widget copy should be changed through `ConsentManagerProvider.options.i18n` so the inline UI stays aligned with the rest of the consent experience.
+
+## Advanced: Compound Components
+
+Use compound components only when you need to rearrange the widget's existing primitives while keeping policy-aware action grouping:
 
 ```tsx
 <ConsentWidget.Root>
   <ConsentWidget.Accordion type="multiple">
     <ConsentWidget.AccordionItems />
   </ConsentWidget.Accordion>
-  <ConsentWidget.Footer>
-    <ConsentWidget.FooterSubGroup>
-      <ConsentWidget.RejectButton />
-      <ConsentWidget.AcceptAllButton />
-    </ConsentWidget.FooterSubGroup>
-    <ConsentWidget.SaveButton />
-  </ConsentWidget.Footer>
+  <ConsentWidget.PolicyActions />
 </ConsentWidget.Root>
 ```
 
@@ -62,12 +83,73 @@ Build fully custom widget layouts using sub-components:
 * `ConsentWidget.AccordionContent` — Collapsible content area
 * `ConsentWidget.AccordionArrow` — Expand/collapse indicator
 * `ConsentWidget.Switch` — Category toggle switch
+* `ConsentWidget.PolicyActions` — Renders grouped policy-aware actions
 * `ConsentWidget.Footer` — Footer container
 * `ConsentWidget.FooterSubGroup` — Groups related buttons
 * `ConsentWidget.AcceptAllButton` — Accepts all consent
 * `ConsentWidget.RejectButton` — Rejects all consent
 * `ConsentWidget.SaveButton` — Saves custom selections
 
+## Using `renderAction` with c15t Defaults
+
+`ConsentWidget.PolicyActions` renders stock c15t buttons and translations by default.
+
+```tsx
+<ConsentWidget.PolicyActions />
+```
+
+`renderAction` is optional. Return the stock button compounds when you want custom mapping while preserving built-in c15t behavior and copy:
+
+```tsx
+<ConsentWidget.PolicyActions
+renderAction={(action, props) => {
+  const { key, ...buttonProps } = props
+
+  switch (action) {
+    case 'accept':
+        return <ConsentWidget.AcceptAllButton key={key} {...buttonProps} />
+    case 'reject':
+        return <ConsentWidget.RejectButton key={key} {...buttonProps} />
+    case 'customize':
+        return <ConsentWidget.SaveButton key={key} {...buttonProps} />
+  }
+}}
+/>
+```
+
+Use `useTranslations()` only when you are replacing the button markup entirely:
+
+```tsx
+import { ConsentWidget, useTranslations } from '@c15t/react';
+
+export function CustomWidgetActions() {
+  const { common } = useTranslations();
+
+  return (
+    <ConsentWidget.PolicyActions
+      renderAction={(action, props) => (
+        <button
+          key={props.key}
+          type="button"
+          className={props.isPrimary ? 'btn-primary' : 'btn-secondary'}
+          style={props.style}
+        >
+          {action === 'accept'
+            ? common.acceptAll
+            : action === 'reject'
+              ? common.rejectAll
+              : common.save}
+        </button>
+      )}
+    />
+  );
+}
+```
+
+For a fixed footer layout, render `ConsentWidget.Footer` and `ConsentWidget.FooterSubGroup` manually instead of using `ConsentWidget.PolicyActions`.
+
+If the stock widget structure is already correct, stay with tokens and slots instead of rebuilding the layout.
+
 ## Props
 
 ### ConsentWidgetProps

package/docs/concepts/client-modes.md

@@ -4,12 +4,12 @@ description: Choose how c15t connects to its backend - full hosted integration,
 ---
 c15t supports three client modes that determine how consent data is stored and synchronized. Choose the mode that matches your infrastructure:
 
-* **Hosted mode** - Full backend integration with geolocation, API sync, and analytics
-* **Offline mode** - Local-only storage with no network requests
+* **Hosted mode** - Recommended for production. Backend-backed consent with geolocation, centralized policy resolution, audit history, and offline fallback.
+* **Offline mode** - Browser-only storage with no network requests. Best for local development, demos, static deployments, or controlled fallback scenarios.
 * **Custom mode** - Bring your own backend with custom endpoint handlers
 
 > ℹ️ **Info:**
-> Offline mode is browser-only storage. If browser storage is blocked or cleared, consent cannot be remembered and prior choices cannot be verified.
+> If you need durable consent records, server-side enforcement, or automatic jurisdiction detection, use hosted mode. Offline mode cannot provide those guarantees because consent lives only in the browser.
 
 <span id="c15t-mode" />
 
@@ -30,6 +30,13 @@ The default mode. Connects to a c15t backend for full consent lifecycle manageme
 
 * `backendURL` (required) - API endpoint path
 
+**Why it is the default for production:**
+
+* The backend stays the source of truth for policy, translations, and jurisdiction logic
+* Consent decisions can be stored beyond the current browser session for audit and support workflows
+* Server-side systems can preload consent-aware behavior instead of waiting for client-only storage
+* If the backend is temporarily unavailable, c15t can fall back locally and re-sync later
+
 **Best for:** Production apps that need geolocation-based jurisdiction detection, consent record storage, and compliance audit trails.
 
 ```tsx
@@ -78,10 +85,12 @@ If consent is not stored at all (for example, storage is blocked or frequently c
 
 * No automatic geolocation or jurisdiction detection
 * No consent audit trail
+* No centralized policy or translation updates without shipping frontend changes
 * No cross-device sync
+* No server-side visibility before client initialization
 * Works without any backend infrastructure
 
-**Best for:** Static sites, development/testing, or as a starting point before setting up a backend.
+**Best for:** Local development, Storybook/static demos, resilience fallback, or simpler sites that explicitly accept browser-only consent storage.
 
 ```tsx
 import { type ReactNode } from 'react';
@@ -156,7 +165,10 @@ export function ConsentManager({ children }: { children: ReactNode }) {
 |Feature|Hosted|Offline|Custom|
 |--|--|--|--|
 |Geolocation|Automatic|Manual via overrides|Your implementation|
+|Policy source of truth|Backend-managed|Bundled into the frontend|Your implementation|
 |Consent sync|API|Local only|Your implementation|
+|Audit trail|Backend records|Not available|Your implementation|
+|Server-side consent awareness|Supported|Not available|Your implementation|
 |SSR data|Supported|Not available|Your implementation|
 |Analytics|Built-in|Not available|Your implementation|
 |Infrastructure|c15t backend|None|Your backend|

package/docs/concepts/initialization-flow.md

@@ -88,7 +88,7 @@ If the resolved model is `none` or `opt-out` (and `ui.mode` is `none`), consents
 
 ## Debugging the Lifecycle
 
-Use the DevTools panel and callbacks to inspect each step of the initialization flow:
+Use the DevTools panel and callbacks to inspect each step of the initialization flow. `onConsentSet` is the broad lifecycle signal; `onConsentChanged` and `subscribeToConsentChanges()` are the change-only signals for explicit post-init saves.
 
 |Step|DevTools Panel|Callback|What to check|
 |--|--|--|--|
@@ -98,6 +98,7 @@ Use the DevTools panel and callbacks to inspect each step of the initialization
 |Banner visibility|Consents|—|`activeUI` in store state; does policy `ui.mode` require it?|
 |Re-prompting|Policy|—|Fingerprint mismatch between stored and resolved policy?|
 |Consent save|Consents + Events|`onConsentSet`|`preferences` object in callback payload|
+|Change-only integrations|Events|`onConsentChanged` or `subscribeToConsentChanges()`|`allowedCategories`, `deniedCategories`, and previous values only when a real save changed preferences|
 |Script loading|Scripts|`onConsentSet`|Script IDs and their load/blocked status|
 |Reload on revocation|Events|`onBeforeConsentRevocationReload`|Fires before reload; check localStorage for `c15t:pending-consent-sync`|
 |Deferred sync|Events|`onError` (if sync fails)|After reload, check Events panel for successful API call|
@@ -120,7 +121,13 @@ export default function ConsentManager({ children }: { children: ReactNode }) {
             console.log('Init complete:', { jurisdiction, location });
           },
           onConsentSet: ({ preferences }) => {
-            console.log('Consent saved:', preferences);
+            console.log('Broad consent lifecycle event:', preferences);
+          },
+          onConsentChanged: ({ allowedCategories, deniedCategories }) => {
+            console.log('Explicit consent change:', {
+              allowedCategories,
+              deniedCategories,
+            });
           },
           onBeforeConsentRevocationReload: ({ preferences }) => {
             console.log('Reloading due to revocation:', preferences);

package/docs/concepts/policy-packs.md

@@ -10,9 +10,9 @@ There are three ways to configure policy packs:
 
 1. **consent.io (recommended)** — use [consent.io](https://consent.io) as your hosted backend. Configure packs visually in the dashboard or via API — no code changes required. Works with any frontend, including static sites.
 2. **Self-hosted backend** — define packs in code via `policyPacks` and resolve them from real request geo data. Full control over policy logic and storage.
-3. **Offline fallback** — pass the same policy shapes to the frontend via `offlinePolicy.policyPacks`. Used as a resilience fallback when the backend is unreachable, or for quick local experimentation and demos. If you omit `offlinePolicy.policyPacks`, c15t falls back to a synthetic worldwide opt-in banner instead of no-banner mode.
+3. **Offline fallback** — pass the same policy shapes to the frontend via `offlinePolicy.policyPacks`. Use this mainly for local development, demos, deterministic testing, or resilience when the backend is temporarily unreachable. If you omit `offlinePolicy.policyPacks`, c15t falls back to a synthetic worldwide opt-in banner instead of no-banner mode.
 
-In both hosted and self-hosted modes, the **backend is always the source of truth**. Offline packs never override a live backend decision.
+In both hosted and self-hosted modes, the **backend is always the source of truth**. Offline packs are a preview or fallback layer and never override a live backend decision.
 
 ## Quickstart
 

package/docs/headless.md

@@ -4,11 +4,12 @@ description: Build fully custom consent UI using only hooks - no pre-built compo
 ---
 c15t's headless mode means using the hooks (`useConsentManager`, `useTranslations`, etc.) without any pre-built UI components. This gives you complete control over the consent experience.
 
-There are three levels of customization:
+Before you go headless, walk the customization ladder in order:
 
-1. **Props** - Use pre-built components with custom text and configuration
-2. **noStyle** - Use pre-built components with their structure but strip all styles
-3. **Headless** - Use only hooks and build the entire UI yourself
+1. **Pre-built components** - Use provider options, component props, tokens, slots, and `theme.consentActions`
+2. **Compound components** - Rearrange c15t primitives when the markup order must change
+3. **`noStyle`** - Keep c15t structure but replace its styling
+4. **Headless** - Use only hooks and build the entire UI yourself
 
 ## When to Go Headless
 
@@ -18,10 +19,15 @@ Go headless when:
 * You need a consent flow that doesn't fit the banner/dialog pattern
 * You want to embed consent choices inline rather than as overlays
 
-Use `noStyle` instead when:
+Use a lower-power tool instead when:
 
-* The component structure works but the styling doesn't
-* You want to apply your own CSS/Tailwind without fighting defaults
+* The component structure works but the styling doesn't -> use tokens, slots, or `noStyle`
+* You only need to rearrange existing c15t parts -> use compound components
+* You want to change copy -> use `ConsentManagerProvider.options.i18n`
+* You only need to restyle stock actions -> use `theme.consentActions`
+
+> ⚠️ **Warning:**
+> Headless mode is not the first answer for pure theming. If you are still trying to debug why a banner footer color did not change, stay in the styling system and verify the token-to-component mapping before you rebuild the UI.
 
 > ℹ️ **Info:**
 > Need a policy-aware implementation guide? See Building Headless Components.

package/docs/hooks/use-consent-manager/overview.md

@@ -27,7 +27,7 @@ function MyComponent() {
 
 |Property|Type|Description|Default|Required|
 |:--|:--|:--|:--|:--:|
-|branding|"c15t" \|"consent" \|"none"|Whether to show the branding|-|✅ Required|
+|branding|"c15t" \|"inth" \|"consent" \|"none"|Whether to show the branding. "consent" is a deprecated alias for "inth".|-|✅ Required|
 |consents|ConsentState|Current consent states for all consent types|-|✅ Required|
 |selectedConsents|ConsentState|Selected consents (Not Saved) - use saveConsents to save|-|✅ Required|
 |consentInfo|ConsentInfo \|null|Information about when and how consent was given|-|✅ Required|
@@ -53,7 +53,7 @@ function MyComponent() {
 |iab|IABManager \|null|IAB TCF 2.3 state and actions (null when not configured or not in IAB mode).|-|✅ Required|
 |reloadOnConsentRevoked|boolean|Whether to reload the page when consent is revoked.|-|✅ Required|
 |ssrDataUsed|boolean|Whether SSR data was successfully used for initialization.|-|✅ Required|
-|ssrSkippedReason|"no\_data" \|"fetch\_failed" \|null|Reason SSR data was skipped, if applicable.|-|✅ Required|
+|ssrSkippedReason|SSRSkippedReason|Reason SSR data was skipped, if applicable.|-|✅ Required|
 
 #### `consents` ConsentState
 
@@ -87,7 +87,7 @@ Information about when and how consent was given
 |:--|:--|:--|:--|:--:|
 |time|number|The epoch timestamp of when the consent was recorded|-|✅ Required|
 |subjectId|string \|undefined|The client-generated subject ID in sub\_xxx format|-|Optional|
-|id|string \|undefined|-|-|Optional|
+|id|string \|undefined|Configuration for the legal links @remarks Legal links can display across different parts of the consent manager such as the consent banner & dialog.|-|Optional|
 |externalId|string \|undefined|The external user ID linked to this subject|-|Optional|
 |materialPolicyFingerprint|string \|undefined|Material fingerprint of the active policy when this consent was accepted.|-|Optional|
 |identityProvider|string \|undefined|The identity provider that provided the external ID|-|Optional|
@@ -196,6 +196,7 @@ IAB TCF 2.3 state and actions (null when not configured or not in IAB mode).
 |setActiveUI|(ui: ActiveUI, options?: \{ force?: boolean \|undefined; } \|undefined) => void|Sets the active consent UI component.|-|✅ Required|
 |setConsentCategories|(types: AllConsentNames\[]) => void|Updates the active GDPR consent types.|-|✅ Required|
 |setCallback|Object \|undefined|Sets a callback for a specific consent event.|-|✅ Required|
+|subscribeToConsentChanges|Object|Subscribes to change-only consent saves.|-|✅ Required|
 |setLocationInfo|Object \|null|Updates the user's location information.|-|✅ Required|
 |initConsentManager|Object \|undefined \|null|Initializes the consent manager by fetching jurisdiction, location, translations, and branding information.|-|✅ Required|
 |getDisplayedConsents|ConsentType|Retrieves the list of consent types that should be displayed|-|✅ Required|
@@ -245,6 +246,19 @@ Identifies the user by setting the external ID.
 |id|string|Usually your own internal ID for the user from your auth provider|-|✅ Required|
 |identityProvider|string \|undefined|The identity provider of the user. Usually the name of the identity provider e.g. 'clerk', 'auth0', 'custom', etc.|-|Optional|
 
+#### `subscribeToConsentChanges`
+
+Subscribes to change-only consent saves.
+
+|Property|Type|Description|Default|Required|
+|:--|:--|:--|:--|:--:|
+|preferences|ConsentState|-|-|✅ Required|
+|previousPreferences|ConsentState|-|-|✅ Required|
+|allowedCategories|AllConsentNames|-|-|✅ Required|
+|deniedCategories|AllConsentNames|-|-|✅ Required|
+|previousAllowedCategories|AllConsentNames|-|-|✅ Required|
+|previousDeniedCategories|AllConsentNames|-|-|✅ Required|
+
 #### `setLocationInfo`
 
 Updates the user's location information.

package/docs/hooks/use-ssr-status.md

@@ -25,7 +25,7 @@ function DebugSSR() {
 |Property|Type|Description|Default|Required|
 |:--|:--|:--|:--|:--:|
 |ssrDataUsed|boolean|Whether SSR data was used for initialization. \`true\` if SSR data was provided and successfully consumed, \`false\` otherwise.|-|✅ Required|
-|ssrSkippedReason|"no\_data" \|"fetch\_failed" \|null|Reason SSR data was skipped, or \`null\` if used successfully.|-|✅ Required|
+|ssrSkippedReason|"no\_data" \|"fetch\_failed" \|"context\_mismatch" \|null|Reason SSR data was skipped, or \`null\` if used successfully.|-|✅ Required|
 
 > ℹ️ **Info:**
 > Must be used within a ConsentManagerProvider. Throws if used outside the provider context.

package/docs/hooks/use-translations.md

@@ -46,6 +46,7 @@ The returned `Translations` object has these sections:
 |customize|string \|undefined|-|-|✅ Required|
 |save|string \|undefined|-|-|✅ Required|
 |close|string \|undefined|-|-|✅ Required|
+|securedBy|string \|undefined|-|-|✅ Required|
 
 #### `cookieBanner` CookieBannerTranslations
 

package/docs/iab/consent-banner.md

@@ -19,11 +19,8 @@ Use this component instead of `ConsentBanner` when you need IAB TCF compliance f
 
 ```tsx
 import { type ReactNode } from 'react';
-import {
-  ConsentManagerProvider,
-  IABConsentBanner,
-  IABConsentDialog,
-} from '@c15t/nextjs';
+import { ConsentManagerProvider } from '@c15t/nextjs';
+import { IABConsentBanner, IABConsentDialog } from '@c15t/react/iab';
 
 export default function ConsentManager({ children }: { children: ReactNode }) {
   return (

package/docs/iab/consent-dialog.md

@@ -13,11 +13,8 @@ Pair it with `IABConsentBanner` inside the provider:
 
 ```tsx
 import { type ReactNode } from 'react';
-import {
-  ConsentManagerProvider,
-  IABConsentBanner,
-  IABConsentDialog,
-} from '@c15t/nextjs';
+import { ConsentManagerProvider } from '@c15t/nextjs';
+import { IABConsentBanner, IABConsentDialog } from '@c15t/react/iab';
 
 export default function ConsentManager({ children }: { children: ReactNode }) {
   return (
@@ -76,7 +73,7 @@ By default, the dialog follows `activeUI === 'dialog'` from the consent store. U
 
 ```tsx
 import { useState } from 'react';
-import { IABConsentDialog } from '@c15t/nextjs';
+import { IABConsentDialog } from '@c15t/react/iab';
 
 function SettingsPage() {
   const [open, setOpen] = useState(false);

package/docs/iab/overview.md

@@ -32,15 +32,21 @@ c15t provides a complete IAB TCF 2.3 CMP (Consent Management Platform) implement
 4. **TC String generation** — Consent choices are encoded into the standard TC String format.
 5. **`__tcfapi` stub** — The standard CMP API is exposed on `window` so vendor scripts can query consent.
 
+If you use the prebuilt styled IAB UI, add your framework's `iab/styles.css` entrypoint alongside the base c15t stylesheet. IAB CSS is published separately so apps that do not render IAB surfaces do not ship those component rules.
+
 ## Quick Setup
 
+If you use the prebuilt styled IAB UI, import the IAB stylesheet alongside the base stylesheet in your global CSS entrypoint:
+
+```css title="src/app/globals.css"
+@import "@c15t/nextjs/styles.css";
+@import "@c15t/nextjs/iab/styles.css";
+```
+
 ```tsx
 import { type ReactNode } from 'react';
-import {
-  ConsentManagerProvider,
-  IABConsentBanner,
-  IABConsentDialog,
-} from '@c15t/nextjs';
+import { ConsentManagerProvider } from '@c15t/nextjs';
+import { IABConsentBanner, IABConsentDialog } from '@c15t/react/iab';
 
 export default function ConsentManager({ children }: { children: ReactNode }) {
   return (