Privacy
This is a draft, not a published policy.
The tables below are generated from the software itself, so they accurately describe what the product does today. The parts that are legal decisions rather than facts — who the data controller is, the lawful basis, how long data is kept, and which law applies — are listed as unresolved at the bottom and must be completed with a qualified adviser before this is relied on.
What we collect about you, our customer
Data about the person who signs up and pays.
| What | Fields | Where it comes from | Why |
|---|---|---|---|
| Account |
| Entered by the customer at registration | To create and secure the account |
| Google sign-in |
| Google, if the customer chooses Sign in with Google | To authenticate without a password |
| Usage |
| Generated by using the product | To enforce the plan's daily allowance and let the customer audit their own API keys |
| Customer content |
| Entered by the customer | The product's core function |
What we collect about other people
This product finds business contacts. That means we hold information about people who never signed up and have no relationship with us — the owners and staff of the businesses our customers are looking for. We think that deserves to be stated plainly rather than buried.
| What | Fields | Where it comes from | Why |
|---|---|---|---|
| Business listing |
| Licensed business-data providers (DataForSEO, Google Places); the two rows below add lists our customers upload and contact details read from the business's website | To let a customer find businesses matching a trade and location |
| Lists uploaded by our customers |
| A CSV file the customer already holds (for example an export from another lead tool) and chooses to upload | So a customer can bring an existing export into the product and merge it with the businesses we already hold |
| Contact details published on a business's website |
| The business's own public website, read by our crawler | To give a customer a route to the business when the listing has none |
| Named individuals at those businesses |
| The business's own public website, read by our crawler | So a customer contacts the right person rather than a generic inbox — the product's core purpose |
| Generated email addresses |
| Derived by us from a person's name and their employer's domain — NOT published by that person | To provide a contact route where none is published |
| Website signals |
| Our crawler reading the business's public website | To score how well the business is served by its current provider |
| Raw provider payloads |
| The providers and the customer-uploaded lists listed above | Provenance — so any field can be traced back to the source that supplied it |
Email addresses we work out ourselves
Where a business publishes no address for a named person, we may infer one from how that company's other addresses are formed. Such an address was never published by that person. It is always labelled as a guess in the product and in exports, and it is never described as confirmed.
What "checking" an address means
- We check the format of the address.
- We ask public DNS whether the address's DOMAIN publishes a mail server. Only the domain is looked up, never the full address.
- We never connect to a mail server, and never send a message to test an address.
- Because of that, we can prove an address CANNOT work, but never that it does. Addresses are labelled accordingly and never described as verified.
What leaves our servers
| Where | What is sent | When |
|---|---|---|
| DataForSEO | The search terms and location a customer typed. No customer identity is sent. | When a search runs and the result is not already cached |
| Google Places | The search terms and location a customer typed. No customer identity is sent. | When a search runs and the result is not already cached |
| The business's own website | An ordinary HTTP request identifying our crawler. No customer or lead data is sent. | When a customer enriches a lead |
| Public DNS | The DOMAIN part of an email address only — never the full address. | When checking whether an address's domain can receive mail |
| Google (sign-in) | Only what the OAuth flow requires, and only if the customer uses it | At sign-in |
| Transactional email provider (SMTP) | The customer's email address, their name (only when their address is verified) and a single-use password-reset link, or a note that the account signs in with Google. No lead data. | When a customer asks to reset a password, once a mail provider is configured (SMTP_HOST). Until then nothing is sent: the same message, including the address and the reset link, is written to the server log instead |
Cookies
| Name | Purpose | Lifetime | Flags |
|---|---|---|---|
| emailclikfinder_session | Keeps the customer signed in. Strictly necessary — the product cannot work without it. | 7 days | httpOnly, sameSite=lax, secure in production |
| emailclikfinder_oauth | Protects the Google sign-in handshake (state, nonce and PKCE verifier). Strictly necessary for Sign in with Google; set only when a customer starts it. | 10 minutes, and deleted when sign-in completes or fails | httpOnly, sameSite=lax, secure in production |
We set no analytics, advertising or third-party tracking cookies. The only cookies are the two above, and both exist only to sign a customer in.
How long we keep things
- A cached provider response stops being used after 7 days (DataForSEO) or 24 hours (Google Places) (src/providers/registry.ts). It is not deleted then: it stays stored until the same search runs again and replaces it, or an erasure request removes it.
- Nothing is deleted automatically. Lead records, crawl results and raw provider payloads are kept until they are removed by an erasure request run by us. Customers can delete their own lists, saved searches, API keys and do-not-contact entries, but cannot currently delete lead records, crawl results or uploaded data themselves.
How it is protected
- Passwords are hashed with scrypt and a per-user random salt; the plain text is never stored.
- API keys are stored only as a SHA-256 hash. The key itself is shown once at creation and cannot be retrieved afterwards.
- Session cookies are httpOnly and sameSite=lax, and are marked secure in production.
- Every query for customer data is scoped to that customer's organization.
- Requests are rate limited per signed-in principal. Sign-in is also limited per account and by an overall ceiling, and — when deployed behind a configured proxy — by source address; registration and password reset likewise (the reset email also per address).
- Password-reset links are single-use and expire after 30 minutes; only a hash of the link is stored, and completing a reset signs the account out everywhere.
- Sign-in, registration and sign-out reject requests that originate from another website.
If you are in our data and want out
If you are a business owner and your details are in this product, you can ask for them to be removed. Our customers also maintain their own do-not-contact lists. A contact route for erasure requests is one of the unresolved items below and must be published before launch.
Still to be decided
These are judgements, not facts about the code, so they are listed honestly rather than guessed at:
- Controller identity: The legal entity, trading address and contact for privacy requests.
- Governing law: Which jurisdiction's law applies, and where disputes are heard.
- Lawful basis: The basis relied on for processing third-party business-contact data, per market.
- Retention periods: How long leads, raw provider payloads, crawl results, cached provider responses and closed CRM records are kept. Nothing is deleted automatically today: a cached provider response stops being used when it expires, but stays stored.
- Generated addresses: Whether to keep inferring email addresses for named individuals, and in which markets. This is the product's differentiator and its most disclosure-sensitive behaviour.
- Sub-processors: The final list, once hosting, email and billing providers are chosen.