Spinative
Trust & SecurityPrivacyTermsCookiesLegal notice

Trust & Security

A single-page reference for studio CTOs and security teams evaluating Spinative. Covers where data lives, who can access it, how it's protected, and what to expect from us during an incident. Last updated: 2026-05-16. Material changes are versioned in our public GitHub repo and announced via in-app notification + email to the workspace owner.

TL;DR

  • Data residency: project data is stored in the EU (Supabase region eu-north-1 / Stockholm). One region today; SOC2-driven multi-region splits are on the roadmap.
  • Encryption: TLS 1.2+ in transit; AES-256 at rest (Supabase default + Vercel managed). Backups inherit the same encryption.
  • Multi-tenancy isolation: every read/write goes through a server-side authorization gate (assertProjectAccess / assertWorkspaceAccessBySlug). Row-Level Security is enabled on every table; anon + authenticated DB roles have been explicitly revoked.
  • No AI training on your data: we use OpenAI's API with the standard "no training" terms. Prompts and outputs aren't fed back into model training.
  • Right to deletion + export: workspace owners can export every project as a single payload and request full deletion via support — fulfilled within 30 days.
  • Security contact: security@spinative.com. Responsible disclosure welcomed.

Where your data lives

CategoryStorageRegion
Project payloads, snapshots, audit logSupabase PostgresEU — eu-north-1 (Stockholm)
Uploaded + AI-generated imagesSupabase StorageEU — eu-north-1
Marketing renders, exportsSupabase Storage (private buckets)EU — eu-north-1
Authentication identitiesClerk CloudGlobal (Clerk's own infra)
Subscriptions, paymentsStripeGlobal (Stripe's own infra)
Function execution + edge CDNVercelGlobal (closest edge)
Error telemetry (optional)Sentry (planned)Configurable (EU/US)

Vercel serverless functions are stateless — they hold no persistent data. The only stateful systems are Supabase, Clerk, and Stripe.

We will accept reasonable data-residency requests from enterprise customers (e.g., a US-only deployment) by spinning up a dedicated environment. Pricing on request.


Encryption

ChannelStandard
Browser ↔ SpinativeTLS 1.2+, HSTS preload enabled, 1-year HSTS max-age
Spinative ↔ SupabaseTLS 1.2+
Spinative ↔ Clerk / Stripe / OpenAITLS 1.2+
Postgres data at restAES-256 (Supabase default)
Storage objects at restAES-256 (Supabase default)
BackupsAES-256 (Supabase default)

API keys, webhook secrets, and database credentials live in Vercel environment variables and are never persisted to the database or logged to client/server console.


Access controls

Application layer

  • Server-side gates: every server action and API route runs assertProjectAccess(userId, projectId) or assertWorkspaceAccessBySlug(userId, slug, requiredRole) before touching data. The check resolves the user's role in the studio (owner / admin / finance / member) and returns 404 on missing access — never leaks the project's existence to a non-member.
  • Public preview routes (/p/<projectId>?token=...): scoped by a 256-bit random share token (24 bytes, base64url). Tokens carry only a role field (reviewer or public_view); they don't grant write access to project content beyond comments (and only for the reviewer role). Token TTL defaults to 30 days, capped at 365.
  • Webhook signature verification: Clerk uses svix signatures; Stripe uses its native HMAC signature. Webhooks reject requests without a valid signature.

Database layer

  • Row-Level Security is enabled on every table in the public schema. The anon and authenticated Postgres roles have been explicitly revoked from all tables, sequences, and functions in public. An event trigger (rls_auto_enable) auto-enables RLS on any future table to prevent regressions.
  • Application access uses the service role (server-side only). The service role bypasses RLS by design — the application-layer gates above are the authorization boundary. Service-role credentials are never exposed to the client.

Editor iframe

  • The editor loads in an iframe under the same origin (spinative.com/editor/spinative.html).
  • X-Frame-Options: SAMEORIGIN blocks third-party framing.
  • postMessage listeners verify event.origin === window.location.origin (v227+) so a malicious popup can't inject project state into a logged-in session.

Multi-tenant isolation

  • Studios are isolated by the studios.id UUID. A user is only a member of studios listed in studio_members.
  • Studio-aware reads / writes filter on studios.deleted_at IS NULL so a deleted studio's data is no longer visible (with a 30-day grace window before background hard-purge).
  • The user.created Clerk webhook cross-checks the invited studio_id against our own audit log of member.invited events before granting membership — Clerk metadata alone is not authoritative.

Sub-processors

Full list at /legal/sub-processors. Summary:

Sub-processorPurposeData
VercelHosting + edge CDNFunction logs, request metadata
SupabaseDatabase + Storage + Auth (Postgres role)Project payloads, assets, audit log
ClerkAuthentication + user identityEmail, name, avatar, organization membership
StripeSubscription + payment processingBilling email, payment method (tokenised)
OpenAIImage generation (gpt-image-1 / gpt-image-2) + AI Producer chat (gpt-4o-mini)Asset prompts, project context, chat history
ResendTransactional emailNotification emails
Upstash (Redis)Rate-limiting countersUser IDs + endpoint hashes (no content)
Sentry (optional)Error telemetryStack traces, breadcrumbs (PII scrubbed)

We notify the studio owner via email + in-app announcement at least 30 days before adding any new sub-processor.


AI provider terms

  • OpenAI: every AI feature on Spinative runs through the OpenAI API under the standard "Business Terms" — image generation (gpt-image-1 / gpt-image-2), the AI Producer chat (gpt-4o-mini), vision describe (typography / reference analysis). Prompts and outputs are not used to train OpenAI models. OpenAI retains data for up to 30 days for abuse monitoring, then deletes. OpenAI's enterprise privacy commitments.
  • We do not use any AI feature with consumer-grade ToS that train on customer data. If we add a new model or provider (e.g. an Anthropic chat experiment, Runway video), this page is updated and a sub-processor announcement is sent before the model goes live.

Backups & retention

  • Backups: Supabase Pro tier provides daily backups with 7-day rolling retention. Enterprise tier (which we move to on signup of our first enterprise customer) provides 14-day PITR.
  • Project snapshots: every 15 minutes, the editor takes an automatic snapshot of the active project payload. Manual snapshots are unlimited. Both persist in project_snapshots and survive accidental edits.
  • Soft-delete: deleting a studio via the Clerk dashboard flips studios.deleted_at instead of cascading a hard delete. The studio's projects, assets, and audit log remain recoverable for 30 days, after which a background sweep performs the hard purge.
  • Deletion on request: account / workspace deletion fulfilled within 30 days. Backups containing deleted data are aged out within the backup retention window above.

Authentication

  • Clerk-managed identities. Email + password, OAuth (Google, Microsoft, GitHub), and magic-link supported out of the box.
  • 2FA: TOTP supported via Clerk; enforceable per-studio on Studio + Enterprise plans.
  • SSO (SAML / OIDC): supported for Enterprise plans via Clerk's SSO connection.
  • Session management: Clerk-managed session tokens; configurable session length and refresh policy per environment.
  • Webhook secrets (Clerk + Stripe): rotated independently; never persisted to the database.

Data portability

  • Project export: from the editor, "Export" produces a single JSON payload of every layer, asset reference, and metadata field — sufficient to reconstruct the project in another tool. Workspace-level bulk export (all projects in one zip) is on the roadmap (Q3 2026).
  • Audit log export: studio admins can pull the studio_audit_log table as CSV via support; self-serve export is planned.
  • Asset download: AI-generated and uploaded assets remain available as direct URLs; users can right-click → Save or download in bulk via the Export menu.

Security operations

PracticeStatus
Per-user rate limits on AI endpoints✅ Live (Upstash backend, in-memory fallback)
Server-side audit log for destructive mutations✅ Live (member changes, project deletes, settings updates, share-link create/revoke, plan changes)
Content Security Policy✅ Report-only today; enforcement after 30-day reporting window
Strict transport (HSTS preload)✅ Live
X-Frame-Options + frame-ancestors✅ Live
Error monitoring (Sentry)✅ Configured; activates when DSN provided
Health probes for uptime monitoring✅ /api/health + token-gated /api/health/deep
Penetration testQ4 2026 (planned)
SOC 2 Type IQ1 2027 (planned)
SOC 2 Type IIQ3 2027 (planned)
ISO 27001Not committed

Incident response

  • We commit to acknowledging a confirmed security incident affecting customer data within 24 hours of discovery and disclosing details + remediation steps within 72 hours.
  • Acknowledgement + disclosure go to the workspace owner email registered with Clerk and via an in-app banner.
  • Post-incident reports are published at /legal/incidents (planned) and stay available indefinitely.

Reporting a vulnerability

  • Email security@spinative.com. We respond within 2 business days.
  • For high-severity issues (RCE, auth bypass, mass PII exposure), please include a working PoC and a suggested CVSS score.
  • We don't currently run a bounty program. We thank coordinated disclosure in the post-fix changelog with the researcher's name + a link of their choice (or remain anonymous if preferred).
  • In scope: spinative.com, www.spinative.com, our public APIs, our Clerk-hosted auth pages.
  • Out of scope: third-party services we depend on (please report directly to Vercel / Supabase / Clerk / Stripe / OpenAI), the AI Producer's generated text content (we cannot guarantee output safety beyond what the upstream provider commits to).

Compliance posture

Spinative is a EU-domiciled service operated by Ediciones Candel SL (España). We act as a data processor for project content uploaded by your studio members; you remain the data controller.

FrameworkStatus
GDPROperating model is GDPR-aligned. DPA available at /legal/dpa — counter-sign on request.
UK GDPRSame posture as GDPR; UK customers covered by the same DPA.
CCPA / CPRAWe respond to verifiable consumer requests. Email privacy@spinative.com.
HIPAASpinative is not HIPAA-compliant. Don't upload PHI.
PCI DSSCard data is handled exclusively by Stripe (PCI Level 1). We never see card numbers.
SOC 2Type I planned Q1 2027. See "Security operations" above for the interim.

If your procurement process requires our SIG-Lite, custom security questionnaire, or vendor assessment, email security@spinative.com with the document — we typically turn around in 5 business days.


Contact

TopicEmail
Security disclosuresecurity@spinative.com
Privacy / DSARprivacy@spinative.com
Procurement / vendor assessmentsecurity@spinative.com
General supportsupport@spinative.com
DPA / contract sign-offlegal@spinative.com

PGP key for security@spinative.com available on request.


This document is a public-facing summary. It is not a contract; the binding agreement is the Terms of Service and Data Processing Agreement linked above.

Spinative is operated by Ediciones Candel SL · CIF B23914054Paseo Martiricos 30, 29009 Málaga, Spainhello@spinative.com