Privacy policy
This policy covers emailtimer.app, app.emailtimer.app, img.emailtimer.app, the /v1 API and any white-label image domain you point at us. In it, "we" means the operator of EmailTimer.App, and "you" means the person or company holding an EmailTimer.App account.
If you only read one section, read section 4. It is the part that is specific to this product.
- Last updated
- 23 September 2026
- Version
- 1.3
1. The short version
You give us an email address, a password and a card, and you upload templates, images, fonts and sometimes a list of your subscribers. We render images from that and count how often they are fetched.
We do not set cookies on your recipients, we do not build profiles of them, and we do not sell or share any of it. Per-request records are deleted after 30 days. Everything else is deleted when you delete it or when you close the account.
2. Who is responsible for what
For your own account data, we decide what is collected and we are responsible for it.
For anything about your subscribers, you decide and you are responsible for it. We process it on your instructions, which are the templates you publish, the lists you upload and the URLs you send. Under the GDPR you are the controller and we are the processor. Our data processing addendum is the contract for that, and it names every sub-processor.
3. What we hold about you
- Your account. Name, email address, and a hash of your password. We never hold the password itself.
- Google sign-in, if you use it. When you sign in with a Google account, Google tells us the name, email address and profile picture on that account and whether Google has verified the address. We store those, the account identifier Google gives us and the tokens it issues for the sign-in, instead of a password hash. Google, as the identity provider, sees that you are signing in to EmailTimer.App.
- Your organization and workspaces. Names, members, roles and invitations.
- Your content. Templates, published versions, uploaded images, uploaded fonts, Photoshop files you import, and the names you give all of it.
- Billing. Your plan, your billing country, the currency, invoices, and an identifier from the payment processor. Card numbers, UPI handles and bank details go straight to Stripe or Razorpay and never reach our servers or our database.
- Access. API keys, stored as a SHA-256 hash and a non-secret prefix, and sessions, held as opaque tokens for 14 days.
- An audit log. Sign-ins, publishes, key creation and revocation, membership changes, billing changes and operator impersonation, with the actor and the time.
- Support mail. Whatever you write to us, and our reply.
4. What reaches us about your recipients
4.1 Merge values in a signed image URL
An image URL can carry values of its own: a first name, a coupon code, a points balance, a per-recipient deadline. They get there only when you generate the URL with them in it through our API. An email platform cannot add them at send time, because the signature covers every parameter and a value filled in afterwards breaks it. The values arrive as query parameters, they are rendered into the pixels of the returned image, and the signature covers them so they cannot be altered in transit.
They are not written to a database, and our request logs record the image address with every such value replaced, so they are not written there either. They are in the URL itself, which means they are also in the HTML of the email you sent, in your platform's send logs, and in any cache between the recipient and us. If you would rather they were not, use recipient tokens (4.3).
4.2 The open request itself
When a recipient's email client fetches the image, the request reaches us the way any web request does, carrying an IP address and a user agent. In practice that address often belongs to Apple's or Google's image proxy rather than to the person.
We do not keep a row for each request. Every open is counted into daily totals per workspace, template and email client family, and the client family is read from the user agent, which is then discarded. Those totals are what your usage screen, your invoice and your quota warnings are based on, and they contain no identifier for any individual.
A row is written only when a request fails, or is answered without being counted towards your plan, so that we can find and fix what went wrong. It holds the time, the workspace, the template and its version, the kind of event, the email client family and a short reason. It holds no user agent string, no country, no recipient token and no IP address. Those rows live in daily partitions and the partitions are dropped after 30 days.
We do not store the IP address anywhere. The service uses it for one thing, a limit on how many requests one address can make, and that limit lives in memory. When a request is refused by it, the log line carries a short tag in place of the address, keyed with a random value that is never written down, so it cannot be turned back into the address.
4.3 Recipient lists you upload
If you upload a CSV of recipients, we store the rows: the email address if your file has one, your own identifier if it has one, every other column as merge data, and a per-recipient deadline if you set one. Each row also gets an opaque token, and that token is the only thing that travels in the image URL.
For speed, each row is also cached in Redis under its token. Deleting a recipient set deletes the rows immediately and queues a job that removes those cached copies, because a customer deleting a list is usually acting on somebody else's deletion request.
4.4 Evergreen timers
A timer that counts from each recipient's first open has to remember that first open. What we store is a SHA-256 hash of the image URL and the time we first saw it. It holds no name and no address, and it expires after the timer's own duration plus 30 days.
4.5 What we do not do
We do not set cookies on recipients. We do not track them across emails or websites, we do not build profiles, we do not enrich or resell anything, and we do not use your data or your recipients' data to train models.
6. How long we keep things
| What | How long |
|---|---|
| Per-request rows for image fetches | 30 days, dropped as whole daily partitions |
| Daily usage totals | While the workspace exists |
| Account, workspace and template records | While the account exists |
| Published template versions | While the account exists, because a delivered email may fetch one years later |
| Recipient rows from a CSV | Until you delete the set or the workspace |
| Cached recipient records in Redis | Two years, or immediately when you delete the set |
| Evergreen first-open markers | The timer's duration plus 30 days |
| Photoshop import source files and proof files | 14 days after an import is abandoned; the import report is kept while a template made from it still exists |
| Sessions | 14 days |
| Password reset links | 30 minutes |
| Email verification links | 60 minutes |
| Records of the emails we send you, which hold a hash of your address rather than the address | 90 days |
| Audit log | 420 days, or until the workspace is deleted if that is sooner. An entry cannot be changed or removed for its first 400 days. |
| Database backups | 30 days, so a deletion works its way out of the backups within 30 days |
7. Who else processes it
We use a small number of services, and no advertising network. Each one that handles your data or your recipients' data, what it does and what it sees, is listed in annex 2 of the data processing addendum. In summary: Cloudflare for the edge, storage, backups, the bot check and our outbound account mail; one virtual private server that runs the application, its Postgres database and Redis; Stripe for payments in dollars; Razorpay for payments in rupees; Google, as the identity provider, for anyone who signs in with a Google account.
Google Analytics is not in that annex. It runs on the marketing site only, and what it sees is a visit to a public page rather than anything about you or your recipients. Section 5 says what it sets.
We will email account owners at least 30 days before we add or replace any of them.
8. Where it is stored
The database and the cache run on one virtual private server. Published templates, uploaded images, fonts and database backups are objects in Cloudflare R2. Images are rendered on that server. Payment records live with Stripe and Razorpay.
Transfers out of the region where you are, and the mechanism for them, are covered in section 13 of the DPA.
9. Security
What we actually do, in enough detail to be checked, is on the security page, including what we do not have: there is no SOC 2 report and no ISO 27001 certificate.
10. Your rights
You can ask us to show you what we hold, correct it, export it, or delete it. Much of it you can do yourself from the dashboard: delete a template, delete an asset, delete a recipient set, revoke an API key, remove a member. Closing an account and erasing what is in it is done by email today rather than by a button in the dashboard.
Write to privacy@emailtimer.app for anything else. We reply within one business day and finish the work within 30 days. We verify a request against the email address on the account, and we do not charge for it. If you are unhappy with the outcome you can complain to your data protection regulator.
If one of your subscribers contacts us directly, we will tell them to contact you, because the data is yours and the instruction has to come from you. We will help you answer them.
11. India, under the DPDP Act 2023
Where the Digital Personal Data Protection Act 2023 applies, we are the Data Fiduciary for your account data and a Data Processor for the recipient data we handle on your instructions. You can withdraw consent, ask for correction or erasure, and nominate someone to exercise your rights if you cannot. Send any of that, and any grievance, to privacy@emailtimer.app. A grievance gets a substantive answer within 30 days. If it is not resolved you may approach the Data Protection Board of India.
12. California, under the CCPA
In the last 12 months we have collected the categories in sections 3 and 4: identifiers, commercial information, and internet activity in the form of image fetch records. We collect them to run the service, bill for it and support it.
We do not sell personal information and we do not share it for cross-context behavioural advertising. We have never done either, so there is nothing to opt out of. We do not use or disclose sensitive personal information beyond what is needed to provide the service.
You may ask what we collected, ask for a copy, ask us to correct it, or ask us to delete it, and we will not treat you differently for asking. An authorized agent may ask on your behalf with written permission. Same address: privacy@emailtimer.app.
13. Children
The service is for businesses. It is not for anyone under 16 and we do not knowingly collect their data.
14. Changes
If we change this policy in a way that affects you, we email account owners at least 30 days before it takes effect, and the version number and date at the top of this page change with it. Earlier versions are available on request.
15. Contact
Privacy and data protection: privacy@emailtimer.app. Everything else: support@emailtimer.app.
Change log
| Version | Date | What changed |
|---|---|---|
| 1.3 | Corrections, and one change to what we do. Section 4.2 said we kept one row per image request, holding the user agent string, the country and the recipient token. We never did: every open is counted only into daily totals, and a row is kept only for a request that fails or is not counted, without any of those three. It now says so, and says where the IP address goes and does not go. The change to what we do: our request logs used to record the full image address, merge values included, and now record it with every such value replaced, which section 4.1 says. The retention table said the audit log is kept while the workspace exists; it is kept for 420 days, and the table now says so. | |
| 1.2 | A change to what we do, not only to how it is described. The marketing site now runs Google Analytics 4, behind a bar that asks before anything is stored and offers Reject and Accept as the same button. Section 5 said the site set no cookies and ran no third-party analytics, which was true until this version; it now says what is asked, what the two cookies are for if you accept, how long they last, what happens if you refuse, and where to change the answer. Section 7 says why Google Analytics is not in the addendum's sub-processor annex. | |
| 1.1 | Corrections to what the policy described, with no change to what we do. Section 4.1 said the usual way to personalize an image was to let your email platform fill merge values into the image URL, which breaks the signature; it now says values reach a URL only when it is generated with them through the API. Google is named, for anyone who signs in with a Google account, along with what that sign-in gives us. Section 8 no longer says image requests are served close to where they arrived. | |
| 1.0 | The first version with a number and a full date. It replaced an undated draft. |