SocialHub.AI

Loyalty & Members · Compliance & Consent

A privacy statement you can defend — and a consent record you can prove.

Generate a versioned member privacy / compliance statement: AI fills plain-language wording into a fixed, pre-reviewed legal skeleton, a human approves it, and every member's consent binds to the exact version. Then read the statement and verify consent across your whole stack over a governed API.

The problem

A privacy page is easy. Proving who agreed to which version is not.

A static page, frozen in time

A privacy page in your footer can't tell you which members agreed to it — or to which wording, on which date.

Consent you can't evidence

When a member or a regulator asks "what did I agree to?", a single opt-in flag isn't an answer. You need the version and the proof.

Locked inside one tool

Your storefront, app and back office each need the current statement and a way to check consent — but it lives in one admin screen.

How it works

AI drafts it. A human approves it. Every consent binds to the version.

01

AI drafts into a fixed skeleton

The platform owns a pre-reviewed section skeleton and a statute whitelist. You supply the facts; the AI fills only plain-language wording — it can't invent facts or cite a statute that isn't on the list.

02

A human reviews and approves

An owner or admin reviews the draft, resolves anything marked "must confirm", and accepts a shared-liability disclaimer. Nothing publishes until those gates pass.

03

Publish a version

Each publish freezes the content, hashes it, and assigns the next version number. Exactly one version is live per team at a time.

04

Consent binds to the version

When a member consents, the record is pinned to that exact version and content hash. A material change forces re-consent; a minor one shows a banner.

Honest about what AI does: it fills wording into a fixed, pre-reviewed skeleton — it never invents facts or cites a statute outside the approved list, and if generation fails it falls back to the plain skeleton, never a made-up policy. It is a drafting aid, not legal advice; your counsel reviews before you publish. Today: English, from a CCPA + CASL baseline.

Now over an API

Read the statement and verify consent — anywhere in your stack.

A governed REST API exposes the published statement and per-member consent to any authorized system — your storefront, app, data warehouse or back office — with scoped, audited API keys.

GET/v2/privacy/currentThe current published statement (sanitized).
GET/v2/privacy/policiesVersion history (published & archived; never drafts).
GET/v2/privacy/policies/{id}A specific version with full content.
GET/v2/members/{id}/consentsA member's consent records — version, scopes, status, time.

Drafts never leak

The API serves only published / archived versions, sanitized — internal review markers and unfinished drafts never leave.

Scoped & audited keys

Read access is granted with narrow scopes (privacy:read, consent:read) on per-key API tokens, tenant-isolated and rate-limited.

Evidence, minus the PII

Consent records return the version, scopes, status and timestamp a partner needs to verify — without the raw IP or device string.

Full reference and examples — Compliance & Consent API →

Built for trust

Evidence that holds up.

Append-only evidence

Consent records are append-only and survive a member's deletion — the proof of what they agreed to doesn't vanish with the account.

Bound to the exact wording

Each consent stores the version number and a hash of the content — so "v3" always means the same words, even after newer versions publish.

Two tracks, never conflated

Agreeing to the privacy statement is separate from opting in to marketing — withdrawing one never silently changes the other.

Every consent bound to the exact version you published.

Generate a defensible statement — and prove consent over an API.

400M+
50+
12+