Overview

An adapter connects to one consent platform and reports what it says in libconsent's vocabulary. It is the only place a platform's name appears — swap it and every useConsent(), <CookieService> and openSettings() keeps working.

<ConsentProvider adapter={usercentrics({ settingsId: "AbCdEf123" })}>

Standards

Two of the adapters aren't vendors at all. They speak the interfaces a whole class of CMPs is required to implement, so one package covers a long tail of platforms with no adapter of their own:

Neither loads a script: they read whichever CMP is already on the page. Reach for a vendor adapter first when one exists — it can open dialogs and report per-service consent, which the standards alone cannot.

What each one can do

Platforms differ in how much they let you control. useConsent().supports reports this at runtime:

"Per-service (read)" means the platform reports consent for individual services, so <CookieService id="hotjar"> gets a precise answer; you just can't set it from your own UI. setConsent is what the banner and useConsentForm() need — libconsent's own adapter, Klaro and Cookiebot have it.

The two standards have no actions at all, because TCF and GPP describe consent without saying how to ask for it. Both take a commands option so you can pass your CMP's own calls through.

Calling something a platform can't do warns in development and does nothing in production. Check supports before offering it:

const { supports, reset } = useConsent();
{
  supports.reset && <button onClick={reset}>Withdraw consent</button>;
}

Options every adapter takes

Not listed here?

Write your own — load a script, subscribe to an event, report what the platform says. The built-in ones are 100–200 lines each.

Before you do, check whether your CMP is TCF-registered: if it is, tcf() already works with it today.