Integrations

Third-party tools are easy to paste into app code, but consent makes them part of your privacy runtime. Analytics SDKs, ad pixels, tag managers, and chat widgets can load remote code, store identifiers, send events, and keep running after the first page view.

Why Manage Tools In c15t

When you install a vendor directly in your app, your consent logic has to chase that vendor everywhere it appears: page layouts, route handlers, event helpers, tag-manager snippets, and cleanup code.

Register the vendor with c15t instead. The integration becomes a declarative Script that the consent runtime can reason about:

• c15t registers the tool with the runtime and evaluates it against the current consent state;
• c15t automatically adds the tool's consent category to the active categories, so GDPR-style consent UIs include measurement, marketing, or functionality when an enabled integration needs them;
• c15t blocks the script until consent is granted, or loads it with denied defaults when the vendor has its own consent mode;
• c15t handles revocation by unloading the script or calling the vendor's consent API;
• c15t runs vendor setup in the right order, including queue stubs, global functions, data attributes, default page-view events, and consent updates.

That gives your app one consent lifecycle instead of many scattered vendor lifecycles.

Built-In Helpers

c15t ships prebuilt helpers in @c15t/scripts for the third-party tools developers integrate most often. Prefer them over copied vendor snippets whenever c15t already supports the vendor.

Every helper returns a regular Script object, so it works anywhere the c15t script loader accepts scripts. You usually choose the helper, provide the vendor ID, and pass the result to your provider's scripts option. The vendor page explains anything else that still matters, such as custom events, region settings, privacy modes, or ecommerce payloads.

Choose An Integration Style

Most apps mix more than one style. Pick the smallest one that keeps consent behavior obvious.

Setup is the same shape in every framework: import the helper, call it with vendor options, and pass the result to the consent runtime through your provider's scripts option. See the framework guides for end-to-end snippets — JavaScript, React, Next.js.

Analytics

Analytics integrations usually require measurement consent. Some vendors can run in a consent-aware or cookieless mode; others should stay fully blocked until measurement consent is granted.

Functional

Functional integrations usually require functionality consent. They add optional user-facing capabilities, such as chat widgets, that should only run after the user allows them.

Ads & Pixels

Advertising pixels usually require marketing consent. Many of them need startup stubs so events can be queued safely before the remote SDK loads — built-in helpers handle this for you.

Tag Managers

Tag managers can load other scripts, so they deserve extra care. Prefer vendor consent modes and denied defaults before any tags are allowed to run.

Build Your Own

If c15t does not ship the vendor you need, drop down a level:

• build a one-off Script directly in your app for simple cases,
• build a reusable manifest-backed helper for shared or package-level integrations,
• or combine the script loader with iframe gating for visible media and widget integrations.

Build a Custom Integration

Learn when to use a raw Script, when to use a manifest, and how to debug and test custom integrations.

Read the guide →

Where To Next

• Read the script loader guide for your framework: JavaScript, React, Next.js.
• See the iframe blocking pattern for visible embeds (YouTube, maps, calendars).
• Use has() to conditionally run app code based on consent state.