Security, plainly described
Galleries put their inventory, collectors, and money flows in here — so this page describes the actual controls, in plain language. We don’t claim certifications we don’t hold; we describe what the system really does.
- Access is enforced at the database row
- Every table carries row-level security policies: a member sees their gallery's rows because the database refuses everything else, not because application code remembered to filter. Public viewing-room access goes through dedicated, narrowly-scoped functions.
- Encryption in transit and at rest
- All traffic is TLS; data at rest is encrypted by our infrastructure providers (Supabase/PostgreSQL, Vercel). External channel credentials we store are additionally encrypted at the application layer.
- Scoped API keys & signed webhooks
- API keys carry granular scopes and live/test modes; every key action is rate-limited. Outbound webhooks are signed so your systems can verify each delivery; inbound provider webhooks are signature-verified with replay windows before anything is trusted.
- AI with guardrails
- The assistant acts only with your permissions, destructive actions require explicit confirmation, and gallery data is never shared between galleries. Model API calls are not used to train models.
- Your data leaves cleanly
- Self-serve, GDPR-grade export of your full account data, and erasure flows for both your account and your gallery's contacts. Stable IDs make the export round-trippable — portability is a feature, not a support ticket.
- Roles, SSO, and audit
- Role-based permissions per gallery; SSO and advanced roles on Enterprise. Platform events form an append-only audit trail, and error reporting runs through a PII scrub before anything leaves the system.
Questions we didn’t answer here? Ask us directly — or read the data & privacy FAQ and the privacy policy.