The consent ledger API

Consentry records every consent decision in an append-only ledger, answers "is this use of personal data permitted?" at request time, and produces a regulator-grade evidence trail on demand. Decide once. Prove anywhere.

Legal defines the purposes. Engineering starts with three calls: record, check, evidence. The ledger is the audit trail.

# 1 - record the decision
curl -X POST https://api.consentry.io/v1/decisions \
  -H "Authorization: Bearer $CONSENTRY_KEY" \
  -d '{ "subject": "usr_8492", "purpose": "marketing", "status": "granted" }'

# 2 - check before you use the data
curl -X POST https://api.consentry.io/v1/checks \
  -d '{ "subject": "usr_8492", "purpose": "marketing" }'
#    → { "decision": "allow", "evidence": "evd_01J8ZK…" }

# 3 - prove it, whenever anyone asks
curl https://api.consentry.io/v1/evidence?subject=usr_8492

Quickstart

From zero to a provable consent record in under ten minutes.

1. 1

   Get an API key

   Design partners receive keys directly. Write to support@consentry.in. Keys are scoped per environment: sk_test_ keys never write to your production ledger.

2. 2

   Install the SDK

   Terminalcopy

   npm install @consentry/node   # or: pip install consentry

3. 3

   Record a decision

   Call this wherever consent is captured today: your signup flow, cookie banner, preference center, or sales-signed DPA. The source doesn't matter; the ledger unifies them.

   record.tscopy

   import Consentry from "@consentry/node";
   const consentry = new Consentry(process.env.CONSENTRY_KEY);
   
   await consentry.decisions.record({
     subject: "usr_8492",          // your user ID - we never need PII
     purpose: "marketing",
     status:  "granted",
     basis:   "consent",           // consent basis under your notice
     source:  "signup_form_v3",
   });

4. 4

   Check, then prove

   Gate any data use with check(). Every call is itself logged, so your evidence trail shows not just what was consented, but that it was enforced.

   enforce.tscopy

   const { decision } = await consentry.check({
     subject: "usr_8492",
     purpose: "marketing",
   });
   
   if (decision === "allow") sendCampaignEmail(user);

   When an auditor, regulator, or enterprise customer asks for proof, one call returns the complete, tamper-evident history:

   evidence · usr_8492sha256 verified · exported 2026-07-23

   • Marketing●Granted2026-07-19 14:02:11Z · signup_form_v3
   • Analytics●Revoked2026-07-21 09:47:03Z · preference_center
   • Processor sharing●Pendingawaiting decision · dpa_2026_04
   • Enforcement check●Logged2026-07-22 18:30:44Z · checks · allow

Core concepts

Four objects. Everything in the API is one of these.

Identity & binding

The ledger references subjects by your opaque IDs. Consentry never stores PII. That raises a fair question: what stops the mapping between usr_8492 and a real person from changing after the fact?

Identity commitments.

When recording a decision, optionally include a commitment: an HMAC-SHA256 of a stable identifier (typically the email address), keyed with a secret only you hold. The commitment is fixed into the hash chain at write time. Consentry still sees no PII, but at audit time, revealing the identifier and key lets anyone recompute the hash and verify the binding existed when the decision was recorded. Remapping an ID later changes nothing that matters: the commitment already sealed who the decision was about.

import { createHmac } from "crypto";

const commitment = createHmac("sha256", process.env.BINDING_KEY)
  .update("priya@example.com")      // stays on your side, always
  .digest("hex");

Identity events are ledger entries.

Real systems remap IDs for legitimate reasons: account merges, migrations, re-registrations. Record a merge with subject.merged so the identity lineage sits in the same tamper-evident history as the decisions. When you alias or migrate IDs, record those lineage changes as ledger entries too. Nothing about a subject (decisions or identity) changes without leaving a record.

Authentication

All requests use Bearer authentication over HTTPS. Test and live environments are fully separated.

Authorization: Bearer sk_live_c0ns3ntry…

Endpoints

{
  "id": "dec_01J8ZKQ4T…",
  "subject": "usr_8492",
  "purpose": "marketing",
  "status": "granted",
  "basis": "consent",
  "ledger_index": 1482231,
  "recorded_at": "2026-07-19T14:02:11Z",   // sealed by the chain
  "receipt": {                              // keep this - it's your independent proof
    "chain_hash": "9f2c41ab…",
    "signature": "MEUCIQDx…"
  }
}

{
  "id": "dec_01J8ZKQ4T…",
  "subject": "usr_8492",
  "purpose": "marketing",
  "status": "granted",
  "basis": "consent",
  "ledger_index": 1482231,
  "recorded_at": "2026-07-19T14:02:11Z",
  "superseded_by": null
}

{
  "subject": "usr_8492",
  "purposes": {
    "marketing": "granted",
    "analytics": "revoked",
    "processor_sharing": "pending"
  },
  "as_of_ledger_index": 1482310
}

{
  "decision": "allow",        // or "deny" · "review"
  "reason": "granted:consent",
  "valid_for": 86400,          // seconds - allow answers expire
  "evidence": "evd_01J8ZK…"    // this check's own audit reference
}

Trust & verification

A proof layer has to answer one more question: why should anyone trust the proof layer? The design assumes they shouldn't have to.

Webhooks

Push consent changes to the systems that must obey them (CRM suppression lists, CDP audiences, ad platform exclusions) instead of polling.

Errors

Errors are precise about what happened and how to fix it. Consent infrastructure that fails vaguely is a liability.