Privacy

1. What we collect

• X connection: a read-only OAuth connection by default (tweet.read, users.read, offline.access). We store OAuth tokens (encrypted at rest), handle, display name, profile image/banner, public bio, and public follower counts when provided by X. Posting requires a second, explicit grant (tweet.write). Nothing posts without that grant and an approve step.
• Scoring: numeric metrics needed for Peak Score (e.g. impressions, engagement counts, post ids/dates/types). We do not store post text for OAuth scoring. Ranked-post views use those same metrics plus a permalink to X.
• Studio drafts and publish jobs: text you write or generate inside ReachPeaks, plus an optional send time. Generation uses your bio, the open plan, and format metrics from your own posts - not stored X post text and not other accounts. That body is your draft, not a copy of an X post. Quote drafts and jobs may store a tweet id you paste so X can attach the quote card. Engage replies may store a tweet id you paste so X can attach the reply; we do not fetch or store the other post. We also store handles you add to the Engage watchlist. Drafts, jobs, and watches are deleted when you disconnect.
• CSV import: parsing happens on-device first; we receive only the metrics you upload after client parse.
• Waitlist (www.reachpeaks.io): the email address you submit, plus a hashed IP and your browser user agent, used to rate-limit abuse. The email is stored so we can send the one message you asked for. No X connection is involved and no score is computed.
• Score breakdown by email (app.reachpeaks.io): the same email, hashed IP and user agent, plus two facts about the score already on your screen - its grade band and which dimension came out weakest. Those two are used only in aggregate, to see which results lead people to sign up, and they are deleted with your waitlist entry.
• Product ops: score history, plan progress, optional day-7 reminder and one mid-week plan digest email (one-time, then removed), billing customer ids via Stripe, and decision-critical funnel events. Funnel records use a salted browser-session hash. Referrer and user agent are reduced to fixed source and device labels before storage. We do not put raw identifiers or content in the product-event ledger.

2. What we do not do

• We do not like, follow, unfollow, or DM. A post or reply goes out only after a write grant and an explicit approve (now, or at a time you set).
• We do not sell your score history as a data product.
• We do not claim scores as causal proof of reach.

3. Why we process data

To compute Peak Score, show history, run optional seven-day plans, send one-time follow-up reminders you opt into, draft and schedule approved posts through the official X API, and operate paid subscriptions.

4. Processors

Infrastructure may include hosting (e.g. Vercel), database (Turso), email (Resend), payments (Stripe), web analytics (Vercel, cookieless; DataFast, which sets first-party analytics cookies on reachpeaks.io to recognise a returning browser), and draft generation (xAI). When you start a checkout, the DataFast visitor and session identifiers are attached to the Stripe session so the purchase can be attributed to the channel that brought you here; they identify a browser, not a person. Studio sends your bio, the open plan, and format metrics from your own posts - not stored X post text and not other accounts. Each processor has its own privacy terms.

5. Retention and control

Disconnect X revokes the ReachPeaks session. You may also revoke the app in X settings. Reminder emails are stored only while scheduled, then removed after send. Product-event rows are retained for up to 90 days. Billing records follow Stripe and tax requirements. To be removed from the waitlist, reply to the message you receive or use the contact path below, and we delete the address.

6. Contact

For data questions use the contact path on www.reachpeaks.io.