Last updated: 2026-10-24 Version: 2026-10-24-draft עברית

Privacy policy

This policy explains what personal and business data Hotlead collects, why, who it is shared with, how long it is kept, and how to ask us about it. It describes what the product does.

1. Who we are

Hotlead is a pay-per-conversion advertising marketplace. Providers are owners of websites with advertising space: they give banner spots on their website (“ad spaces”) to Hotlead and install the Hotlead site script there. Clients (advertisers) upload banners, which Hotlead shows in matching ad spaces; a visitor who clicks a banner is the client's lead, and the client pays only when that lead becomes a sale. Clients connect their own CRM, payment, invoicing or store systems so that Hotlead can attach a click or a lead reference to a record in that system and detect when a sale happens. Some providers also send leads through our API. Hotlead also runs its own lead generation (“Hotlead Direct”) and launches ad campaigns and landing pages for clients.

The service is provided by [LEGAL ENTITY NAME], company number [COMPANY NUMBER], registered address [REGISTERED ADDRESS] (“Hotlead”, “we”, “us”). This policy covers our website at https://hotlead-app.netlify.app, the client and provider portal, our API, the site script and the banners it shows on providers' websites, the forms and click links we host, and the connections to third-party systems and websites.

Our role differs by data: for the account data of clients and providers we decide why and how it is used. For data about people who visit a provider's website where our banners are shown, click a banner, respond to an advertisement or fill in a form on a page we host, our role is: [HOTLEAD ROLE FOR LEAD DATA].

Applicable privacy law: [APPLICABLE PRIVACY LAW].

2. What we collect

2.1 Clients and providers (accounts)

• Account details: email address, company or provider name, a password (stored only as a one-way hash), a notification email if you set one, and, for clients, the industry (vertical) you choose at sign-up, and an optional budget.
• Provider websites: the website's address, what it is about and its audience (fields, countries and language), the approximate number of monthly visitors (a range you choose, optional), the percentage of each sale you want to receive and your range, and your rules (fields you exclude, clients you block, whether new clients wait for your approval). For each website we also keep what our scan and the site script found: the platform it is built on, whether Google Tag Manager is on it and the container identifier, whether and when the script was first and last seen on it, and the result of the last scan.
• Ad spaces: for each ad space, its name, size, the page it is on, the position of the element on that page (a CSS selector, from the scan or from your marks), the address of the image that was in that spot when it was scanned or marked, its status, and the banners currently shown there. We keep only a hash of a one-time marking link.
• One-button installs: where you ask us to install the site script, the access you grant for it (a WordPress application password, a Google Tag Manager access grant, or our Wix or Shopify app installation) and the identifiers of the site, account or container it applies to. We store such grants encrypted, like other credentials (section 8).
• Client banners: the banner images you upload and their sizes, their alt text, the destination you choose (your own website's address, or a Hotlead form), your targeting (fields and countries), the percentage of each sale you will pay and your range, and whether you approve matches automatically.
• Acceptance of our terms: when you create an account yourself, you tick a box to accept the Terms of service and this Privacy policy. We record which version you accepted and when. Accounts our staff create for you carry no such record.
• Access keys: API keys are stored only as hashes. Your account's API key is shown to you once, when it is created or replaced, and is never sent by email; afterwards the portal shows only its first characters. Replacing a key needs your password; the old key keeps working for a short grace period (by default 24 hours) that you can end at once. We keep a record of each replacement (account, time, who did it and the first characters of the keys, never a key itself) and email you a notice without the key. Signing in to the portal uses a separate session, not your API key (see Cookies and browser storage).
• Marketplace activity: match proposals and approvals, contracts and their status and agreed rate, any listings (providers who send leads), your requirements and limits (clients), contract requests, and for contracts the billing model and any term.
• Billing details: where card payment is set up for a client account, the Stripe customer identifier and the identifier of the payment method you attach. Your card number is entered into Stripe's own form and handled by Stripe; we receive and show the card brand and last four digits.
• Webhook settings: if you set up a webhook, its address and signing secret.
• Disputes: if a client disputes a conversion, the reason, the free-text description, and any refund amount requested or approved.
• Our staff: platform administrators have accounts and can see data across clients and providers in order to run the service.

2.2 People who respond to advertising (leads)

When a person fills in a form on a landing page we host, or a provider sends us a lead through our API, we record:

• Email address and phone number as hashes. We convert them into one-way SHA-256 fingerprints and store the fingerprints. Fingerprints of email addresses and phone numbers can still be matched back to a person by anyone who already knows the address or number, so we treat them as personal data.
• Other form answers. Landing pages we host store the other answers as submitted. Depending on the campaign, forms can ask for, for example, first and last name, date of birth, ZIP code or state, household size, income range, credit-score range, employment status, and details about a property or vehicle. These answers are not converted to hashes. Leads sent by a provider through the API are screened and values that look like an email address, phone number, street address, name, date of birth or national ID are dropped.
• Technical data: IP address, browser user-agent, referrer, advertising click identifiers (such as gclid and fbclid), our own click identifier, sub-identifiers set by the provider, and, if a provider supplies it, a device fingerprint. IP address and user-agent are stored as they are, not hashed.
• Consent record: whether consent was given, the consent text shown, the time, and a TrustedForm certificate link that proves what the visitor saw.
• Lead status: the vertical, an estimated value and currency, the provider and campaign, the client the lead was matched to, whether it looks like a duplicate, and the outcome (for example, a deal won or a payment collected).

For a lead that came from a banner click, see also section 2.6. The provider that supplied a lead through our API can see the lead's record that we hold for it, including its hashes, IP address, user-agent and consent fields, and its status. For each conversion of that lead the provider sees whether and when it converted, the sale amount and currency its share is based on, and its earnings. It does not see the client's systems: not which system reported the sale, the client's record ids in that system, or invoice details. The lead and conversion records do not name the client; a client's business name is shown to a provider only on a match or contract between them, and with the client's banners shown on the provider's website. A client sees the conversions and amounts for its own leads, and the person's name and contact details only when the person agreed on the Hotlead form that they be passed to that client (section 3).

2.3 Fraud and duplicate checks

When a lead arrives we run rule-based checks: the same email or phone fingerprint arriving repeatedly, the same fingerprint across several providers within a week, bursts of leads, repeated submissions from one device or IP address, and known test addresses. For banner clicks we limit the number of clicks counted from the same network address on the same ad space (using a hash of the IP address), do not count clicks that come too soon after the banner was shown, and flag ad spaces whose click rate is far above normal. The results are stored as scores or flags and are advisory: they are used for review, to keep clicks that are probably not genuine out of the matching, and in disputes. We do not use the model described in section 4 to make decisions about people.

2.4 Connections to client systems

See section 4 for what we read and write. In short, we store the credential or access grant a client gives us (encrypted), a snapshot of the structure of the client's system (names of objects, fields, pipelines and stages, not the records), the mapping the client confirmed, and an audit log of connection events.

2.5 Logs and communications

• Logs of delivery of notifications and webhooks, including the destination, the status, and the payload sent (lead identifier, status, amounts and screened metadata).
• Short-lived logs used to limit how often someone can try to sign in, reset a password, use an API key, use a connect link, connect a system or probe the marketplace. The sign-in and API-key logs, and the logs of failed connect links, hold a hash of the email address, key or network address, not the value itself.
• Emails we send you (for example account verification, password reset, welcome, notices that your API key was replaced, account deletion confirmation, marketplace, dispute and conversion notices) and what you send to us.
• Records of data downloads and account deletion requests: when they happened and their status. The download record holds the number of rows in each part of the file, not the data.

2.6 Visitors of providers' websites (banners and clicks)

• Showing banners. When a page with the site script opens, the visitor's browser asks Hotlead which banners to show, sending the website's public identifier and the path of the page (without the rest of its address). The banner images are then loaded from our storage. We choose banners by the website, the page, the ad space and the client's targeting, not by information about the visitor. We do not keep a record of each visitor or each page view. As with any request on the internet, the visitor's IP address and browser details reach our hosting providers (section 5) to deliver the request.
• Impressions. We count how often each banner is shown in each ad space as totals per hour, with no IP address, identifier or other data about the visitor.
• Clicks. A banner's link goes through Hotlead. When a visitor clicks it, we check that the link is genuine and recent, and record the click: the time, the banner and its client, the ad space and its provider, and, as for our other click links (section 2.2), the IP address, browser user-agent and referrer, together with a hash of the IP address used to limit repeated clicks. The visitor then goes to the destination the client chose, with our click identifier.
• On the client's own website. If the destination is the client's website, our click identifier is added to its address (ar_click). On Shopify and Wix we read it from the order. On other websites, the site script installed by the client adds it as a hidden field to the forms on the page the visitor arrives on, so that a contact the visitor submits reaches the client's own CRM together with the click identifier. What the visitor types into the client's form goes to the client's systems under the client's own privacy notice; we later read the click identifier and the sale from those systems (section 4).
• On a Hotlead form. If the destination is a Hotlead form, the visitor's answers and consent are handled as in section 2.2.
• Who sees what. A provider sees, for each of its ad spaces, the number of impressions and clicks, which clicks became sales, the sale amount its share is based on and its earnings, and the business name and banners of the clients shown there. A client sees, for each of its banners, impressions, clicks, sales and cost, and the names of the websites where its banners ran. Neither side sees the other's data about individual visitors beyond this, and the click records (IP address, user-agent) are not shown to the provider or to the client. Our administrators see all of it.

3. How we use data

• To run the marketplace: create and secure accounts, review and approve providers, match banners with ad spaces, propose matches and form contracts, route a lead or a click to the client it belongs to.
• To match automatically: on each banner request we select the eligible banners (approved provider, matching fields and countries, a banner of the right size, not blocked by the provider's rules, rates that overlap) and rotate among them weighted by the expected value of each (the agreed rate and the rate at which that client's clicks have become sales, with a minimum share so that new clients are shown). This concerns businesses, not visitors.
• To serve banners and install the site script: read a provider's home page when it asks us to (scan), show banners in its ad spaces, count impressions, and, where the provider asks, install the script on its website.
• To deliver leads: record the lead, and write a lead reference (a placeholder record with the lead identifier, the vertical, the estimated value and a return address) into the client's CRM. When a visitor of a Hotlead form ticks the consent line that names the business (it lists the channels the business may use: phone, email, SMS and WhatsApp), we also pass the visitor's name, phone number and email address to that business's CRM (HubSpot, Pipedrive, GoHighLevel, Close, ActiveCampaign, Salesforce, Zoho, Fireberry, or the business's own webhook when it chose to receive them). Until delivery we hold that clear copy encrypted, for at most 14 days, and we delete it once delivered. Without that consent we do not send the person's contact details to the client's CRM.
• To detect sales: read deal stages, payments, invoices or orders from the client's connected systems and match a payment or invoice to a lead by comparing fingerprints of the payer's email and phone with the fingerprints stored on the lead. The payer's email and phone are used for that comparison only.
• To calculate fees and shares and keep a billing record, including making sure that the same customer is not charged twice.
• To detect fraud and duplicates (including click controls on banner traffic), to review and remove reported banners, and to handle disputes.
• To show reports to providers and clients (section 2.6).
• To run advertising for clients: we launch campaigns on Hotlead's own Meta and Google advertising accounts and create landing pages, using the client's industry, the product and offer text the client gives us, and generated ad copy.
• To send service emails and notifications.
• To give account holders a copy of their data and to delete an account when its holder asks (see section 10).
• To keep the service secure and working: limits on failed sign-ins and other attempts, audit events, diagnosing errors.

Legal bases or other grounds for these purposes, where the law requires us to state them: [APPLICABLE PRIVACY LAW].

4. Systems that clients and providers connect

A client connects a system by pasting a key or token, or by signing in on the vendor's own consent screen (for Zoho, Salesforce, QuickBooks and Xero; for Wix through the Wix app install). By connecting, the client confirms it is entitled to give Hotlead that access. The access Hotlead asks for is the access listed below, and no more than the key or app permission the client creates.

A client who is not the right person to create the key can send a connect link to the person who is. The link lets that person connect one system for that client, once, without an account; it stops working once used, when the client cancels it, or after a few days (by default 7, never more than 30). We store only a hash of the link.

What we write

• A lead reference for each lead (see section 3).
• For leads from a Hotlead form (DRAFT): the lead's name, email address and phone number, when the person agreed on the form that the named business may contact them (by phone, email, SMS or WhatsApp). Until they are delivered we hold them encrypted, for at most 14 days, and then delete them.
• The custom fields or properties we need in order to store the lead identifier and return address, for example two custom deal properties in HubSpot.
• Webhooks or notification subscriptions in the client's account, so that the system can tell us when a deal is won or a payment is made (for example in Stripe, Pipedrive, GoHighLevel, Close, ActiveCampaign, Zoho, PayPal and Shopify). Where a vendor lets them lapse, we renew or re-create them while the system is connected.
• During the onboarding test, one clearly tagged test lead, which we read back and remove again where the vendor allows it; otherwise we tell the client which record to delete.
• For a setting that only the vendor's support desk can change (for example the payment notification address at Grow/Meshulam or Cardcom), we prepare a message to that support desk with the client's company name, the account identifiers the vendor needs and our notification address for the connection, never a key. The client sends it, or, where we have switched this on for that vendor, we email it for the client after the client agrees to the exact text, with the client's email address in copy.

What we read

• The structure of the system: names and types of objects, fields, pipelines, stages and option labels. We store this snapshot and the mapping the client confirms (for example which field is the email and which stage means “won”).
• Outcomes: the stage and amount of the deals we created, and payment, invoice or order status, amount and currency, and the Hotlead click identifier carried on an order or on a record created from the client's own form.
• Payer details for matching: the payer's email and phone on a payment, invoice or order, used only to compute fingerprints for matching.
• Won deals and their contacts (DRAFT): for the CRMs where it is switched on, the won deals and invoices of the client's system within the attribution window, including records Hotlead did not create, and the email and phone of their contacts, read only to compute fingerprints and compare them with our leads. We do not store the contact details we read. We also note when a record Hotlead created was deleted, archived or no longer carries our reference.
• Contact emails, only when the client asks: a client can ask us to list the contact email addresses in its CRM so it can use them as the recipients of an email campaign. The list is returned to the client's browser and, if the client launches the campaign, passed to the client's own email provider. We do not copy the contact database into ours.

What each connection allows, in plain words

Not every system is switched on for sale detection; the connection card in the portal tells the client what Hotlead does with each one.

Credentials and disconnecting

Credentials and access grants are encrypted before they are stored (AES-256-GCM) and are decrypted only when Hotlead makes a call to that system. A client can disconnect any system in the portal. On disconnect we:

• ask the vendor to remove the webhooks or subscriptions we created (best effort, within a few seconds); anything that could not be removed is recorded and tried again later, using an encrypted copy of the credential kept only for that purpose;
• delete the stored credential and remove secret-looking values from the stored settings;
• for a Salesforce, Zoho, QuickBooks or Xero connection that holds a lasting access grant (a refresh token), ask the vendor to cancel that grant (best effort, right after the disconnect; a failed request is tried again for a limited time, using an encrypted copy of the grant kept only for that purpose). For QuickBooks and Xero we do not send this request while another active connection uses the same company account, because cancelling it would cut that connection too.

For every other connection, the key or app the client made for us stays in the vendor account after a disconnect: the client should delete it there to close our access completely.

The connection record stays. The structure snapshot and the confirmed mapping are kept so that reconnecting the same account can bring them back. When our automatic clean-up is switched on, they are deleted 30 days after the disconnect unless the client chose to keep its setup; while it is switched off, they are kept until the client asks us to delete them or deletes its account. The portal tells the client which of the two applies.

Provider websites: the scan and the site script

• The scan. When a provider adds its website or asks for a new scan, our server reads the website's home page once, identified as a Hotlead site scan, sending no cookies or credentials. We read from it the platform, whether Google Tag Manager is on it and its container identifier, and the elements that look like banner spots (their position, size and the address of their image). Only the spots the provider chooses are kept as ad spaces; the other proposals are not stored. We keep a log of when each provider asked for a scan, to limit how often it can be done.
• Marking spaces. A one-time link opens a Hotlead toolbar on the provider's own website so that it can mark or adjust ad spaces there. We store only a hash of the link; it works once and for 30 minutes, and only on that website.
• One-button installs. On WordPress, the provider approves an application password on its own site's “Authorize application” screen; we use it, through the site's REST API, to install and activate the Hotlead plugin, which the site downloads from the WordPress.org plugin directory. On Google Tag Manager, the provider signs in with Google and grants access to Tag Manager; we use it to create the Hotlead tag in the provider's container and publish the container. On Wix and Shopify, installing our app adds the script. We use these grants only to install, update, check and remove our script, plugin or tag. The provider can withdraw them at any time (application passwords in its WordPress user profile, third-party access in its Google account, or removing our app).
• The site script. The script itself sets no cookies, writes nothing to the browser's local or session storage and reads no identifier from the browser (section 6). It reports to us which of the website's ad spaces it found on the page, so that the portal can show their status, and its first request tells us that the script is installed.

Google user data (Google Tag Manager)

(DRAFT, lawyer to confirm.) If you choose “Install with Google Tag Manager”, you sign in with Google and allow Hotlead to manage your Tag Manager containers and container versions and to publish them (Google's permissions tagmanager.edit.containers, tagmanager.edit.containerversions and tagmanager.publish), and to see the email address of the Google account you sign in with (openid, email), which the portal shows so you know which account is connected. We ask for nothing else: no permission to delete containers, manage users or manage accounts.

• What we do with it. We list your Tag Manager accounts and web containers so that you can confirm the one on your website. In the container you confirm, we create one workspace, one Custom HTML tag that loads the Hotlead site script and one All Pages trigger; we create a container version, compare it with your live version and publish it only when the only change is our tag and trigger. When you remove the tag or your website (or delete your Hotlead account), we delete our tag and trigger and publish again where you allowed it. We never delete your workspaces or containers.
• What we keep. The Google permission (stored encrypted, like other credentials, section 8), the Google account's email address and identifier, the container you confirmed and the identifiers of our tag, trigger and the versions we published. We do not read, copy or keep your other tags, triggers or variables beyond the comparison above.
• Who sees it. We use the permission only for the operations above, for you. We do not share or transfer it or anything read with it to anyone, and no person at Hotlead reads your container data, except where needed for security or to comply with the law.
• Ending it. We revoke the permission at Google when you remove the tag or the website, or delete your account (unless another of your websites still uses the same Google permission). You can also remove Hotlead's access at any time in your Google Account (Security, third-party connections).

Hotlead's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Automated assistance

To suggest which of a client's fields and stages mean “email”, “phone” or “won”, we first use fixed rules and only then ask a language model hosted by Groq. The model sees only names, labels, types and option labels as short aliases. Before anything is sent, any value that looks like an email address, phone number, key or token is replaced by “[redacted]”, and we do not log prompts or replies. We also use Groq to write ad and landing-page text from the industry, product name and offer text a client gives us. The client reviews and confirms the field mapping; the model does not decide anything about a person.

5. Who we share data with

We use the following service providers. Most process data for us under their data-processing terms (sub-processors). Our emails are sent from Hotlead's own Gmail account, which Google provides under its own terms (see section 7 for the copies Gmail keeps). The list can change; we will update this page.

Where a provider asks us to install the site script, we act in the provider's own accounts: Google (Google Tag Manager API, only when the provider connects it), its own WordPress site, or Wix or Shopify through our app. Those vendors process the data under the provider's own agreement with them. WordPress.org is only the public directory from which a WordPress site downloads our plugin; we send it no data about you.

We also share data between the parties to a deal, as the marketplace requires: a provider sees its own leads, the impressions and clicks of its ad spaces, whether they converted, the sale amount its share is based on and its earnings, and the business name and banners of the clients it is matched with, nothing about the clients' systems or customers; a client sees its own conversions, amounts and connection status, the results of its banners and the names of the websites where they ran; our administrators see all of it. The systems a client connects are the client's own, under the client's own agreement with that vendor; where the client agrees to it, that vendor's support desk receives the message described in section 4. We disclose data where the law requires it.

6. Cookies and browser storage

We do not use advertising or analytics trackers on our website or portal. The banners we serve on providers' websites are contextual: they are chosen by the website, the page, the ad space and the client's targeting, and we do not track visitors across websites or build profiles of them. We use the following:

• The site script on providers' websites (banners). On a provider's website the script sets no cookies, writes nothing to local or session storage and reads no identifier from the browser. It sends the website's public identifier and the page path to fetch banners (section 2.6), and it reports which ad spaces it found. The banners are links marked as ads.
• Banners on websites (DRAFT, lawyer to confirm). Websites that work with us can show businesses' banners through our site script. To show a banner, the visitor's browser asks our server which banner to show for that page (it sends the website's identifier and the page's path, as any web request does with the browser's IP address and type); the script sets no cookie and uses no browser storage, and banner images are plain image files served from our own address. We count views and clicks in hourly totals per ad space and banner, without a row per visitor. When a visitor clicks a banner, we record the click (which banner, ad space and website, the time, the browser type, the referring page, and a one-way fingerprint of the IP address used to limit repeated clicks; not the IP address itself) and send the visitor to the business's website or to our short form. A click less than a second after the banner appeared, or too many clicks from one address, is not counted. Click records follow the click retention rule below.
• Site script on a client's own website (DRAFT). A client may add our script to its own website. When a visitor arrives there from a Hotlead link, the script keeps the Hotlead click in that website's own browser storage (hl_attr_v1, no cookie, no third-party storage) until the attribution window ends, and adds it to the website's forms. When the visitor sends a form, the script computes fingerprints of the email and phone typed and sends only those fingerprints with the click; the email and phone themselves never leave the visitor's browser. Where the client's website asks for consent first, the click is stored only after consent.

On our own website, portal and links:

• Session cookies hl_adv_session (clients) and hl_prov_session (providers). When you sign up or sign in, we set a cookie that holds your portal session. Scripts on the page cannot read it (HttpOnly), it is sent only over a secure connection, only to our API (path /v1) and never with requests from other sites (SameSite=Strict). A session lasts at most 7 days and ends after 24 hours without use; signing out ends it. While a page is open, the session is also kept in that page's memory. Our staff's administration site uses a similar cookie.
• No keys in browser storage. Your API key and your session are not kept in local storage, session storage or a cookie that scripts can read. A key that an older version of the portal left in local storage is deleted the next time you open the portal.
• Language and progress (local and session storage). The portal remembers your language (the sign-up page uses the same setting). During sign-up and while connecting a system, your progress is kept in the current tab (no key or password), and the portal remembers your answers about where your sales are recorded.
• Click cookie ar_click_id. When someone follows one of our campaign links, we set this cookie on our own domain (HttpOnly, 30 days) holding the identifier of that click, so that a Hotlead form submitted later can be attached to the click. It is not set on, or read from, a provider's or client's website.
• Sign-in protection cookie oauth_state_binding. A short-lived (10 minutes) cookie used while a client connects a system, to prevent forged requests.
• Third-party scripts. The portal loads Stripe's script to take card details. Campaign landing pages load TrustedForm's script to produce the consent certificate.

7. Retention and deletion

We have not yet set fixed retention periods for most data. Unless one of the rules below applies, accounts, leads, clicks, fraud scores, conversions, disputes, notification logs and the connection audit log are kept until they are deleted. What happens today:

• Short-lived logs: the logs that limit connection attempts and marketplace probing, and the logs of failed connect links, are deleted automatically after one day. Records of failed sign-in and API-key attempts are deleted one day after the last failed attempt (later if a temporary block is still running). Expired portal sessions are deleted daily, and connect links 30 days after they expired.
• Erasing a lead: a provider can erase a lead it supplied. The same erasure is used when our administrators permanently delete leads, when an account is deleted, and by the retention schedule once it is switched on (all below). Erasing a lead clears its IP address, browser user-agent, device fingerprint, the consent record (the text shown, the time and any consent IP fingerprint a provider sent; only the yes/no answer stays), the TrustedForm link, the advertising click and sub-identifiers and all other form answers. It clears the same technical data on the lead's click record, where no other lead uses that click. In the lead's conversion records and the notification logs of those conversions, it removes the fields that name personal details (such as email, phone, name, address or date of birth) and any value that looks like an email address.
• What an erased lead keeps: if the lead has no conversion, its email and phone fingerprints, the provider's own reference for it and the references to the records we created in the client's CRM are removed too. If the lead has a conversion (a recorded sale), those are kept, together with the conversion and its amounts and any dispute about it (including the text written in it). We keep them as evidence for billing, refunds and disputes, and so that the same customer is never charged twice. The industry, estimated value, currency, dates, status and our internal references stay in every case; on their own they do not identify the person. The fraud scores (type, score and counts; no personal data) stay until the lead is permanently deleted.
• Identity fingerprints (DRAFT, lawyer to confirm): the email and phone fingerprints of a lead are kept for the attribution window plus the dispute window (by default 180 + 90 days from the click), even after the lead is erased or deleted, to prevent fraud and to establish or defend legal claims (for example GDPR Article 17(3)(e)), and are then deleted automatically. Clear contact details held for delivery to a business are deleted on delivery or after 14 days at the latest. Risk scores about client accounts (counts and rates, no personal data about consumers) are kept 400 days.
• Erasure records: for each erasure we keep a record of which lead (by our internal reference), who asked, when, and which kinds of data were cleared or kept. It holds no personal data.
• Permanent deletion by us: an administrator can permanently delete leads that were deleted more than 30 days earlier. A lead without a conversion is then removed together with its fraud scores and its click records (where no other lead uses them). A lead with a conversion is not removed: it stays in its erased form with its billing records, as described above.
• Older raw webhook records: an older part of our system stored raw payment messages from connected systems, which may contain a payer's email or phone. These records are not linked to a lead and are not yet covered by the erasure or by a retention period.
• A retention schedule is built but not in force: our system can automatically clear or delete some kinds of data after set periods. It is switched off and the periods are not decided yet. We will list the periods here before we switch it on.
• Copies of the emails we send: we send our emails from Hotlead's own Gmail account, and Gmail keeps a copy of every email it sends in that account's Sent folder: the recipient address, the subject and the text, including password-reset and account-deletion confirmation links (these links stop working after 1 hour and 24 hours) and messages to a vendor's support desk. The copies are kept until we delete them in Gmail; we clear them regularly.
• Disconnecting a system: see section 4.
• Websites, ad spaces and scans: a provider can remove an ad space or a whole website in the portal at any time; removing a website deletes its ad spaces and marking links with it. Otherwise the website and ad-space records (including the element positions and the image addresses found by the scan) are kept while the website is in the account. The log of scan requests is kept for about a day (older entries are removed when the next scan is requested). Marking links expire after 30 minutes; used and expired links are removed when a new one is made.
• Impressions: the hourly totals are kept for [RETENTION PERIOD FOR IMPRESSION COUNTS]. They hold no personal data.
• Banner clicks: click records follow the rules for other click records in this section (a click that became a lead or a sale is kept with that lead's records). The hash of the IP address used to limit repeated clicks is kept for [RETENTION PERIOD FOR HASHED IP ADDRESSES OF CLICKS].
• Banners: a banner that a client removes, or that we or the provider's rules pull, stops being served at once. The image, its alt text and its settings are kept for [RETENTION PERIOD FOR REMOVED BANNERS] after that, as evidence for reports, billing and disputes.
• Deleting an account: how to ask is in section 10. When an account is deleted, sign-in, the API key and every portal session stop working; every connected system is disconnected as described in section 4; no stored credential, structure snapshot or mapping is left on the account's connections; for a client, its email-sender settings and keys, open connection sign-ins, connect links, support-desk messages, connection audit log and rate-limit logs are deleted; for a provider, its outbound webhooks and their secrets, its notification logs and the contact details of its publishers are deleted, and no banner is served on its websites any more; the profile is anonymised (the email address is replaced, and the password and, where present, the notification email, webhook, payment method, budget, payout details, description and website are removed); contracts, listings, requirements and campaigns are stopped; click records of the account's campaigns that never became a lead are cleared; and the account's leads are erased as described above (for a provider, all its leads; for a client, the leads Hotlead generated for it). We then send a final email, without a link, to the sign-in address.
• What a deleted account keeps: the account record with its internal reference, the company or provider name, the Stripe customer or Connect identifier, the version and time of the accepted terms and the date of deletion; conversions and their amounts, invoices, payouts, disputes (including their text), deal history, fraud scores, the erasure records, the records of key replacements, the deletion request (its dates; the email address is removed from it when the deletion is done) and the record of data downloads. These are billing and dispute evidence and the evidence of what was agreed. Leads a client bought from another provider stay that provider's records. A deleted provider's website and ad-space records are kept for [RETENTION PERIOD FOR WEBSITE AND AD-SPACE RECORDS OF A DELETED ACCOUNT]. We have not yet set a period after which the other kept records are removed.

8. Security

No system is perfectly secure and we cannot promise otherwise. These are the measures that exist in the product today:

• Credentials and access grants for connected systems are encrypted at rest with AES-256-GCM.
• Passwords are stored as bcrypt hashes; API keys, portal sessions, reset tokens and deletion links are stored as hashes. Password reset links expire after one hour and work once.
• Repeated failed sign-ins, password-reset requests and wrong API keys lead to temporary blocks that grow longer with repeated failures. The block message is the same whether or not the account exists.
• Portal sessions are held in cookies that scripts cannot read, last at most 7 days and end after 24 hours without use. API keys are shown once and never emailed. Replacing a key or deleting the account needs the password; replacing a key signs out the account's other browsers, and a password reset signs out all of them.
• Data of each client and provider is separated by row-level security in the database for the main tenant tables, and the database's public API roles have no access to our tables.
• Web security headers (content security policy, frame blocking, no referrer, permissions policy) on the portal and public pages.
• Limits on how often a client can test credentials, call connected systems or probe the marketplace.
• Sign-in to a connected system uses a one-time state value and a binding cookie. Web addresses a client supplies for webhooks must be public https addresses.
• Incoming webhooks are authenticated with a secret in the address and, where the vendor signs its messages, a signature check.
• New providers are reviewed and approved by us; until a provider is approved, no client banner is served on its website.
• The site script receives banners only for the website it is installed on: our server answers only requests from that website's own address, and the website's identifier lets the script do nothing else.
• Banners are image files only (no HTML or scripts), their type and pixel size are checked on our server, and they are served from our own storage. Banner links carry a signed, short-lived click token, so that a click cannot be forged for another banner or client, and the banner request does not reveal the client's destination beyond the click redirect.
• Limits on clicks from the same network address on the same ad space, and flags on unusual click rates (section 2.3).
• The scan reads only public web addresses, with checks that block internal or private network addresses, a time limit and a size limit, and is limited per provider. A marking link is stored only as a hash, works once, for 30 minutes and only on its website.
• An audit log of connection events, with secrets and long tokens removed.
• Error messages are scrubbed of credentials before they are logged; prompts to the language model are not logged.

9. Where data is processed

Our database is hosted by Supabase in [DATA HOSTING REGION]. Our other service providers listed in section 5 may process data in other countries, so data about you may be transferred outside the country where you live. The mechanism we rely on for those transfers: [INTERNATIONAL TRANSFER MECHANISM].

10. Your rights and how to use them

Depending on where you live, you may have the right to ask whether we hold data about you, to see it, correct it, have it deleted, object to a use, or complain to a regulator ([APPLICABLE PRIVACY LAW]).

How to ask. Email [CONTACT EMAIL] from the address on your account, or, if you are a person who filled in a form, say which page or campaign it was. Requests that the portal tools below do not cover are handled by hand. Our target response time: [RESPONSE TIME FOR REQUESTS].

• If you filled in a form or were the subject of a lead. There is no self-service tool for you; email us. We store your email address and phone number only as fingerprints, so to find your record we compute the fingerprint of the email address or phone number you give us and look for it. Please tell us the email address or number you used. The provider and the client involved in your lead may also hold data about you under their own policies, and we may need to ask them. What an erasure removes and what it keeps is described in section 7.
• If you visited a provider's website or clicked a banner. We do not keep a record of visitors who only saw a banner (impressions are hourly totals). A click record does not hold your name or contact details; to look for one we need the approximate time, the website and the IP address you used. Email us with these details.
• If you are a client or provider. In the portal you can correct your account details, disconnect systems, cancel contracts, download a copy of your data and ask for your account to be deleted.
• Download my data. You get one file (JSON) with your account's data: your profile, the version of the terms you accepted, contracts, campaigns, connections (their status and confirmed mapping, never keys) and your leads, conversions and billing records. A client's file contains the leads delivered to it without the person's personal data (only references, dates, status, industry and value, and the client's own CRM record references) and what it was charged, not the provider's share or our fee. A provider's file contains its leads as it submitted them and its earnings, not the client's sale amounts, the client's CRM references, which of the client's systems reported a sale, or the text the client wrote in disputes. The file never contains passwords, API keys, session keys, credentials of connected systems, webhook secrets or tracking tokens. You can download it once an hour; a very large part is cut at 100,000 rows and marked as cut. We record each download (when, and how many rows), not its content.
• Delete my account. Ask in the portal and enter your password. We email a single-use confirmation link to your sign-in address; it works for 24 hours. After you confirm, there is a 7-day waiting period: your account keeps working and you can cancel in the portal with your password. After that the account is deleted as described in section 7. If our automatic deletion is not yet switched on when the waiting period ends, your request waits until we process it. If we cannot send the confirmation email, the portal tells you and nothing is started; please contact us then. Some accounts, such as those of our own staff, cannot be deleted in the portal.
• Some data is kept for billing and dispute records even after an erasure or a deletion, as described in section 7.

11. Children

Hotlead accounts are for businesses. The service is not directed to children, and we do not knowingly collect data from children. If you believe a child's data reached us, contact us and we will look into it.

12. Changes to this policy

We may change this policy when the product or the law changes. The date at the top shows the last update. If a change is significant, we will tell account holders by email or in the portal.

13. Contact

[LEGAL ENTITY NAME]
[REGISTERED ADDRESS]
Company number: [COMPANY NUMBER]
Email: [CONTACT EMAIL]