Build consent capture, withdrawal and rights requests straight into your own stack. Our OpenAPI spec documents 494 paths and 675 operations — a subset of the 886 distinct paths the gateway actually registers; every documented path is checked against that route table before a number on this page can change. Read it before you talk to us. Build your own consent UI, or drop in ours; the backend doesn’t care.
API BASE: https://app.consentree.in/api/v1 · CONSOLE: app.consentree.in · SENTIN-AI: sentinai.consentree.in
import { createClient } from '@consentree/js'; const cs = createClient({ apiKey: 'pk_live_…' }); // render the banner — notice version & language resolved server-side cs.banner.mount('#consent-root', { language: 'auto' }); // gate a purpose anywhere in your app if (await cs.consent.has('analytics')) { initAnalytics(); }
All four share the same key model, webhook signature verification, and consent semantics — learn one, know them all.
Framework-free banner, preference center and purpose checks for any site. Offline queueing with sync-on-reconnect.
v1.1.0 · vanilla JS/TSHooks and components — useConsent(), <ConsentGate/> — that make purpose-gating declarative.
Server-side consent checks, DSR submission, and signed-webhook verification middleware for Express & friends.
v1.1.0 · Node 18+Drop-in data-subject request intake — submission, status polling and verification handoff — for embedding rights flows in your own portal.
v1.1.0 · TypeScript
How you get them, stated plainly: these are built from our monorepo and provided
directly to design partners and integration clients. They are not yet published to a public
package registry, so npm install will not
find them today — ask us and we will send you the tarball and the integration guide. Native
Java, Android and Flutter SDKs exist in our repo — real clients, not stubs — but are not yet
released to design partners or a package registry, and are not covered by the stability
guarantees above.
The event-hub delivers signed webhooks for every lifecycle event — grants, withdrawals, expiries, erasure completions — with delivery logs you can actually inspect when something goes wrong. Need push instead of pull? There’s a live SSE stream too.
import { verifyWebhook } from '@consentree/node'; app.post('/hooks/consent', (req, res) => { const evt = verifyWebhook(req, process.env.CS_WEBHOOK_SECRET); switch (evt.type) { case 'consent.withdrawn': // stop processing — the platform already logged the proof await crm.suppress(evt.data_principal); break; case 'dsr.erasure.completed': await notifyPrivacyTeam(evt); } res.sendStatus(200); });
Client-side purpose gating is a UI nicety, not a control — anyone can open devtools and flip it. Every consent check the SDKs call resolves against the gateway itself, so a denied purpose is a hard stop no client code can bypass, and the denial is itself an audited event.
// Purpose-limitation is enforced in the backend, // not left to the UI’s good manners. decision := engine.Resolve(ctx, ResolveReq{ Principal: "dp_7f3a…", Purpose: "marketing.email", }) if !decision.Granted { // hard stop — and the denial is itself audited return ErrPurposeNotConsented }
Per-key domain allowlists (exact-match, no prefix tricks), scoped permissions, and rotation without downtime.
Shipped: per-key allowed_domains, exact-match enforcementA dedicated staging environment for DPDP workflows — plus Playwright and Go testcontainers to mock consent flows in your own CI.
Shipped: sandbox tenants · E2E test containers