How RepSentinel handles your data

When you create an account we record the data needed to authenticate you and to keep your sign-in working across devices: a user id, your name, your email address, an email-verification flag, an optional profile image, the timestamp of your last login, and the usual creation/update audit timestamps. LinkedIn, X, Facebook and Instagram are not used to sign you in — those platforms are connected after sign-in only, so your account is independent of any social account.

Two authentication paths are enabled: email + password (minimum 12 characters, enforced server-side) and a passwordless magic link (single-use token, SHA-256 hashed at rest, 15-minute expiry). Branded cookies repsentinel.session_token and repsentinel.session_data maintain the session; both are httpOnly and secure, so JavaScript cannot read them and they only travel over HTTPS. The lawful basis for storing this data is the service contract (your agreement to our terms when you create an account) and our legitimate interest in preventing abuse.

After you sign in you can grant RepSentinel limited access to a social-platform account so we can monitor mentions of you across it and, on supported platforms, publish counter-content on your behalf after you approve each piece. Every grant is recorded as its own row, scoped to your user id alone, and you can revoke it from the connected-platforms settings card at any time — revocation deletes the row and stops our use of the token. Per-platform specifics:

• LinkedIn. We request the minimum scopes needed to read posts on your behalf (self profile, or one organization page you declare as yours). We store the access token, optional refresh token, expiry, your LinkedIn URN, optionally a LinkedIn organization URN, the authorization type (self vs. organization), and your display name.
• X / Twitter. We store your X user id, your X handle, the OAuth scope string, and the token pair. Tokens are encrypted at rest with AES-256-GCM using a managed encryption key — the on-disk value is a ciphertext blob, and the plaintext is reconstructed only inside the publish path.
• Facebook Pages. We request the minimum read-and-publish scopes (pages_show_list, pages_manage_posts, pages_read_engagement). We record your Facebook user id, page id and page name, and the timestamp at which you acknowledged Facebook Platform Policy §IV (the Pages API terms) during connect.
• Instagram. We request instagram_basic + pages_show_list + pages_read_engagement so we can read public posts that mention your brand. Instagram is monitoring only — we do not publish on Instagram.

We do not share data from one connected platform with another, and we do not share your connected-platform data with any third party except as needed to make the platform's own API (the call our request is part of) — i.e. the platform you're connected to is the only external recipient of your data on that path.

For each brand profile you create we poll a configurable set of public sources for matches against your declared keywords. The full source catalog is: Twitter/X, Reddit, news (RSS), blogs (RSS), podcasts (RSS — Apple + Spotify feeds), Google News, LinkedIn public posts, Facebook public posts, Instagram public posts, Hacker News (Algolia), Product Hunt, G2, Trustpilot, Capterra, and a seed path for operator-only testing. The shipped default set is Twitter/X, Reddit, news, blogs and Google News — adding more sources is opt-in per brand in the monitoring wizard.

For every match we store the keyword, the source, the platform's external id for the post, the author's handle and (when public) display name, the post body text, a permalink, the sentiment label and score returned by our scoring pipeline, and optional reach signals (followers / retweets / shares / view counts). Dedup is enforced by a per-(brand, source, external-id) index so a post that fans out to one keyword is not re-ingested for the others. We do not perform mass scraping of unrelated content — every fetch is bounded to the keywords you declare, and we keep fetched material only as long as it is useful for review and audit; after that, it ages out of the feed the same way deletions on the source platform do.

We send email notifications for four kinds of events, each with their own threshold and opt-out:

• Real-time mention alert. When a newly ingested mention crosses your severity threshold (default 70/100) OR crosses your sentiment floor (default −0.5), we send one email per matching row. The per-mention check is idempotent on the row's alertedAt timestamp, so duplicates cannot re-send.
• Weekly digest. Once per week (Mondays by default; per-brand override), an aggregate of the week's activity is emailed. Retries inside the same week are suppressed by a per-(brand, week) idempotency log row.
• Sentiment-dip warning. A daily sweep over each brand's 7-day sentiment series flags days that drop meaningfully below the trailing baseline.
• Negative-spike warning. Every 30 minutes, a sliding-window check (default: 3 negative mentions within 60 minutes) fires an alert when the rate crosses the brand's configured multiplier.

The default recipient for alerts is the alert email you set during brand onboarding, overridable per company from the notification settings. SMS delivery is an opt-in knob on the same settings page; it is dormant by default and is not activated until our messaging provider credentials are deployed — when that happens, the page reflects it under "current state" above and an opt-in user will receive text alerts at their E.164 phone number for the same events.

RepSentinel is a hosted service; the data we collect moves through a small, named set of managed providers:

• Managed Postgres. All persistent application data (users, sessions, mentions, alerts, brand profiles, connected platforms, notification logs, billing subscriptions) lives on a managed Postgres database provisioned by the platform. DATABASE_URL is wired at deploy time.
• Email delivery. Outbound mail is sent through the platform's email proxy — there is no SendGrid, Postmark or Resend SDK in this codebase, and the proxy is the only path. Recipients see mail from the company's single verified sender identity. Attachments, carbon-copy, blind-carbon-copy and custom from-addresses are not supported by the proxy and are therefore never sent.
• AI inference. Generated counter- content, sentiment scoring and image analysis are routed through the platform's OpenAI-compatible proxy. There is no OpenAI or Anthropic SDK or key in this codebase — calls flow through @/lib/ai/client.
• Payments. Paid plans are billed through the platform's Stripe Connect proxy. There is no Stripe SDK, no Stripe secret key, and no inbound Stripe webhook endpoint in this codebase; the proxy is the only integration, and receipts are pulled on a recurring reconcile job.
• Social platforms. Each connected platform (LinkedIn, X, Facebook, Instagram) is a downstream data recipient limited to the call we make to its API. Their own privacy terms govern how they store the post we read from them or the post we publish on your behalf.
• Hosting. The app itself is deployed by Polsia and is reachable at the same URL you are reading this page on. Health-check probes are served at /health.

No on-device SDK ships with the app and no third-party tracker pixels are loaded by the marketing or app pages.

We keep data only as long as it serves an active purpose. Account data is retained until you delete your account. Mention records are retained for the rolling window needed to operate alerting and the weekly digest, after which they are eligible for deletion by the same reconcile job that cleans up stale cursors. Connected-platform rows are deleted the instant you revoke the grant.

Available controls today:

• Per-platform disconnect. Each connected platform has a Disconnect control in its card on the integrations page; clicking it deletes the connection row and stops our use of its token immediately.
• Alert and digest opt-out. The notification settings page lets you disable real-time alerts, the weekly digest, the sentiment-dip warning and the negative-spike warning independently.
• Sign-out. Signing out clears the session cookies in your browser. The session row itself expires automatically and is then deleted by the session-cleanup job.

For requests we do not yet expose in-product — full account deletion, data export, or anything else — email us with the email address on your account and we will action the request within 30 days at no cost. The address we hear from is verified against your account before any export or deletion takes effect, so an unrelated third party cannot trigger a deletion by emailing us in your name.

Each platform's own user data (your LinkedIn profile, Facebook page, Instagram business account, X account) lives on those platforms — those providers answer their own data-subject requests. Revoking a connection here ends RepSentinel's use of that data; it does not delete the underlying account on the social platform.

RepSentinel is built for adults running a personal or small-business brand. The service is not directed at children under 16 and we do not knowingly collect personal data from anyone under 16. If you believe a child has created an account, email us and we will delete the account and its data within 30 days.

Material changes to this policy will update the "Last updated" stamp at the top of this page. Where a change meaningfully expands the categories of data we collect, the new scope will not apply to data collected under the previous version, and existing users will be told in-product before the change takes effect. Continued use of RepSentinel after the effective date of a change is acceptance of the new policy.

Privacy questions, deletion requests and data-export requests all go to the same inbox: repsentinel-3-2@polsia.app. We acknowledge within five business days and complete standard requests within 30 days.