NanoScraper · privacy
Privacy — what we collect, and what we do with it.
NanoScraper is run by one operator on one server. This is the personal data that actually passes through it — from the access-request form, from an account, from the records a customer collects, and from the logs.
Last reviewed 20 August 2026.
The access-request form
There is no self-service registration, so the access-request form is the only way in. Submitting it stores four things you typed and the time they arrived. Nothing else about the visit is recorded.
- Your name
- So a reply is addressed to a person.
- The only way the operator has to answer you.
- Organisation
- Optional. Stored empty if you leave it empty.
- What you would collect
- The message field. It is what the decision is actually made on.
- When it arrived
- A timestamp, set by the server.
The operator can also mark a request handled and attach a private note to it. Those two are written here rather than by you, and a copy of what is held includes them.
The operator reads these to decide whether to provision an account, and to write back. The four submitted fields cannot be edited afterwards, so the stored row stays the record of what was received.
It is used to answer your request and for nothing else. It is not sold, rented, or handed to anyone. There is no advertising here and nothing to share it with.
The application cannot send email at all — there is no mail configuration in it. A reply is therefore a person writing to the address you gave, from their own mail client, or there is no reply.
If an account is provisioned
Accounts are created by hand. One holds an email address, optionally a first and last name, whether it is active, when it was created and when it last signed in. There is no profile, no upload, and no third-party sign-in.
Sign-in credentials are stored as a one-way hash and never in readable form. Nobody, the operator included, can read yours back out.
Signing in sets a session cookie. It is marked secure, is not readable by page scripts, and identifies the session and nothing more. It belongs to the signed-in application; these public pages never set it.
The records a customer collects
The product collects business information from the public web and turns it into company records — a name, a domain, a website, a description and the like. Every stored value stays linked to the observation that produced it.
It also stores contact records. A contact can carry a full name, an email address and a phone number, so it can hold personal data about a person at a business — even though the business is what was being looked for.
Those records belong to the customer's workspace and are reachable only inside it. NanoScraper does not use them for anything of its own: no shared pool, no aggregate product, no resale.
The customer chooses what to collect, and having a lawful basis for collecting it is the customer's responsibility. That is a rule the connectors are held to, not a sentence written for this page — see /docs/data.
What the logs record
The application writes one structured line per request: method, path, status code, how long it took, and a correlation id that follows the work into background tasks. A signed-in request also carries the account and workspace ids.
Request bodies are not logged. Values under keys that look like credentials are replaced before a line is written, and that happens in the one formatter every record passes through rather than at each place something is logged.
Health probes and static assets are not logged at all. A correlation id sent by a caller is accepted only if it is a UUID; anything else is discarded and a fresh one minted, so an inbound header cannot write into the logs.
No retention period is defined for them. They are one server's container output, and naming a number here would be inventing a policy the system does not implement.
What this site does not do
These are properties of how the site is built, not preferences that a setting could change.
- Analytics
- None. No tag, no product analytics, no session recording, no heatmap.
- Third-party origins
- None. No font host, no CDN, no embedded widget. Every asset is served from here.
- Cookies on these pages
- None are set. The public pages read no session and render the same for everyone.
- Payment
- None is taken anywhere, so no card or billing record exists to hold.
- Email from the application
- There is none. No confirmation, no notification, no marketing message.
Asking about your data
The access-request form is the only first-party contact channel that exists, so it doubles as the route for a privacy question — a copy of what is held, a correction, or a deletion. Say which one you mean in the message field.
The operator handles these by hand and can remove stored rows and records directly. There is no automated deletion control, and an access request is not something you can retrieve for yourself.
What this page does not say
No legal entity, registered address, governing law or data-protection officer is named, because none has been settled. No response time is promised either. Those gaps are stated rather than filled with something plausible.
There has been no external audit and no certification of any kind. What has actually been executed is on /docs/verification, and the terms of use are on /terms.