Data Processing

1. Roles

For your account data we act as a controller. For the URLs you submit and the screenshots we generate, you are the controller and PreviewAPI is your processor — we process that data only to provide the service.

2. What we process

Submitted URLs, capture settings, job metadata (status, timing, dimensions, size, errors), generated screenshot images, and request logs (endpoint, method, response code, latency).

3. Subprocessors

Our infrastructure provider (VPS hosting and storage), PayPal (payments), and Google and GitHub (sign-in — the only way to authenticate, so an account cannot be created without one of them). We will list any new subprocessor here before it handles customer data.

A capture is not fetched directly from our network. It is routed out through the Tor network, and retries may fall back to a pool of public proxy servers. The relay and exit operators this involves are volunteers and third parties we neither operate nor contract with, so they are not subprocessors and we cannot list them as such — but a capture in flight passes through them, and section 4 sets out what they can see.

4. Security measures

Public traffic to previewapi.dev and api.previewapi.dev arrives through a Cloudflare tunnel, which terminates TLS; the origin server is not exposed to the internet directly. Traffic between our own components on the private capture network is not encrypted — that hop carries the page being captured and the resulting image, and you should weigh it as such.

The egress hop leaves our control by design. Every capture is routed out through the Tor network — the proxy is mandatory and a capture fails rather than going out unproxied — and retries may fall back to a pool of public proxy servers. The leg between us and that network is encrypted, but the leg beyond it is the target's own: a page fetched over https:// stays encrypted to the origin, while a page fetched over http://, which the service accepts, is readable in full by the exit operator — a third party we do not operate, vet or contract with. Submitted URLs should therefore be treated as visible in transit, and should not carry credentials or session tokens.

API keys are stored as HMAC-SHA256 hashes under a server-side secret that is never in the database; the key itself is shown once at creation and never written down.

Stored images are not access-controlled. They are served from URLs containing a random unguessable token, and that token is the whole of the protection: image delivery carries no per-request authorisation and is not checked against the account that created the job. Anyone holding the URL can fetch the image for the 14-day retention window. Treat those URLs as secrets and pass them on accordingly.

Each capture runs in its own browser session on a capture host separate from the API, and that session is discarded when the job finishes. We make no representation here about backups, and none about access controls beyond this, because we are not in a position to evidence either.

5. Deletion

Deleting a screenshot deletes the image file. It does not delete the job record: the URL you submitted, the status, timing, dimensions and size are kept, with the row marked deleted. The same is true of the 14-day retention sweep. If the URL itself is the sensitive part, take that into account — deletion does not reach it.

Deleting an account removes its job records, screenshots, keys and credits. That is done by hand on request rather than by a self-service control; there is no account-deletion path in the product yet. Email [email protected].

6. Assistance

We will provide reasonable help with data subject requests, security questionnaires, and incident notifications — email [email protected].