What Tripticonsent is
One API for capturing consent and preferences, proving them later, and honouring them in your product.
Tripticonsent is a hosted service for consent, preferences and cookies. Every product that collects a “yes, you may email me” or a “no tracking” has to capture it, store the exact wording that was shown, let people change their mind, prove it to a regulator, and expire it when it gets stale. That’s the same problem every time — so you do it once, here, through one API.
You get: a tamper-evident history (the vault) that’s never edited, a signed receipt for every decision that anyone can verify, versioned legal text, per-country banner rules, and webhooks when anything changes. Data stays in the EU.
How the pieces fit
- Organization — your company. Has members with roles (owner, admin, editor, viewer, and DPO for data-subject requests).
- Site — one product or brand. Holds its own domains, API keys, purposes, preference centre, banner rules and webhooks. Most companies have one; add more to keep brands separate.
- Purpose — one thing a person decides about (
marketing_email,analytics). Its wording is versioned. - Subject — one person, referenced by an identifier you already have (
email:…,cookie_id:…). - Vault — the append-only record of every decision, per site, per environment.
Two ways in
Your team uses the console — sign in with Google, configure purposes, search the vault, review requests. Your code uses API keys against /v1/*: a pk_ key in the browser (locked to your domains, can only read definitions and write consent), a sk_ key on your server (full access).
pk_test_…, sk_live_…). The two never see each other’s data, so you can develop against test with real-looking traffic and switch to live by swapping the key.Where your data lives
Everything runs in the EU (Frankfurt). Personal data in identifiers is encrypted at rest; we can still find a subject by a one-way hash without decrypting, and an erasure request throws away the key so the person can no longer be found.