ConsentProvider

Mount the provider

Render ConsentProvider once, around your whole app, in the component you pass to mount():

<script lang="ts">
	import { posthog } from '@c15t/integrations/posthog';
	import {
		ConsentBanner,
		ConsentDialog,
		ConsentDialogLink,
		ConsentProvider,
		manifest,
	} from '@c15t/svelte';

	const scripts = [
		posthog({
			id: 'phc_your_project_key',
			initOptions: { cookieless_mode: 'never' },
			loadMode: 'after-consent',
		}),
	];
</script>

<ConsentProvider mode={manifest()} {scripts}>
	<main>
		<h1>c15t + Svelte</h1>
		<p>Your app goes here.</p>
	</main>
	<footer>
		<ConsentDialogLink>Privacy settings</ConsentDialogLink>
	</footer>
	<ConsentBanner />
	<ConsentDialog />
</ConsentProvider>

mode is the only required prop. Here manifest() resolves the policy from the snapshot the build bundled and saves choices to your Inth project, as set up in the quickstart. manifest({ source: 'runtime' }) fetches the manifest when the page loads instead, and hosted() asks the backend's /init. Both read the backend URL from consentManifest, or take backendURL. Import every mode from @c15t/svelte. The consent components render inside the provider; your app's own components can sit anywhere inside it too, so they can call the context getters.

In a Svelte app without SvelteKit the browser resolves the policy after the page loads, so the banner appears after the first paint. Optional categories stay denied until then.

Props

Pass each option as a top-level prop, or group them in options. When both set the same option, the top-level prop wins. The ConsentManagerOptions type from @c15t/svelte lists every option. SvelteKit's ConsentRoot takes the same props, except that state replaces mode and prefetch.

"Read once" options are read when the provider is created. Changing them later has no effect until the provider remounts, and outside production a change to mode, i18n or experiment logs a warning. Options that update after mount are compared with their previous values, so a new options object that only changes theme sends no request. The provider has no policyRules option. For local policy rules, pass offline({ policyRules }) as mode.

What the provider does when it mounts

The provider creates the consent runtime while the component initializes, on the server and in the browser. Creating it has no side effects, so the server can render the banner from prefetch. In the browser, onMount starts the runtime:

1. It reads the stored choice from the cookie and local storage.
2. It starts the script loader, the iframe blocker and, if configured, the network blocker and the IAB TCF add-on.
3. It resolves the policy with its mode, unless prefetch already holds one.

When the provider unmounts, it stops all of them. Keep one provider at the root of the app, so it stays mounted across navigation and every component can reach it.

With networkBlocker, matching requests are held from the moment the provider is created in the browser, before its children run their own code, until the blocker decides them.

Share one runtime

Pass runtime when two component trees that cannot share Svelte context need the same consent state. Create it with createConsentRuntime() from @c15t/svelte, pass it to each provider, and call runtime.start() and runtime.dispose() yourself. A provider never starts or disposes a runtime it did not create. Options that build the runtime, such as mode, scripts and callbacks, come from your createConsentRuntime() call; display options such as theme and noStyle still apply per provider.

Verify the provider

Open the page in a private window with DevTools open:

1. The banner appears once the policy resolves. window.c15t in the console shows pkg: '@c15t/svelte'.
2. The Network panel shows the request your mode makes: none for manifest() with a bundled snapshot, one /init for hosted(), and none when the page came with a server-resolved state.
3. A component that calls getConsentManager() renders without the c15t: no v3 consent context error.