Privacy Policy

Account and sign-in. Helmwatch uses email magic links for account sign-in. The account records an email address, a name when provided, verification and account timestamps, and the session needed to keep you signed in. The current sign-in flow does not ask you to create a Helmwatch password. The session schema has optional nullable fields for a request IP address and browser User-Agent. This checkout does not establish whether runtime code populates those fields or how it handles absent values, so both behaviors are unknown here. This is a statement about session fields, not a separate fraud scoring feature.

Workspace and client records. Depending on the features you use, Helmwatch stores client names and email addresses, source, rates, notes, invoice line items and amounts, invoice status and dates, incident source and identifiers, service and monitor names, severity, summaries and timestamps. It also stores reply threads, matched message headers and bodies, drafts, approved or sent message details, and the related audit or feedback records used by the workspace.

Voice profile and integrations. A voice profile can contain the example text you save, style notes and preferences used to shape drafts. Integration records can include the provider name, connection and verification status, dates, account labels, granted scopes, and credentials or tokens needed for a connection. Gmail OAuth tokens and webhook credentials are stored server-side. The app does not expose those credential fields in its settings responses.

Operational records. Helmwatch records events such as signup, onboarding and integration activity, along with audit entries for workflow decisions. These records support workspace status, activity history, and the product’s operational reporting.

Polsia services. Helmwatch runs on Polsia’s application and database platform. When a feature needs an AI draft or summary, the selected source text and relevant workspace context are sent to the Polsia AI proxy. Email messages, including sign-in links, digests and approved client messages, are sent through the Polsia email proxy. For a Gmail reply, the AI request includes the thread subject, latest matched inbound message body and saved voice context; an approved delivery sends the recipient, subject and approved body to the email proxy. The Gmail message is not sent from your Gmail account.

Services you connect. Linear can send issue events to Helmwatch for invoice drafting. PagerDuty and Better Stack can send incident events to Helmwatch. If you enable a Slack digest and provide an incoming webhook, Helmwatch sends digest text and its included workspace links to that Slack destination. Google and Stripe data flows are described below.

The Settings area also has a separate Stripe workspace connection and stores Stripe-related invoice references. In this checkout, invoice draft identifiers are generated locally and the open-invoice reader returns no provider records; no separate Stripe API exchange for those client invoice workflows is implemented. Do not confuse that status and local reference with the Stripe hosted checkout used to pay for Helmwatch.

Email magic-link sign-in is Helmwatch’s account login. Separately, if you connect Gmail in Settings, Google OAuth authorizes that mailbox for the reply workflow and supplies the connected-account label. This is not Google social sign-in to Helmwatch. Helmwatch requests the openid identity scope and the read-only gmail.readonly Gmail permission. It does not request Gmail permission to send, delete or modify messages.

When the replies workflow syncs, it checks up to 50 recent thread IDs, selected Subject, From, To, Date and Message-ID headers, and the inbox unread count. It fetches full message content only for a thread whose sender matches a client in your workspace. Matched inbound content may be stored with the thread, draft, sent message, audit and feedback records so the workflow can show context and prepare a reply. Helmwatch does not operate as a general mailbox mirror.

OAuth access and refresh tokens, expiry and granted scope are stored server-side on the account’s integration record. For drafting, the subject, latest matched inbound body and saved voice context go to the Polsia AI proxy. After you approve a reply, the recipient, subject and approved body go to the Polsia email proxy for delivery. Approval does not create a Gmail Draft or Sent item. Helmwatch does not use Gmail data for its own model training, advertising or unrelated purposes. The downstream services’ own handling is governed by their terms; Helmwatch cannot verify their retention or deletion from this app.

The 14-day Practice trial is a separate no-card, no-automatic-renewal flow. If you choose the paid Practice subscription, the app opens Stripe’s hosted Checkout for the $149 monthly plan. The one-time Founder Pass also uses hosted Stripe Checkout when that offer is available; it is not the monthly subscription.

Stripe receives the checkout details needed to process the selected purchase, including its product and amount, the account or purchase reference supplied by Helmwatch, the account email for subscription checkout, and payment information entered on Stripe’s hosted page. Helmwatch stores its own account-linked subscription or Founder Pass status, plan or offer, trial and access dates, customer email where applicable, and Stripe Checkout session reference. Payment card numbers and security codes are entered on Stripe’s hosted checkout and are not stored in Helmwatch’s application records. Stripe’s handling of payment data is subject to Stripe’s own terms and privacy information.

Subscription changes are managed through the billing controls and Stripe’s customer portal. Canceling renewal is a billing control; it does not itself delete workspace history.

Helmwatch uses authentication cookies to keep an account session and short-lived state cookies during the Google OAuth connection. The website also loads the Meta Pixel after the page becomes interactive. The current code sends a PageView event, a Lead event after a signup magic-link request returns success, and a Purchase event only after checkout verification succeeds. The Purchase event includes the verified amount and currency and may include a product name.

The Meta Pixel is a website-measurement tag; it does not display advertisements on the Helmwatch site. The app code does not establish whether Meta associates these events with a social profile, uses them for ad measurement or retargeting, or how long Meta retains them. Those downstream practices are not verified here. The code does not show another social-profile collection or fraud-scoring workflow.

When the deploy configures Polsia visitor analytics, Helmwatch creates a randompolsia_vid identifier in browser local storage and sends a visitor beacon with that identifier and the app’s analytics slug for each page load. This is for website visitor measurement, not ad display. The analytics service’s further collection, including any request metadata or retention period, is not visible to this app and is unknown here. Whether the production deploy has configured this optional beacon is also not visible in this checkout. You can clear browser cookies and local storage or use browser controls that block these scripts; blocking authentication cookies may prevent sign-in from working.

Although the session schema has optional nullable fields for IP address and browser User-Agent, whether application runtime code populates them and what it does when either value is absent are unknown from this checkout. Whether the hosting or network layer keeps additional request logs, and their contents or retention, is not established by this checkout.

There is no finite retention period, automatic purge job or general self-service historical deletion flow currently implemented for Gmail threads, matched messages, reply drafts, sent records, audit records and feedback. Disconnecting Gmail attempts to revoke Google access and clears the local OAuth fields; it does not delete workflow history already stored in the workspace.

The app does not show a general self-service account-deletion workflow. A separate retention schedule for other workspace records, account records, backups and copies held by providers is not established by this checkout. Contact the owner with a correction or deletion request; this contact route is not a promise that a request can be completed, or that it will be completed within a particular time. Provider-held data is also subject to the provider’s own terms and controls.

You can disconnect integrations, replace saved voice-profile details, change digest settings and manage paid subscription renewal in the available workspace controls. These controls stop or change future product activity; they do not automatically erase historical records.