Privacy Policy

It covers the Sendr website, the application behind your account, and the sending service that delivers email on your behalf. It does not cover Gmail or Google Account behaviour, which are governed by Google's own privacy policy, and it does not cover the institutions and professors you write to.

Sendr is provided as a tool for students preparing academic outreach. It is not a scholarship agency, a consultancy, or an admissions intermediary, and it does not act as an agent for any university.

Nothing about you is collected by hidden means. Each item below exists because a feature you used needs it:

• Account and connection. When you connect Gmail through Google's sign-in, Sendr stores the address of that account and a stable Google account identifier, plus the access and refresh tokens that keep the connection alive. Your Gmail password is never entered into Sendr and never reaches our servers.
• Each email you ask us to send. The recipient addresses in the To, Cc and Bcc fields, the subject, the rendered body, the delivery status, the number of attempts, the provider message id and any failure reason.
• Documents you attach. The file name, content type, size and the file itself, held temporarily so a queued message can be delivered with its attachments.
• Plan and usage records. Which plan you are on, when paid access started and ends, and a per-day count of sending attempts, so a daily allowance can be enforced rather than assumed.
• Payment review records. For a manual bank or wallet transfer: the sender name and phone number you type, the transaction reference, an optional payment date, your notes, and the payment screenshot image you upload.
• Operational logs. A request identifier, which account made the request, the endpoint, the response status and how long it took.

• Your replies. Answers from professors arrive in your Gmail inbox and stay there. Sendr has no permission to read them, so it cannot see, store or summarize a response.
• Your whole contact list. Contacts, groups, templates, variables and drafts are kept in your own browser. Only the single message being sent is handed to the server, one recipient at a time.
• Mailbox credentials. Gmail passwords, session codes and recovery details are never submitted to Sendr.
• Tracking data. This application does not load third-party analytics, advertising pixels, social trackers or cross-site scripts, and it does not place advertising or profiling cookies.
• Device fingerprinting. There is no invisible identifier built from your browser or hardware beyond the ordinary request metadata in the logs described above.

Sendr is deliberately split. Your working library — contact lists, groups, tags, templates, drafts and the campaign you are assembling — is written to your browser's own storage (IndexedDB) and to in-app state, so it belongs to your device. The service holds the parts that must survive your browser being closed: the mailbox authorization, the queue of messages to deliver, delivery results, attachments in flight, plan and usage records, and payment evidence.

Server-side records live in the PostgreSQL database our hosting arrangement uses. Gmail tokens are encrypted with an AES-256-GCM key before they are written, so the database never contains a usable token in plain text, and encrypted values cannot be decrypted without the server's separate key.

Connecting is what turns an anonymous visitor into an account: Sendr identifies you by the Google account whose mailbox sends the email, so reconnecting the same mailbox returns you to the same records, plan and usage counters.

Disconnecting from Settings, in the email section, deletes the stored authorization for your account. Delivered-message records and usage counters are kept, because they are what makes your History screen and your remaining daily allowance accurate; ask us through the Help page if you want those removed too.

For every email the service is asked to deliver, it keeps one record: the single recipient, the subject and body as they were rendered, the status (queued, sending, sent, failed, skipped or cancelled), how many attempts were made, the message id returned by Gmail, and the error text when something went wrong.

That record is what lets the History and campaign screens report facts instead of guesses — and it is what allows a retry to avoid sending a professor the same email twice. It is not read for marketing, not sold, and not used to train a model.

Attachment files are uploaded to the service because a queued message may be delivered long after the browser that created it has been closed. Each file is checked against the server's own limits for type, size, total size and count before it is accepted, and it is stored with the campaign it belongs to.

Attachment storage is temporary by design. An upload that never becomes a send is deleted after a retention window measured in hours, and removing a campaign releases the files it carried. Attachments are not scanned, indexed or retained beyond that.

Sendr sets two cookies, both httpOnly — meaning neither is readable by scripts running in your browser:

• Session cookie. An opaque, signed identifier for your own account, with a thirty-day lifetime. It is what keeps you signed in, and it carries no personal details of its own.
• Gmail connection cookie. Written when you start the Google sign-in flow and cleared when it finishes. It lives for ten minutes and exists so the callback can only complete in the browser that began the connection — it is a safety check, not a tracker.

These cookies are the service's authentication mechanism. Blocking or clearing them signs you out; there are no advertising or profiling cookies to opt out of, because there are no advertisers.

Paid access is granted after a manual transfer to the account details shown in the app, so Sendr never sees or stores card numbers, bank login credentials or wallet passwords. What it does keep is the evidence you submit for review: sender name, phone number, transaction reference, an optional payment date, your notes, and the screenshot you upload.

A payment submission is reviewed by an administrator, who approves or rejects it with a reason. Administrative changes to payment settings, plans and subscription status are written to an audit log, so a decision can be traced to whoever made it. Uploading a screenshot never activates access by itself.

• to deliver the emails you queue, one recipient at a time, at the pacing you set;
• to enforce the daily allowance attached to your plan, counted on the server before a message is handed to Gmail;
• to show you truthful campaign progress, history, failures and retry options;
• to verify a payment you submitted and to grant or refuse paid access;
• to keep accounts separated, detect misuse, and rate-limit abusive request volume;
• to diagnose a failure you report to us, using the request identifier from the logs.

Sendr does not sell your data, rent it, or trade it with advertisers.

• Google. Gmail processes and delivers the messages you send from your own mailbox under Google's terms.
• Our infrastructure providers. The hosting and managed database services that keep the application running.
• The administrator of this Sendr deployment. Someone with admin access can review payment submissions, subscription status and plan settings. Admin sign-in is separate from ordinary accounts, passwords are stored only as bcrypt hashes, and configuration changes are logged.
• Your recipients. The professors and institutions you send to receive your message, your address and anything you attach.
• Legal requests. If a valid order compels disclosure, we may have to provide it.

There is one blanket rule: nothing is retained because it was convenient to capture.

• Gmail authorization — until you disconnect it, or the connection is revoked at Google.
• Message and delivery records — while your account and its campaigns exist; deleting a campaign removes its queue and releases its attachments.
• Attachments — temporarily. An upload that never becomes a send is removed after the retention window (a few hours), and a campaign's files go with the campaign.
• Daily usage counters — kept per calendar day, because an allowance that can be reset or backdated is not an allowance.
• Payment submissions and screenshots — as financial evidence for the transaction they describe, including rejected ones.
• Browser-resident data — until you delete it in the app, or clear your browser's site data. We cannot remove what never left your device.

You can do most of this yourself, right now: disconnect Gmail, delete campaigns, remove contacts, groups, templates and drafts, or clear your browser's stored site data to wipe the local library.

For server-side records you can ask us to confirm what is held about your account, provide a copy, correct it, or delete it — including a message record you no longer want kept. Requests are made through the Help page in the app, and we answer within thirty days. Where the law allows us to refuse — for example a payment record needed to resolve a dispute — we tell you why. Deleting the connection and the records tied to an account has no self-service button yet, so ask us and we will do it.

If you live in a region with a data protection authority, you can complain to them. We are a small service: the fastest route to a fix is almost always the Help page.

• Gmail tokens encrypted at rest with AES-256-GCM, keyed separately from the database;
• httpOnly, signed session cookies with SameSite restrictions, and production startup that refuses to run on development fallback secrets;
• admin passwords stored only as bcrypt hashes, with admin sessions kept separate from user sessions;
• every request scoped on the server to the account the session belongs to — a user id supplied by a browser is never trusted;
• rate limits on the API and origin checks on cross-site requests;
• logs that record request outcomes rather than message content.

Production traffic is expected to run over HTTPS, which is what makes the secure cookie flags work. No system is perfectly secure. If you believe something here has failed, tell us through the Help page and we will investigate.

When you import contact lists you bring other people's personal data into the tool. You are responsible for having a legitimate reason to contact them, for the content you send, and for honouring their wishes — including removing anyone who asks you not to write again. The recipient addresses and message text you submit are processed only to deliver that message.

Sendr is built for students arranging their own outreach and is not directed at children under 16. If we learn that an account belongs to a child under that age, we disconnect the mailbox authorization and remove the account's server-side records.

Academic outreach is international by nature: your mailbox, our hosting, and your recipient's mail server may each be in a different country. Sending a message necessarily transfers its content to the recipient's infrastructure, and the servers that run Sendr may be located outside the country you live in.

This page is the policy of record, dated at the top (22 October 2026). If it changes in a way that affects what is collected or who it is shared with, we update the date here and point it out in the app rather than expecting you to re-read this page.