Data Processing Addendum

Effective 4 September 2026 · Last updated 14 October 2026 · Version 1.3

This addendum (“DPA”) governs our processing of personal data on your behalf under Article 28 of the GDPR. It is incorporated into the Terms of Service and applies automatically as soon as you use the API to capture pages containing personal data. You do not need to sign it or ask for it — but if your procurement process needs a countersigned PDF, email us and you will get one with no negotiation, because this is the only version we offer.

1. Who is who

• You are the controller for personal data contained in the pages you ask us to render and in the URLs you submit. You decide which pages are captured and why.
• We are your processor for that data. Caio Ricciuti, sole operator of screenshot-api.net, established in Spain, is the processor.
• We are an independent controller for your own account data — your email address, plan, keys, usage and billing records. That processing is described in the Privacy Policy and is not covered by this DPA.

2. Instructions

• We process personal data only on your documented instructions. Your API requests are those instructions: the URL you submit and the rendering options you set. This DPA and the Terms are the rest of them.
• We will not use the data for our own purposes, will not sell it, will not use it to train models, and will not disclose it to anyone except the subprocessors in Annex III.
• If we are required by EU or member-state law to process it otherwise, we will tell you before doing so unless that law forbids the notice.
• If we believe an instruction breaches data protection law, we will tell you and may pause that processing.

3. Confidentiality

The service is operated by one person, who is bound by confidentiality and is the only human with access to production systems. There are no employees, contractors or support staff with access to your data. Access to the server is key-only over SSH, and there is no shared or standing third-party access.

4. Security

We implement appropriate technical and organisational measures under Article 32, described in Annex II. The architectural point worth stating up front: for a plain capture, the rendered image and the full URL are never persisted, so most of the personal data we process for you exists only in memory, for the seconds a request takes, and cannot be recovered from our systems afterwards. The exceptions are the features whose purpose is to keep something — baselines, delivered images and snapshot sets — which you choose to use, control, and can delete; their retention is in Annex I.

5. Subprocessors

• You give us general authorisation to engage the subprocessors listed in Annex III.
• We will update that list before engaging a new one and will notify account holders by email at least 30 days in advance.
• If you object on reasonable data protection grounds, tell us within those 30 days. If we cannot resolve it, you may terminate the affected subscription and we will refund the unused part of the current period.
• Every subprocessor is bound by written terms no less protective than these, and we remain liable to you for their performance.

6. Data subject requests

If someone exercises a right against you — access, erasure, objection — in relation to data processed through this service, we will help you respond, taking into account the nature of the processing. In practice there is usually very little for us to do: unless you use baselines, delivered images or snapshot sets, we hold no images and no full URLs, so there is normally nothing of that person’s to retrieve, correct or erase. Where you do use them, you can delete the data yourself through the API or the dashboard, and we will do it for you on request. If a data subject contacts us directly about data we process for you, we will not respond substantively and will refer them to you, telling you promptly.

7. Breaches and assistance

• We will notify you without undue delay, and in any event within 72 hours, of becoming aware of a personal data breach affecting data we process for you, with the nature of the breach, the likely consequences, and the measures taken.
• We will provide reasonable assistance with your obligations under Articles 32 to 36, including data protection impact assessments and prior consultation, given the information available to us.
• Notice goes to the email address on your account. Keep it current.

8. Deletion and return

Plain captures leave nothing to return. Baselines and snapshot sets can be retrieved through the API before termination. On termination we delete the account data that remains — email, key digests, usage counters, the hostname-level render log, baselines, delivered images, snapshot sets with their options and run history, and any Slack connection — within 30 days, except where EU or member-state law requires us to keep it, which in practice means billing records kept for tax purposes. Backups roll off within 14 days and are not restored selectively.

9. Audits

We will make available the information needed to demonstrate compliance with Article 28 and will respond to reasonable written questionnaires, once per year and on 30 days’ notice. Given that this is a single-operator service running on a single server, we do not host on-site audits or provide third-party certifications; where you have a regulatory obligation that requires more, contact us before you build on the service so we can agree what is workable.

10. International transfers

Processing takes place on infrastructure in Finland; the processor is established in Spain. The transfers described in Annex III are covered by the European Commission’s Standard Contractual Clauses, module two (controller to processor) or module three (processor to processor) as applicable, which are incorporated by reference. The docking clause applies, and Annexes I to III of this DPA populate the corresponding annexes of those clauses. Personal data contained in captured pages is not transferred outside the EEA by us, except on your instruction: if you connect Slack, the messages you configure — page URLs, change summaries and links to delivered images — are posted to your Slack workspace.

11. Liability and precedence

The limitation of liability in the Terms of Service applies to this DPA and to claims arising under it, to the extent the law allows. Where this DPA conflicts with the Terms, this DPA wins for matters of personal data processing; where it conflicts with the Standard Contractual Clauses, the Clauses win.

Annex I — Details of processing

Annex II — Technical and organisational measures

• Data minimisation by design. Plain captures are streamed to the caller and never written to disk or to a database, and the render log keeps only the target hostname. Images and full URLs are stored only by the features built to keep them — baselines, delivered images and snapshot sets — and only for the periods in Annex I. The web server access log records request lines as sent; a controller who wants target URLs and keys out of it sends them in a POST body and the Authorization header, which is never logged.
• Isolation between renders. Each capture runs in a fresh browser context that is destroyed afterwards, so cookies, local storage and cache cannot cross between customers.
• Encryption in transit. TLS on every public endpoint, HTTP redirected, HSTS set, modern ciphers only.
• Credential hygiene. API keys, sign-in links and session tokens are stored only as SHA-256 digests. There are no password hashes because there are no passwords. Target-site credentials given to a snapshot set, and a connected Slack webhook address, must be sent again, so they are stored encrypted with AES-256-GCM under a key held outside the database; they are deleted with the set, the integration or the account.
• Request validation. Submitted URLs, and every redirect and subresource a page then requests, are checked against loopback, private, link-local, CGNAT and reserved ranges before the browser may fetch them.
• Egress filtering. The renderer container’s outbound network access is filtered independently of that validation, so a DNS rebinding attempt that defeats one layer still meets the other.
• Least privilege. Application containers run as unprivileged users. The renderer container drops every kernel capability, has a read-only root filesystem and process and CPU limits, and runs the browser with its sandbox enabled, so each page is rendered in a process confined to its own namespaces under a system-call filter. No service other than SSH, HTTP and HTTPS is reachable from the internet; the host firewall is default-deny.
• Patching. Unattended security updates on the host; application images rebuilt from current bases on deploy; the browser image pinned to an exact version and updated deliberately after testing.
• Monitoring. Automated daily health reporting covering error rates, service state, certificate expiry, backup age and authentication failures; brute-force protection on SSH.
• Backups. Nightly, integrity-checked, retained 14 days, restricted to the operator, and restore-tested. Backups copy the database — account and billing metadata and, where those features are used, baseline URLs, snapshot-set URLs, options and credentials, and run history. They never contain images.
• Payment data. Handled entirely by Stripe; card numbers never reach our systems.
• Personnel. One operator, bound by confidentiality, using hardware-backed keys for administrative access.

Annex III — Subprocessors

Analytics is self-hosted on our own infrastructure and involves no third party. There is no CDN, no third-party error tracker, no session recorder and no support widget in the product.

Slack is not a subprocessor we engage. If you connect it, it is a destination you choose: the messages you configure — page URLs, change summaries and links to delivered images — are posted to your own workspace on your instruction, under your agreement with Slack.

Contact

Data protection questions, signed copies, and subprocessor objections: me@caioricciuti.com.