Quickstart — ConsentProof Docs

From nothing to a publicly verifiable consent receipt. Two routes — the dashboard route needs no terminal at all.

Route A — dashboard only (10 minutes, no code)

Create your organization — company name, email, password.
The setup guide walks four steps: pick your industry (seeds bilingual purposes with sensible legal bases), review and activate your policy (activation hash-locks the exact wording — every consent will reference that hash), generate keys, and record a first consent whose receipt you open on the public verify page. That last step is the whole product in one click.
Copy the widget snippet from step 3 into your site, and add your site's origin under API keys → Widget origins — the widget is blocked everywhere until you do.

Route B — API

1 · Keys

Two kinds, different trust levels:

Key	Prefix	Where it lives	What it can do
Secret	cp_live_	your server only	everything its scopes allow
Publishable	cp_pk_	the browser, safely	widget config + recording consent from the banner — nothing else

Secret-key scopes: consents:read, consents:write, dsar:read, dsar:write, admin, subjects:token. Grant the minimum; keys are shown once and revoked from the dashboard.

2 · Prerequisites — purpose + active policy

A consent can only be recorded against an existing purpose and an ACTIVE policy version (drafts don't count). Both languages are mandatory — that is PDPL's language rule, enforced at the API:

H="Authorization: Bearer cp_live_…"
B="https://your-host/v1"

curl -X POST -H "$H" -H 'Content-Type: application/json' "$B/purposes/" \
  -d '{"code":"marketing_sms","name":"SMS Marketing","name_ar":"التسويق عبر الرسائل","legal_basis":"consent"}'

curl -X POST -H "$H" -H 'Content-Type: application/json' "$B/policies/privacy/versions/" \
  -d '{"content":"We will send you SMS offers…","content_ar":"سنرسل لك عروضاً عبر الرسائل…"}'

curl -X POST -H "$H" "$B/policies/privacy/versions/1/activate/"

3 · Record consent

curl -X POST -H "$H" -H 'Content-Type: application/json' "$B/consents/" -d '{
  "subject":  {"phone": "+966501234567"},
  "purpose":  "marketing_sms",
  "policy":   "privacy",
  "action":   "granted",
  "method":   "checkbox",
  "source":   "signup_form",
  "language": "ar"
}'
# → {"record_id": "…", "receipt_id": "rcp_…", "status": "active", "verify_url": "…"}

The receipt_id is the evidence. Store it on your side. Anyone can open /verify/rcp_…/ and check it — no account.

4 · Check before you send

curl -H "$H" "$B/consents/check/?purpose=marketing_sms&phone=%2B966501234567"
# → {"purpose": "marketing_sms", "status": "active", …}

Rule of thumb: record at the moment of choice, check at the moment of use. If you also defined preferences, read them in the same place you check.

What "production" needs

Add every site origin that embeds the widget (API keys → Widget origins) — CORS is a per-organization allowlist, not a wildcard.
Wire webhooks if your systems must react to withdrawals in real time.
Working through an AI coding agent? The AI integration page gets it done in one prompt.