openid, email, profile
Why: sign-in identity. Your name and email address, to create your account.
Privacy Policy
Last updated:
This policy applies to Inbox by Pidgy at inbox.alkmist.com.
1. Who we are
Inbox by Pidgy (the "Service") is operated by Alkmist, a company incorporated in Belgium ("Alkmist", "we", "our", or "us"). We are the data controller for personal data processed through the Service, except where we act as a data processor on your behalf (for example, the contents of the emails in your mailbox).
Registered office: Ravensteinstraat 2 bus 3, 9000 Gent, Belgium
Company / VAT number: BE 1026.308.203
Contacts
- Privacy / legal: legal@alkmist.com
- User support: support@alkmist.com
- OAuth verification (Google / Microsoft reviewers): oauth-verification@alkmist.com
This Service is governed by the laws of Belgium, without regard to its conflict-of-laws rules.
2. What we collect and why
When you sign in with Google or Microsoft and use the Service, we access and process the following categories of data:
- Account profile: your name, email address, and profile picture from your Google or Microsoft account, used to authenticate you and display your account inside the app.
- OAuth tokens: the access and refresh tokens issued by Google or Microsoft so we can call their APIs on your behalf. We never see or store your password.
- Email metadata and content: headers (sender, recipients, subject, timestamps, labels, threads), body text, and attachments. We use this to triage, prioritise, search, summarise, and act on your inbox on your instruction.
- Calendar events: events from your connected calendar, which we use to show meetings alongside the related mail, to match a message against a meeting that has already finished so that mail can be archived for you, and to create events you ask us to create.
- Mailbox settings (Google accounts): a one-time read of your existing signature so we can import it into the compose window, and your send-as addresses, which we store so that mail sent to a work alias is recognised as yours. On Microsoft accounts we read your proxy and alternate addresses for the same alias matching. We request a signature there too, but the Microsoft permissions we ask for do not grant it, so we never obtain one from a Microsoft account.
- Usage and product analytics: page views, feature use, and errors, captured by PostHog (EU instance). Email body text and addresses are masked in any session replays.
- Billing data: if you subscribe, Stripe processes your payment details. We receive a customer ID and subscription status only. We never receive or store full card numbers.
3. Google API scopes
When you connect a Google account the ordinary way, we request only the scopes below. Where we have
enabled a second connection route, its consent screen asks instead for the single scope https://mail.google.com/, which is full access to the mailbox; that screen is
authoritative for what you granted. Each scope maps to a specific user-facing feature.
https://www.googleapis.com/auth/gmail.readonly
Why: read messages and threads from your Gmail inbox so we can display, triage, prioritise, search, and summarise them inside the app. Without this scope, the app cannot show your inbox.
https://www.googleapis.com/auth/gmail.modify
Why: apply labels, archive messages, mark messages as read or unread, and move a message to Trash, when you ask us to. We never delete a message outright and never empty the Trash: trashed mail goes to Gmail's own Trash, under your retention settings, and you can take it back out. Nothing on a timer trashes anything. Some actions move mail there in bulk, and they are ones you choose: unsubscribing from a sender and asking us to remove what they have already sent, which moves that sender's existing mail to Trash; and blocking a sender, which does the same and additionally writes a Gmail filter, so each later message from them is trashed without another click until you lift the block. Most writes come from an action you trigger in the UI (for example, clicking "Archive", "Mark read" or "Trash"). Archiving also happens without a further click from you: the message you have just replied to is archived; mail about a meeting or event is archived once that event has finished, at least an hour after it ends; a login code, magic link or password-reset mail is archived once it can no longer be used, after 15 minutes, an hour and a day respectively; and mail carrying a clear deadline is archived once the deadline has passed, never sooner than six hours after the mail arrived. If you switch on headless mode, which is off by default, we also write priority and category labels on your messages, refresh them nightly, and remove them once you have handled the message.
https://www.googleapis.com/auth/gmail.send
Why: send replies and new messages that you compose inside the app, through your own Gmail account. Mail leaves your account when you send it, when you forward it (including handing a thread to a colleague, which forwards it at that moment), and when you unsubscribe from a sender whose only unsubscribe route is an email, which sends a short unsubscribe request from your address, and when you accept, decline or answer tentatively on a meeting invitation your calendar cannot record directly, which is sent as an ICS reply and happens on Google rather than on Microsoft. One exception not started by you is the optional follow-up autopilot, off unless you switch it on: it can send a chase-up on a thread you are waiting on without you sending that message yourself. Separately, the Service's own mail also leaves from your address rather than ours: an invitation or a share you issue from inside the app, a note to a collaborator when shared work changes, and an alert to you when your mailbox connection breaks, which is sent without anyone acting. These are short service messages about your own work, addressed to you or to a recipient you named; an invitation goes to whatever address you type, which need not be someone you have corresponded with. We send no bulk or marketing mail from your account.
https://www.googleapis.com/auth/gmail.settings.basic
Why: read your existing Gmail signature once, so the in-app compose window can pre-fill it, and read your send-as addresses, which we store so that mail sent to a work alias is recognised as yours. We write one Gmail setting, and only when you block a sender: a single filter that sends that sender's future mail to Trash. We store the filter's id, so lifting the block removes it. We create, change or delete no other filter, and we never touch your vacation responder or your forwarding rules.
https://www.googleapis.com/auth/calendar.events
Why: read upcoming events so we can show meetings alongside the related emails, create or update events when you take a "Schedule meeting" action inside the app, and record your reply on an invitation when you accept, decline or answer tentatively. We also match a message against your calendar so that mail about a meeting or event which has already finished can be archived for you, which is one of the archives described under the mailbox write permission above.
4. Microsoft Graph scopes
When you connect a Microsoft (Outlook / Microsoft 365) account, we request only the scopes below.
User.Read
Why: read your name and email address, to create your account, and your other mailbox addresses (proxy and alternate addresses), which we store so that mail sent to one of them is recognised as yours.
offline_access
Why: keep the connection alive between sessions, so you are not re-prompted to sign in every hour. Revoking access in Microsoft Entra stops every renewal; an access token already issued keeps working until the expiry Microsoft stamped on it, which Microsoft sets rather than we do: commonly 60 to 90 minutes, and not a value we cap.
Mail.Read
Why: read messages and folders from your Outlook mailbox so we can display,
triage, prioritise, search, and summarise them. The Microsoft equivalent of gmail.readonly.
Mail.ReadWrite
Why: apply categories, move messages between folders, mark messages as read or unread, and move a message to Deleted Items, when you ask us to. We never delete a message outright and never empty Deleted Items: it stays there under your retention settings and you can take it back out. Nothing on a schedule ever moves anything to Deleted Items. Most writes come from an action you trigger in the UI. Archiving also happens without a further click from you: the message you have just replied to is archived; mail about a meeting or event is archived once that event has finished, at least an hour after it ends; a login code, magic link or password-reset mail is archived once it can no longer be used, after 15 minutes, an hour and a day respectively; and mail carrying a clear deadline is archived once the deadline has passed, never sooner than six hours after the mail arrived. If you switch on headless mode, which is off by default, we also write priority and category labels on your messages, refresh them nightly, and remove them once you have handled the message.
Mail.Send
Why: send replies and new messages that you compose inside the app, through your own Outlook account. Mail leaves your account when you send it, when you forward it (including handing a thread to a colleague, which forwards it at that moment), and when you unsubscribe from a sender whose only unsubscribe route is an email, which sends a short unsubscribe request from your address, and when you accept, decline or answer tentatively on a meeting invitation your calendar cannot record directly, which is sent as an ICS reply and happens on Google rather than on Microsoft. One exception not started by you is the optional follow-up autopilot, off unless you switch it on: it can send a chase-up on a thread you are waiting on without you sending that message yourself. Separately, the Service's own mail also leaves from your address rather than ours: an invitation or a share you issue from inside the app, a note to a collaborator when shared work changes, and an alert to you when your mailbox connection breaks, which is sent without anyone acting. These are short service messages about your own work, addressed to you or to a recipient you named; an invitation goes to whatever address you type, which need not be someone you have corresponded with. We send no bulk or marketing mail from your account.
Calendars.Read
Why: read upcoming events so we can show meetings alongside the related emails. We also match a message against your calendar so that mail about a meeting or event which has already finished can be archived for you, which is one of the archives described under the mailbox write permission above. Read only: we write nothing to your calendar under this permission.
Calendars.ReadWrite
Why: create or update calendar events when you take a "Schedule meeting" action inside the app, and record your reply on an invitation when you accept, decline or answer tentatively. Both are actions you take; nothing writes to your calendar on a schedule.
5. Limited Use commitment
5.1 Google API Services User Data Policy
Inbox by Pidgy's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
In concrete terms, this means:
- We use Google user data only to provide and improve user-facing features described in this policy.
- We do not transfer Google user data except as needed to provide those features, comply with applicable law, or as part of a merger / acquisition with continued protections.
- We do not use Google user data for advertising.
- We do not sell Google user data.
- No human at Alkmist reads your email, except (a) with your explicit consent, (b) for security or abuse investigation, (c) to comply with applicable law, or (d) for aggregated, anonymised, internal operations.
- We do not use your Google user data, including the contents of any email or attachment, to train or improve generalised or third-party AI/ML models.
5.2 Microsoft Graph data
The same commitments apply to data we receive through Microsoft Graph: we use it only to provide the features described in this policy, we do not sell it, we do not use it for advertising, no Alkmist human reads it outside the narrow exceptions above, and we do not use it to train AI/ML models.
6. How AI processes your email
Many features of the Service (triage, summarisation, suggested replies, priority scoring) use large language models (LLMs).
- No human review. Alkmist staff do not read your email content. Outputs from LLM calls are returned to you, not to a reviewer.
- No model training. Email content sent to an LLM provider is not used to train, fine-tune, or improve any AI model, ours or theirs.
- Today: OpenAI on the US endpoint. At the time of this policy, email content is processed by OpenAI on their US endpoint. Nothing sent there is used to train OpenAI models. Retention depends on how a request is sent, not on who asked for it, and we state both shapes. Most of what we send is an ordinary request: the prompt goes, the answer comes back, and nothing is retained. That covers every feature you trigger, and much of the background work too, thread summaries among it. Some background work is submitted through OpenAI's Batch API instead, for cost. Today that is analysis of newly arrived mail; the summaries we build of a correspondent relationship, whose prompts carry the subjects and summaries of up to twenty of that person's messages; and looking up an organisation from its domain and public website text, which is not mailbox content but is still your data. Read that as examples rather than a boundary: anything we add that runs in the background is likely to be submitted the same way. A batch uploads its prompts to our OpenAI account as a file, and the model's answers return as a second file we download. Neither file is currently deleted after the results are collected, so both the prompts and the answers remain in our OpenAI account until they are removed. See OpenAI's Enterprise Privacy commitments.
- Intended: EU-residency LLMs. We intend to move LLM processing to EU-residency providers, Mistral models and EU OpenAI deployments accessed via OpenRouter, so that email content no longer leaves the European Union for AI processing. That work has not started, so read this as an intention rather than a roadmap: there is no date, and nothing in the product routes anywhere but OpenAI today. We will update this policy and the subprocessor list when it ships.
7. Subprocessors
We use the following subprocessors. Each handles only the categories of data listed.
| Subprocessor | Purpose | Data handled | Region |
|---|---|---|---|
| Google Cloud Platform (GCP) | Primary database (Cloud SQL / PostgreSQL) and application hosting (Cloud Run) | All application data, including email content, metadata, and OAuth tokens | europe-west1 (Belgium) |
| Cloudflare | DNS, CDN, Web Application Firewall (WAF) | Request metadata (IP, user-agent, URL); HTTPS-terminated traffic | Global edge |
| Cloudflare R2 | Object storage for email attachments and message bodies | Email attachments and a copy of each message body (encrypted at rest) | EU as provisioned. Not yet evidenced: the jurisdiction is fixed at bucket creation and readable only off the storage endpoint, which we have not recorded against this bucket. Endpoint host available on request. |
| Upstash Redis | Background task queue and short-lived cache | Mostly queue metadata (job IDs, references). Some message-derived content passes through or is briefly held: a real-time notification carries a subject line or a short comment preview, and analysis results derived from a message may be cached for up to 24 hours. Nothing is retained as a durable store. | EU |
| OpenAI (today) | LLM processing for triage, summarisation, suggested replies; background analysis additionally via the Batch API | Email content sent in prompts, and non-mailbox material we analyse in the background such as an organisation's domain and public website text; outputs returned to you. Not used for training. Interactive prompts are not retained; batch uploads persist as files in our OpenAI account until removed. | United States |
| OpenRouter (planned) | Routing layer for EU-residency LLMs (Mistral and EU OpenAI deployments). Intended, not started: nothing is routed here today | Email content sent in prompts; not retained, not used for training | EU |
| Clearbit, Google and DuckDuckGo (logo lookup) | Finding a company's logo. We try the company's own website first; only when that yields nothing do we ask one of these three for an icon | The company's domain name only, taken from a correspondent's email address. No message content, no email addresses, nothing identifying you | United States |
| Amazon Web Services (SES) (not in use today) | Delivery of our own notification mail (assignment digests, portal verification, follow-up autopilot notices). Wired but not switched on: the credentials exist in no environment, so nothing is sent through it and no data reaches Amazon. Listed because enabling it is an operator action, not a product change | The recipient's address, which is yours for a digest or autopilot notice and a guest's for a portal verification, and the notification body. That body carries mailbox content: the autopilot notice quotes the subject line of the message being chased and the correspondent's address, and digests list task titles, which are often taken from an email | eu-west-1 (Ireland) |
| Stripe | Subscription billing and payments | Billing data (name, email, payment details): no email content. We receive only a customer ID and subscription status. | EU + US (Stripe global) |
| PostHog (EU instance) | Product analytics and session replay | Pages visited, features used, errors. No email content: email body, subject, and addresses are masked in session replays. | EU |
A current list of subprocessors is maintained in this section. We will update this policy if we add or remove subprocessors.
8. Where your data is stored
Your application data, including email content, metadata, OAuth tokens, and account profile, is stored on Google Cloud Platform in the europe-west1 region (Belgium). Backups remain in the same region.
LLM processing routes email content to the United States (OpenAI). We intend to move to EU-residency LLM providers (Mistral and EU OpenAI deployments via OpenRouter), after which all LLM processing of email content would stay in the European Union. That work has not started. There is no date and no partial rollout: every LLM call in the product goes to OpenAI today. We will update this policy when it ships.
9. Retention
- Email content (headers, body, attachments): retained for as long as your subscription is active, so that search and archival keep working across your entire mailbox history.
- OAuth tokens: retained while your subscription is active and you have at least one provider connected. Removed when you disconnect a provider or delete your account.
- Account deletion: we keep the account recoverable for 30 days, then begin the erasure. That is a window before the work starts, not a deadline for it to finish, and we do not state how long it takes. The erasure of your records in our primary database is a single transaction. The steps after it (deleting stored files, removing you from our analytics provider, revoking our access to your mailbox where the provider allows it, and tearing down the archive mailbox) run afterwards, and not all of them are retried automatically if one fails. Where yours was the last account in a workspace, the workspace record itself is not removed in that transaction: it is stripped of anything that identifies it and then deleted separately, on a schedule, so an emptied workspace shell can outlive your account by up to that interval. Where a mail-archive backend holds archived copies of your messages, see the note in section 11.
- Backups: automated database backups are taken on a rolling schedule and cannot be edited selectively, so an individual account's data cannot be removed from a backup that already exists. It leaves our systems when that backup ages out of the retention window, which is therefore after, not within, the erasure described above.
- Billing records: retained for the period required by Belgian and EU tax law (typically 7 years) to comply with our accounting obligations.
10. Encryption
- In transit: all traffic between you, our servers, and our subprocessors is encrypted with TLS 1.2 or higher.
- At rest: the database disks (Cloud SQL) are encrypted using GCP-managed encryption keys.
- Application-level encryption of OAuth tokens: Google and Microsoft OAuth tokens are additionally encrypted at the application layer using Fernet (AES-128-CBC with HMAC-SHA256), so that anyone with raw database access still cannot impersonate your provider session.
- Application-level encryption of email content: we are rolling out application-level encryption for email subject, snippet, and body in addition to disk encryption. This is in deployment at the time of writing and will be the default for new and re-synced data.
11. Your controls
- Revoke Google access: myaccount.google.com/permissions. Removing Inbox by Pidgy invalidates our access tokens immediately.
- Revoke Microsoft access: myaccount.microsoft.com/consent.
- Export your data: contact legal@alkmist.com and we will provide a machine-readable export.
- Delete your account: you can do this yourself, from Settings → Account. Because the deletion cannot be undone, we ask you to sign in again with your email provider and to type your account's email address before it proceeds. Your data is then erased in the background rather than at the moment you confirm — see Retention for what that does and what it does not promise. The account record itself is kept for up to 30 days so that you can sign back in and start again, and is removed after that. Signing back in does not restore anything — it gives you a new, empty workspace. Deleting your account also releases your email address, so if someone else registers it in the meantime we cannot restore your account. If you signed up with a password rather than with Google or Microsoft, email legal@alkmist.com and we will carry the deletion out for you.
- What account deletion does not yet cover: where your mailbox is served by a mail-archive backend, deleting your account decommissions that mailbox but does not by itself erase the messages the backend has already archived. A separate process to erase archived message content has entered service and is being validated; until we describe it as an established capability, that decommissioning is what account deletion performs upstream. If you need the archived copies erased as well, email legal@alkmist.com and we will carry it out.
- Remote images are blocked by default: when we render an email, remote images (including senders' open-tracking pixels) are not loaded, so opening a message sends no request (and therefore no read receipt, IP address, or read time) to the sender's trackers. You can load a message's images on demand with the Load images control shown on the message.
12. GDPR rights
If you are in the European Economic Area, the United Kingdom, or Switzerland, you have the following rights with respect to your personal data:
- Access: a copy of the personal data we hold about you.
- Rectification: correction of inaccurate or incomplete data.
- Erasure: deletion of your data, subject to our legal retention obligations. You can start this yourself from Settings → Account. Read the note in section 11 on what account deletion does not yet cover — where a mail-archive backend holds copies of your messages, those are erased on request rather than automatically.
- Portability: your data in a structured, machine-readable format.
- Objection: to processing based on legitimate interests.
- Restriction: temporary halt of certain processing activities.
- Withdraw consent: for any processing based on consent, at any time.
To exercise any of these rights, email legal@alkmist.com. This is also the contact for Data Subject Access Requests (DSARs) and serves as our data-protection contact. Alkmist has not formally designated a Data Protection Officer under GDPR Article 37, as our processing activities do not meet the mandatory DPO criteria; the contact above fulfils the equivalent function. You also have the right to lodge a complaint with your local data protection authority, in Belgium, the Data Protection Authority.
13. Children's data
The Service is not directed to anyone under 18, and we do not knowingly collect personal data from children. If you believe a child has provided us with personal data, contact legal@alkmist.com and we will delete it.
14. Changes to this policy
We may update this Privacy Policy as the Service evolves. We will update the "Last updated" date at the top of this page, and for material changes we will notify you by email and / or by an in-app notice before the change takes effect.
15. Data Processing Agreement
A Data Processing Agreement (DPA) covering Article 28 GDPR is available on request. Email legal@alkmist.com and we will share our standard DPA.
16. Contact
Alkmist
Ravensteinstraat 2 bus 3, 9000 Gent, Belgium
Company / VAT: BE 1026.308.203
Privacy / legal: legal@alkmist.com
User support: support@alkmist.com
OAuth verification: oauth-verification@alkmist.com