1. What we collect, and why
Nothing here is collected for analytics or advertising. Every item exists because an application form asks for it, or because a run cannot be carried out without it.
| Group | What it holds |
|---|---|
| Account and identity | Your profile (name, phone, postal address, work authorization), your uploaded résumés and their extracted text, the address applications are sent from, your daily cap and relevance rules, and the masked mirror of your extension settings. |
| Mailbox access and classified mail | The Google refresh token that lets our servers read the verification codes employers email you, plus every job email we classified, its extracted deadlines, and your corrections to those classifications. |
| Applications and answers | Every application submitted for you and its outcome, the ATS accounts created in your name, the answers you gave to application questions, and the tailored résumés attached to each job. |
| Roles found for you | The daily scan of open roles matched to your profile, and the freshness statistics behind it. |
| People and outreach | People found at companies you applied to, referral asks queued or sent on your behalf, and the outreach drafts built from them. |
| Diagnostics and activity | Captured failure reports (which can include a screenshot and the HTML of a part-filled application page), your activity log, headline counters, manual page captures, and any pending CAPTCHA relay reply. |
| Run control | Queued start/stop commands for the server-side runners. |
This table is generated from the same catalogue the deletion code uses
(web/lib/account-core.js), so what is listed here is what is actually stored.
2. Applying in your name
Applications are submitted as you, not as us. They carry your name, your email address and your résumé, and they arrive in an employer's applicant-tracking system indistinguishable from one you typed yourself.
Two consequences worth stating before you sign up:
- An application we send cannot be recalled. Once it reaches the employer it is theirs, held under their retention policy, not ours.
- Where a form asks a question our automation cannot answer from facts you gave us, it is left for you rather than guessed. Questions about salary, visa or sponsorship status, citizenship, security clearances, criminal history and voluntary self-identification are never answered by a model — those are refused in code, on the server, because a plausible-sounding invented answer would be a false statement made in your name.
3. Your passwords and your mailbox
Some employers make you create an account on their careers site before you can apply. Where that happens we create one for you and store the password, because the next application at that employer needs it.
- Those passwords are encrypted at rest (AES-256-GCM) with a key held only in our server environment, never in our source code and never in the database alongside the data. The encryption is bound to your account, so a row copied out of your namespace cannot be opened.
- If you connect Gmail, we store a refresh token and use it for exactly one thing: reading the verification codes employers email you mid-application. We do not read, index or retain the rest of your mail.
- We will never email anyone on your behalf without you asking for that feature.
4a. Who at our end can see your data
This service is run by one person. That person controls the servers and holds the keys to the database, which means they can reach your résumé, your saved answers and your application history. We state this plainly rather than implying a separation that does not exist: a promise not to look, made by the same person who would have to enforce it, is not a control you could verify.
What we do instead is limit it by default and leave a trace:
- The operator’s own screens show metadata and outcomes — plan, status, counts, whether a run succeeded. They do not show your résumé or your answers.
- Administrative actions on an account (suspending, cancelling, changing a plan) are written to an append-only audit record with who did it and when.
- Nothing on our automated servers is able to delete your account. Only a signed-in person can do that — you, from your own account.
If we ever build support tooling that opens the contents of your application, it will require a deliberate action that is recorded in that same audit trail.
5. How long we keep it
While your account is active, indefinitely — the applied-history is what stops us applying to the same job twice, and the learned answers are what make later applications faster. When you delete your account, see below.
If you cancel and never explicitly delete, we keep your data for 90 days so you can come back to your history, and then delete it on the same path described below. You can delete it yourself at any point during those 90 days.
Backups. Deleting your account removes your records outright. A database backup snapshot taken before you deleted still holds a copy until that snapshot ages out. That window is no more than 30 days. Backups exist only so the service can be restored after a failure — we do not use a backup to bring back an account you deleted, and a snapshot containing your data is overwritten as backups rotate. This is the one part of “deleted” that cannot be immediate, so it is stated as a bound rather than left vague.
6. Deleting your account
You can delete your account at any time from your dashboard. The first thing deletion does is deregister you, which stops any further applications going out in your name; only then does it clear your data. If that first step fails, nothing is deleted and you are told so, because shredding the records of an account that is still running would be worse than doing nothing.
Deletion is honest about its own limits. Before you confirm it, you are shown a preview of what will be removed and what will not.
7. What deletion does not reach
Most services do not tell you this. These are the places your data can persist after you delete, and why.
- The empty row itself, and any database backup taken before you deleted. Our store offers no delete verb — only a whole-blob overwrite. Deleting replaces each of your rows with an empty payload, so the contents are gone but the row keeps existing, and a backup snapshot taken earlier still holds the old contents until it ages out of the backup window.
- Archived copies of individual applications whose job link we could no longer find. Each archived application, failure capture and page capture is stored under a key derived from a hash of its job URL, not under your name, and nothing keeps a complete list. We rebuild every key we can from your ledgers and indexes before clearing them, but a ledger that was trimmed to fit its size limit took those URLs with it.
- Data still on your own devices. The free Chrome extension keeps its own local copy of your profile, résumés and learned answers, and re-uploads them whenever it is signed in. Deleting here does not reach your browser — and if the extension is still installed and signed in, it will put some of that data back.
- Anything stored under a different sign-in address. Everything is keyed by the Google address you signed in with. If you used a second Google account at any point, that account holds its own separate set of rows and has to be deleted separately.
- Server logs. Our API logs each accepted write with the account address and the kind of data, and each runner writes a run log naming the employers it applied to. These rotate on the server and are not addressable per customer.
- Working files on the machine that ran your applications. A run stages files on disk — the résumé it uploaded, a report of what it submitted — under a per-customer directory. Deletion from here does not reach that filesystem.
- Anonymous form knowledge. When our automation works out how to operate a control on an employer's form, that fix is pooled across everyone. It records the shape of a form, never an answer, a name or any value you supplied, so there is nothing in it that identifies you — and it is not removed.
- Applications already sent to employers. An application submitted in your name now belongs to that employer, in their applicant-tracking system, under their retention policy. We cannot recall it, and deleting your account here does not withdraw it.
8. Your rights
You can export everything held about you, correct it from your dashboard, or delete it. We will not refuse a deletion request in order to keep billing you.
This service is offered in India only. We do not accept customers in the European Union or the UK, and do not target them. If you are in the EU or UK, please do not sign up — we have not built the GDPR obligations that would come with it, and we would rather say so plainly than claim a compliance we have not done.
Your rights under India's DPDP Act — to access, correct, and erase what we hold, and to withdraw consent — are honoured through your dashboard or by emailing us.
9. Contact
For a privacy question, a data request, or to report abuse of this service:
Email: [email protected]
Use it for a privacy question, a data export or deletion request, or to report abuse of this service. An employer or job board wanting activity from this service investigated or stopped should write to the same address — it reaches a person, not a queue.
Who is responsible for your data
Relax & Apply is operated by Aniruddh Laharia, an individual based in Bengaluru, Karnataka, India. Contact by email at the address above.
This document describes what the system actually does today, not what it intends to do. If you find a place where the two disagree, the code is the bug and we want to hear about it.