Security & privacy

How CRISP handles tokens, data boundaries, encryption, retention, and deletion.

CRISP Content Engine is designed to be safe-by-default: minimize sensitive data exposure, encrypt tokens, and keep publishing deterministic.

Who this page is for

CRISP uses multiple systems with clear responsibilities:

Airtable: content records and editorial fields (human-visible)
Supabase (Postgres): connections, encrypted tokens, publishing jobs, job state
Make.com: content generation workflow engine (webhook-driven)
Cloudinary: image hosting and transformation

Platform access tokens are stored server-side.
Tokens are encrypted at rest when stored (example: Meta uses META_TOKEN_ENCRYPTION_KEY).
Tokens and platform IDs are not written to Airtable (especially Meta).

Publishing source of truth

When publishing, CRISP uses the stored job payload (e.g. publish_jobs.payload_json) rather than re-reading Airtable at publish time.

Airtable supports the editorial workflow (drafts, approval, metadata).
Supabase is the operational system for:
- Connection state
- Destination selection
- Publish job queue + retries + immutable publish payloads

Disconnecting a platform removes connection records and invalidates future jobs.
Meta requires a dedicated data deletion callback endpoint; CRISP implements this as part of the Meta integration.

Common third parties used by CRISP include: