Privacy policy

1. Who we are

Bridgrs ("Bridgrs", "we", "us", "our") operates the application at app.bridgrs.com and the marketing site at bridgrs.com. Bridgrs is an email operations platform built for business development teams running high-volume outreach.

This policy covers both the application and the marketing site. By creating an account or connecting a mailbox, you agree to the terms described below.

2. Information we collect

We collect only what we need to run the service. Categories:

• Account data — name, work email, hashed password or OAuth identity provider subject ID, organization name.
• Email metadata — sender address, recipient addresses, subject line, Message-Id, thread identifier, timestamp, Gmail label IDs, and the AI classification label we assign (e.g. Interview Confirmed, Action Required, Interested, Out of Office, Unsubscribed).
• Usage data — pages visited in app, feature toggles flipped, dashboard filters used. Collected via first-party analytics only.
• Device / connection data — IP address, browser user-agent, session cookie ID for the purposes of authentication and abuse prevention.
• Support data — anything you email us at hello@bridgrs.com or privacy@bridgrs.com.

We do not store the body content of your emails beyond the in-memory window required to classify them. See Section 4.

3. Google API Services — Limited Use disclosure

When you connect a Google account to Bridgrs, we access Gmail data only to deliver the user-facing features described on bridgrs.com and in the application. Specifically:

• We do not use Gmail data to serve advertising, including retargeting or personalised ads.
• We do not sell or transfer Gmail data to third parties except the limited, named sub-processors listed in Section 7, and then only for the purposes described.
• We do not use Gmail data to train, fine-tune, improve, or otherwise feed any generalised or large-language AI model.
• We do not allow humans to read Gmail data except (a) with your explicit consent, (b) for security investigation, abuse detection or enforcement, (c) to comply with applicable law, or (d) for internal operations where the data has been aggregated and anonymised.

Scopes we request and why

How Gmail access works end-to-end

1. You connect a Google account via standard OAuth 2.0. Bridgrs never handles your Google password directly.
2. The refresh token is stored encrypted at rest, written only by server-side edge functions using service-role credentials. It is never sent to a browser.
3. A scheduled worker fetches new inbound messages at a cadence between 1 and 30 minutes depending on time of day.
4. For each inbound message, the body is loaded into server memory, passed to the classifier, and the resulting label is written to our database. The body itself is discarded from memory inside the same request — typically within a second.
5. When you approve an AI-drafted reply and click Send, Bridgrs uses the gmail.send scope to deliver the message from your Gmail account.

Revoking access

You can revoke Bridgrs's access to your Google account at any time — either inside Bridgrs (Settings → Email Providers → Disconnect) or via Google Account permissions. On disconnect Bridgrs revokes the refresh token against Google and stops all future sync and classification for that mailbox.

4. Email body — what actually happens

This is the most sensitive thing we do, so it's worth saying plainly:

• We never write the email body to disk, database, or any long-term storage.
• The body exists in the memory of the classification worker for the duration of a single request (under 3 seconds in the typical case).
• After the classification completes, the body reference is dropped and the memory is reclaimed by the garbage collector on the next cycle.
• What we retain is the classification label itself (e.g. Interview Confirmed), the message headers required to reconstruct the thread view (From, To, Cc, Subject, Date, Message-Id, In-Reply-To), and the Gmail thread identifier.

If you want to verify this, point a compliance auditor at security@bridgrs.com and we will walk through the classification pipeline and database schema with them.

5. How we use your data

• To sync your mailboxes, classify inbound replies, and render your dashboard.
• To compute per-rep and per-campaign analytics inside your workspace — not across workspaces.
• To send service notices (security alerts, billing changes, critical outages).
• To respond to support requests you initiate.
• To detect, investigate, and prevent abuse, spam, and security incidents.
• To comply with law enforcement requests when legally compelled.

6. Legal bases for processing (GDPR / UK GDPR)

If you are in the EEA or the UK, we process your data under one or more of these legal bases:

• Contract — to deliver the Bridgrs service you or your organization signed up for.
• Legitimate interests — to secure the service, prevent fraud, and improve reliability. These interests are balanced against your rights.
• Consent — for optional processing such as product-update emails, which you can withdraw at any time.
• Legal obligation — where required by applicable law.

7. Sub-processors

We use a short list of infrastructure providers to run Bridgrs. Each operates under a Data Processing Agreement and only processes data as instructed:

• Supabase (AWS us-east-1) — primary database, authentication, realtime.
• Fly.io — voice AI WebSocket worker (used only when your workspace enables voice AI; not used for email processing).
• Google Cloud (Gemini API) — AI classification under a zero-data-retention agreement.
• Hostinger — static hosting for the bridgrs.com marketing site (this page).
• Resend / Postmark — transactional service emails only; never customer outreach email.
• Twilio — used only if your workspace enables voice features; not used for email processing.

We do not sell data. We do not share data with advertising networks. We do not rent lists.

8. Where your data is stored

Primary storage is in the United States (AWS us-east-1). Classification requests may hit Google Cloud regions selected automatically for latency. For EEA/UK customers requiring data residency in-region, contact security@bridgrs.com and we will discuss workspace-level regional isolation.

9. Security measures

• TLS 1.2+ on all traffic to and from Bridgrs.
• AES-256 encryption at rest for database storage.
• Row-level security (RLS) enforced in Postgres — every query is automatically scoped by workspace and role.
• Sensitive credentials (OAuth refresh tokens) accessible only to service-role edge functions, never to browser clients.
• Hardened CI/CD pipeline with required reviews on protected branches.
• Annual penetration test; report available to enterprise customers under NDA.

10. Data retention and deletion

• Email metadata and classifications are retained for the lifetime of your account.
• You can delete individual conversations, entire mailboxes, or your whole workspace at any time from the in-app settings.
• Upon account deletion, all workspace data — metadata, classifications, analytics rows, audit log entries — is permanently deleted within 24 hours. Backups age out within 30 days.
• Disconnecting a mailbox revokes the OAuth refresh token against Google in the same request.

11. Your rights

Depending on where you live, you may have the right to:

• Access the data we hold about you.
• Correct inaccurate data.
• Delete your data (right to be forgotten).
• Receive your data in a portable format.
• Object to or restrict certain processing.
• Lodge a complaint with a supervisory authority.

To exercise any of these rights, email privacy@bridgrs.com. We respond within 30 days.

12. Cookies

The marketing site uses no advertising or tracking cookies. The application uses first-party session cookies strictly for authentication and a small number of localStorage keys (active workspace, active section, preferred theme). No third-party cookies are set by Bridgrs.

13. Children

Bridgrs is a B2B product. We do not target or knowingly collect data from anyone under 18.

14. Changes

We'll update this page when we change how we handle data. Material changes are announced via product notice inside the application at least 14 days before they take effect. The Updated date at the top always reflects the most recent version.

15. Contact

Privacy questions or data requests: privacy@bridgrs.com
Security issues: security@bridgrs.com
General: hello@bridgrs.com