Privacy policy
Last updated 13 August 2026
We hold two very different kinds of data: the account details of the developers who sign up, and the captures their end users create. This explains both, and who is responsible for which.
The short version
- Captures are rendered, annotated and redacted entirely in your end user’s browser. Nothing is uploaded until they confirm.
- A capture can contain anything that was on screen, which is why redaction runs before encoding — blurred regions are destroyed in the browser and the original pixels never reach us.
- We do not sell data, and we do not use captures to train anything.
- If you are our customer, you decide what gets captured. We only process it on your instructions.
Who is responsible for what
If you sign up for an account, you are our customer and we are the controller of your account data. When your application captures something from one of your users, you are the controller of that capture and we are your processor — we store it and deliver it where you tell us to, and nothing else. The data processing addendum sets out those terms.
This means the duty to tell your users what you capture, and to have a lawful basis for capturing it, sits with you. We give you the tools — redaction selectors, exclusion selectors, an explicit confirm step — but we cannot know what is on your screens.
What we collect from account holders
| What | Why | Kept for |
|---|---|---|
| Email address | Signing in, billing, service notices, and our product mailing list | Until you delete the account |
| Password | Signing in. Handled by Supabase Auth and never stored by us in a readable form | Until changed or the account is deleted |
| Organisation and project settings | Running your projects | Until you delete the account |
| API keys | Authenticating requests. Secret keys are stored only as a SHA-256 hash | Until revoked |
| Usage counts | Quotas and billing | 24 months, aggregated by day |
What we receive when a capture happens
Your SDK sends us the rendered files plus a small amount of context about where they came from:
| What | Why | Kept for |
|---|---|---|
| The rendered files | It is the product | Your project’s retention setting, or until deleted |
| Page URL, title and referrer | So you can tell captures apart in the dashboard | With the capture |
| Viewport size and user agent | Diagnosing rendering differences between browsers | With the capture |
| Your own params and caption | Passed straight back to you on the webhook | With the capture |
| Country, derived from IP | Abuse prevention. We do not store the IP itself | With the capture |
A capture is a picture of a screen. If that screen showed personal data, the capture contains personal data. Use redact and exclude, or set them project-wide in Settings, so the sensitive parts never survive the render.
Where it is stored
On Supabase infrastructure. Files live in a private bucket and are only reachable through signed URLs that expire — never later than the capture itself, which is deleted after three days by default. Signed URLs are unguessable but they are also unauthenticated, so treat one like a password: anybody you forward it to can open the file until it expires.
Database access is constrained by row-level security, so one organisation cannot read another’s rows even if application code has a bug.
Who else sees it
- Supabase — database, authentication and file storage. The only one that holds captures.
- Vercel — application hosting.
- Sentry — error tracking. Sees stack traces and request context when something fails, scrubbed of keys, tokens and signed URLs first. Never a capture.
- Brevo — account email and the mailing list. Sees email addresses and nothing else.
- Your own webhook endpoints — we send capture URLs wherever you configure. What happens after that is on your side.
The sub-processor page is the canonical list, with what each one can reach and where it processes.
We do not sell personal data, share it for advertising, or use captures to train machine-learning models.
Email we send you
Signing up puts your address on our contact list and sends you one welcome email. The list is used for occasional product mail — new features, changes that affect you — and never sold or shared. Every message has an unsubscribe link, and unsubscribing has no effect on your account.
Service email is separate and you cannot opt out of it while you have an account: sign-in links, password resets, invitations and notices about outages, security or billing. Those are the mechanics of having an account rather than marketing.
Your rights
Depending on where you live you may have the right to access, correct, export or delete your data, and to object to how we process it. You can delete captures yourself from the dashboard at any time; for anything else, email privacy@screen2api.com and we will respond within 30 days.
If one of your users asks us to delete something, we will point them at you — it is your data and your decision.
Retention
Captures are deleted three days after they are created. Set retention_days on a project to choose anything from one day to seven. Seven is the ceiling for every account and no plan raises it — a capture is a picture of somebody’s screen, and a window we can defend is worth more than one that flatters a pricing page.
The files, the capture record and any undelivered webhook events go together. Usage counts survive, aggregated by day, because that is what billing runs on.
If you need a capture for longer, copy it to your own storage when the webhook arrives. Deleting your account removes your organisation, projects, captures and stored files straight away rather than waiting for the three days to run out.
Changes
If we change this in a way that materially affects you, we will email account holders before it takes effect. The date at the top always reflects the current version.