Privacy Policy
Last updated: 2026-04-27
Flow is a workflow-automation platform where you design flows, connect them to your own tools and AI providers, and run them on our servers. This policy describes what data we hold about you, what we do with it, what we deliberately do not do, and how you can get it out or delete it.
1. Who we are
Flow is operated by Lumnar, based in Romania (European Union). When this policy says "we", "us", or "the platform", it means Lumnar as the data controller for the account and service-operation data described below. For data you push through your flows to third parties, you are the data controller and we are a processor acting on your instructions.
You can reach us at max@lumnar.com.
2. Data we collect
Account data
- The email address you sign up with, and your password (stored as a salted bcrypt hash; we never see the plaintext).
- If you sign in with Google: your Google account ID, email, and profile name. We don't ask Google for anything else.
- Optional fields you choose to fill in (name, company, country, phone, website) if you provide them during onboarding or account settings.
- Billing information when you subscribe to a paid plan, handled by Stripe — we only see the last four digits of your card and the customer ID Stripe assigns you. Full card numbers never reach our servers.
Flow data (the things you build)
- Your scenarios, steps, branches, positions on the canvas, and any settings you enter — this is what makes your flows work and we store it so you can come back to it.
- Files you explicitly upload to a flow (samples, inputs, documents you want processed).
- Vector-database entries if your flow uses the Qdrant module.
- Public documentation you write for a flow.
Runtime data
- Execution logs — which steps ran, in what order, how long they took, whether they errored, and for debugging: the inputs and outputs at each step.
- Usage counters (step-runs, flow-runs, tokens, cost) used to enforce plan limits and to show you your own usage.
- Error reports captured by the platform when something fails, including stack traces and the request that triggered the error, so we can fix bugs.
- Basic request metadata (IP address, user agent, timestamp) for security, abuse prevention, and legal compliance.
3. What we do not do
- We do not sell your personal data. There is no advertising business here.
- We do not read your flow executions for purposes other than running them, billing them, supporting you, or fighting abuse. No employee browses flow content for fun.
- We do not use your configured API keys, webhook URLs, or integration credentials for anything other than dispatching the calls your own flows ask us to make.
- We do not share your data with law enforcement absent a valid legal process, and when we receive one, we will narrow the scope to what the request legally compels.
4. How we handle credentials you upload
Flows often need secrets — OpenAI keys, Twilio tokens, Gmail OAuth tokens, database URLs, webhook signing keys, and so on. These live in one of two places:
- Per-scenario credentials are stored in JSON files under a storage directory outside the public web root. They are readable only by the scenario that owns them.
- Account-level API keys (for the Interface page and similar account-scoped features) live in the
users_api_keysdatabase table.
Either way, we only access a credential when one of your own flows asks us to dispatch a call that needs it. We do not proxy, cache, or reuse credentials across accounts.
5. AI providers and your prompts
The platform uses your own OpenAI, OpenRouter, Anthropic, or compatible API key (your choice) to dispatch LLM calls on your behalf. The prompts and responses travel directly from our server to the AI provider you've configured. The content of those prompts and responses is then subject to that provider's privacy policy — not ours — because they are the ones processing it.
We do store a copy of each AI call in the flow's execution log so that you can debug it. Those logs are retained per the schedule in section 9.
6. Google APIs and Gmail data (Limited Use disclosure)
This section describes Lumnar Flow's compliance with the Google API Services User Data Policy, including the Limited Use requirements that apply when an application accesses data from restricted or sensitive Google APIs such as Gmail.
What we ask for
When you click 🔗 Connect Gmail account in a Gmail credential editor inside Lumnar Flow, the platform initiates Google's standard OAuth 2.0 flow with one scope:
-
https://www.googleapis.com/auth/gmail.send— Send email on your behalf. Used by thesend_messagemode of the Gmail module to deliver mail through your Gmail account when one of your flows asks it to.
This is the only Google scope Lumnar Flow currently
requests. The Gmail module's source code also defines additional
read/modify/draft modes (search, fetch, save attachments, label
management, drafts, automatic reply threading), but those modes need
restricted scopes (gmail.readonly, gmail.modify,
gmail.compose) which are not requested by the OAuth flow
and not active on this deployment. Those modes return a clear
"[NOT AVAILABLE YET]" error to the calling flow if invoked.
How we use Gmail user data
-
Inside
send_message, we use thegmail.sendscope to submit the user's outgoing message to Google'susers.messages.sendAPI. We do not retain a copy of the message body once it has been handed off, beyond the standard execution-log retention described in section 9. -
We store a refresh token in the user's per-scenario
credentials file (
scenarios/{user_id}/{slug}/credentials/gmail.json), outside the public web root, with restricted filesystem permissions. This is so the platform can transparently refresh the access token before each call without prompting the user to re-authenticate. - The connected Gmail address is stored alongside, so the credential UI can show users which Google account is bound and so flow steps can include it as the From: address.
-
We do not call any Gmail API endpoint outside the explicit
send_messageandwhoamimodes that the user invokes from their flow. There is no background polling, no speculative fetching, no batch read operation.
Limited Use commitments
Concretely:
- No advertising. We do not display ads on Lumnar Flow, and we never use Google user data to power any advertising or marketing system, ours or anyone else's.
- No transfer for unrelated purposes. We do not transfer Google user data to third parties except as necessary to provide or improve user-facing features of Lumnar Flow itself, to comply with applicable law, or as part of a merger or acquisition with appropriate notice.
- No selling. We do not sell Google user data to anyone, ever.
- No human reading except limited cases. No employee at Lumnar reads the content of email a user sends through the Gmail module, except (a) with the user's explicit permission for support purposes, (b) for security investigations such as verified abuse detection, or (c) to comply with applicable law.
- No AI/ML training. We do not use Google user data — including Gmail content, refresh tokens, recipient lists, send-time metadata, or anything else obtained via Google APIs — to train, fine-tune, or evaluate generalized or personalized AI/ML models. The "no training" promise in section 3 applies in full to Google user data.
How users can revoke and delete
A user can disconnect a Gmail credential and remove all Google data we hold for it in two ways:
-
From inside Lumnar Flow: open the Gmail credential's
status modal in the editor, click Disconnect & revoke.
The platform calls Google's
https://oauth2.googleapis.com/revokeendpoint to revoke the refresh token at Google, and immediately clears the refresh_token, access_token, expires_at, scopes, email_address, and connected_at fields fromcredentials/gmail.json. -
From Google's account dashboard: visit
myaccount.google.com/permissions
and remove "Lumnar Flow — Gmail integration". Once revoked at
Google's end, the next API call from Lumnar Flow will fail with
reauth_required: true, and on the next reconnect or disconnect operation we clear the dead tokens from our store.
When a user deletes their Lumnar Flow account, the per-scenario
credentials/gmail.json files are removed within 30 days as
part of the standard account-data deletion described in
section 9.
What we DO NOT access
Lumnar Flow never requests, and the Gmail module's source code never attempts to call:
- Permanent deletion of email (no Google scope grants this anyway).
- Your Google Drive, Calendar, Contacts, Photos, or Workspace admin data.
- Other Google accounts you happen to be signed in with in the same browser — only the specific account you authorize during the Connect flow is bound to that credential.
- The contents of your existing inbox, sent items, drafts, or labels. Even in the future, if Lumnar completes Google's restricted-scope security audit and enables read-side modes, the consent screen at Connect time will list every additional permission and you will see and approve each one explicitly before it takes effect.
7. Sub-processors
We rely on a small set of sub-processors to operate the service. Each only receives the minimum data needed for its role:
- Our hosting provider — stores the databases, flow files, and logs described above, in the EU.
- Stripe — processes payments and stores billing records. We only send customer metadata and plan choices; Stripe handles card details directly.
- Google — if you sign in with Google, we receive your Google-verified email, profile name, and stable Google account ID.
- Email delivery provider — used to send verification emails, password resets, and transactional notices. Receives only the recipient address, subject line, and body of that specific message.
Third parties that your flows connect to (OpenAI, Gmail, WhatsApp, your CRM, etc.) are not our sub-processors — you configure them yourself and their processing happens at your direction under their own terms.
9. Retention and deletion
- Account data — kept while your account is open. Closed accounts have their personal data removed within 30 days, except records we're legally required to keep (e.g. invoices for tax purposes).
- Flow definitions and files you uploaded — kept while your account is open. Deleted flows enter a soft-deleted state for 30 days so you can recover them, then are purged.
- Execution logs / flow context — rolling window of up to 90 days unless your plan specifies longer. Older runs are pruned on a schedule.
- Error logs — kept for up to 180 days for debugging and then pruned.
- Billing records — retained for 7 years to comply with EU/Romanian tax law.
You can request earlier deletion by emailing us (see section 14).
10. Your rights (GDPR)
If you are in the EU, UK, or any other jurisdiction with similar rules, you have the right to:
- Access a copy of the personal data we hold about you.
- Correct data that is wrong.
- Delete your account and associated data (subject to the legal-retention carve-out above).
- Export your flows in a machine-readable format.
- Object to, or restrict, specific kinds of processing.
- Lodge a complaint with your local data-protection authority. In Romania that's ANSPDCP.
To exercise any of these, email max@lumnar.com from the address on your account. We reply within 30 days.
11. Children
The platform is not designed for, or directed to, children under 16. We do not knowingly collect data from them. If you believe a child has signed up, tell us and we'll remove the account.
12. Security
We follow commonly accepted practices: TLS for data in transit, bcrypt for passwords, least-privilege access to production, network-isolated databases, regular backups, and prompt patching of the stack we run on. No system is perfectly secure. If we discover a breach affecting your personal data, we will notify you and the relevant supervisory authority within 72 hours of becoming aware, per GDPR.
Reporting a suspected vulnerability: please email max@lumnar.com with reproduction steps. We appreciate responsible disclosure and won't pursue good-faith researchers.
13. Changes to this policy
When we change this policy in a way that materially affects you, we will update the "Last updated" date at the top and notify active accounts by email at least seven days before the change takes effect. Minor, non-material edits (typos, clarifications, added sub-processors of similar role) may happen without notice but will always be reflected in the date.
14. Contact
General questions, data-subject requests, sub-processor questions, anything else privacy-related: max@lumnar.com.