Skip to main content
Recurr’s data-handling defaults are scoped to what is needed to operate the migration: cohort selection, migration outreach, checkout, entitlement sync, reporting, and billing reconciliation.

​
Subscriber data collected

For each subscriber within scope of a migration, Recurr may process:
  • Email address - to deliver migration messages and transactional follow-up
  • Subscription state - plan, tenure, renewal date, churn status, trial/intro state, and store source
  • Identity reference - the subscriber identifier in your entitlement system, used for cohort selection and webhook callbacks
  • Cohorting attributes - geo, plan mix, renewal window, acquisition source, engagement score, lifecycle state, and relevant analytics fields where available
  • Web checkout events - page views, clicks, completions, and drop-off stages on the migration checkout flow
  • Payment metadata - what Stripe exposes for billing operations, such as last 4, expiration, billing country, payment status, refund/dispute state
Raw card data never touches Recurr. Stripe handles card entry and tokenization.

​
What’s not collected by default

  • Customer support transcripts
  • Product content created by the subscriber
  • Demographic data unrelated to migration
  • Advertising IDs, unless explicitly scoped for cohorting
  • Raw event streams beyond the fields required for migration analysis
Some migrations require subscriber-level analytics fields to build safe cohorts. The goal is not to ingest every product event forever; it is to create enough cohort signal to sequence waves and measure migration impact.

​
Where data lives

  • Subscriber records - Supabase Postgres database, encrypted at rest, row-level-security enforced per tenant
  • Analytics-derived cohort fields - stored against subscriber records for wave selection and reporting
  • Email send, open, and click events - Resend analytics, accessible via Recurr’s dashboard
  • Payment data - Stripe, in your Connect account, with the same data-handling posture as any Stripe customer
  • Aggregate cohort metrics - Recurr analytics, used for benchmarking, reporting, and gating decisions

​
Retention

  • Active subscriber records - retained for the duration of the engagement
  • Cohort and migration logs - retained for the engagement and standard reporting window
  • Email events - 12 months by default, then aggregated and per-event records deleted where no longer needed
  • Web analytics - 13 months on the rolling window
  • Stripe data - Stripe’s default retention applies and is customer-controlled through the Connect account
Customer-side data export is available at any point during the engagement: subscriber records, cohort metrics, migration logs, and billing events can be exported as CSV or JSON via the Recurr dashboard.

​
Subscriber data rights

Subscribers can exercise GDPR / CCPA rights via:
  • The customer’s own existing privacy mechanism, which the framework supports
  • A direct request to Recurr support if needed, though most requests come through the app’s existing channel
Specific rights supported:
  • Right of access - what data is held, exported in machine-readable form
  • Right to erasure - record deletion, with audit-log retention only as needed for fraud, billing reconciliation, tax, or legal obligations
  • Right to portability - same as access, in standard JSON
  • Right to object - opt out of marketing cadence; transactional billing communications continue while the subscription is active

​
Customer-controlled deletion

Customer-side admins can delete a subscriber’s records on request through the dashboard. The deletion is real, preserving only the audit trail required for billing reconciliation, tax, fraud, or legal obligations. For customers leaving the platform, full data export and deletion are part of the offboarding process, typically completed within 30 days of formal exit notice. See Portability and reversibility for the full picture of what stays with you.

​
Sub-processors

Recurr’s sub-processors fall into two categories — those that handle subscriber data, and internal tooling that doesn’t touch subscriber data. Processors handling subscriber data (named in the DPA):
  • Stripe — payment processing for web subscriptions
  • Supabase — managed Postgres + auth (subscriber records, subscription state)
  • Vercel — hosting for customer-facing surfaces (branded checkout, billing portal, help center)
  • Resend — transactional email delivery (migration outreach + lifecycle messages)
  • AWS — underlying infrastructure for Supabase + email storage
Internal tooling (operational only, no subscriber PII processing by default):
  • Sentry — error monitoring; subscriber identifiers excluded from production logs and stack traces
  • PostHog — Recurr’s product analytics for the tenant dashboard; subscriber PII not piped through
  • Google Workspace — internal operations (email, calendars, documents)
Notification of any sub-processor change in the subscriber-data category comes 30 days in advance via email to the customer’s named contact. Internal tooling changes that don’t affect subscriber-data handling are not subject to notification. Compliance posture