Privacy policy

Last updated: November 12, 2026

1. Controller

EMI Solutions OÜ
Sepapaja 6, 15551 Tallinn, Estonia
Email: office@linkharbor.com

For privacy-specific requests: privacy@linkharbor.com.

We have not appointed a Data Protection Officer: the statutory conditions for doing so (Art. 37 GDPR — notably a core activity involving large-scale, regular and systematic monitoring of individuals, or large-scale processing of special categories of personal data) do not apply to us. Privacy requests still reach us reliably at the address above.

2. Two kinds of processing under one policy

This notice covers two different things worth keeping apart:

• This platform (linkharbor.com, the dashboard at deck.linkharbor.com, the LinkHarbor apps for iOS and Android and the API at dock.at-harbor.com — components of the same system) — where we process data for running the site, registration, login, and billing.
• Pages published by our users (e.g. linkharbor.com/@handle or a custom domain) — where the page owner decides what content appears. See section 8 for the important special case of embedded third-party content.

Public published pages appear by default in the search of the LinkHarbor app and on linkharbor.com (Discover), with handle, display name, SEO title and description, profile picture, address and follower count. The page owner can switch this off per page ("Listed in public search"); the page then stays reachable through its own link. The search index runs on our own infrastructure.

3. Access logs & basic operation

Every request is processed automatically for technical access data — timestamp, method and requested path (without URL parameters), status code, response time, the country Cloudflare derives from the IP address, for signed-in requests the account and workspace ID or the ID of the API key or connected app (section 9), plus IP address and user agent. In access logs we store the IP address and user agent as a cryptographic hash (HMAC-SHA256 with a secret key), not in plaintext. Internal audit records hold both as such a hash as well, and in addition the full IP address in plaintext (see below). We do not store the contents of requests and responses there. Legal basis: Art. 6(1)(f) GDPR, legitimate interest in operation, security and abuse detection.

We keep IP addresses in plaintext only in the five places listed below, and only for as long as stated there; everywhere else, in particular in the statistics of published pages, in access logs, with form submissions and in consent records, we store them only as a hash with a secret key. We process the IP address in plaintext in these places because attacks such as password guessing or mass registrations cannot be detected and stopped otherwise:

• Security log: for sign-ins (including via Google or Facebook), failed sign-ins, registrations, password resets, resent confirmation emails, two-factor checks, sign-ins with an API key, blocked IP addresses and form submissions on published pages we write the time, the kind of event, the IP address and, where there is one, the email address used to a security log. Retention: the log starts a new file every day; we delete entries after 90 days, including their copy in our central logging system (section 9).
• Server logs of our edge servers (section 10): per request the IP address, requested host, request line (method and address including URL parameters), status code, response size and referrer. Retention: we do not archive these logs or forward them to our logging system; newer entries continuously replace older ones.
• Logs of the web server in front of our API: per request the IP address, time, request line and status code; they are deleted after at most 30 days.
• Abuse counters: locks after too many failed sign-ins, per-IP limits for registrations, confirmation emails and form submissions, and request rate limits use the IP address as a key in our cache. These entries expire automatically after at most one hour.
• Internal audit records: for every audit event triggered by a request sent directly to our API (from the dashboard, the LinkHarbor app, an API key or a connected app, and pages on custom domains served by our API), such as sign-ins and registrations, changes to accounts, workspaces and pages, calls with an API key or by a connected app (section 9), actions of our administrators, the proof of email delivery (see below) and blocked IP addresses, we record the full IP address of that request together with the event. Requests our edge servers pass on to our API on a visitor's behalf, such as form submissions and page statistics, get no IP address in these records. When we block an IP address after too many failed sign-in attempts (including password resets and sign-ins with an API key), the entry also holds the reason (which function the failed attempts came from and how many there were) and when the block started and ends; if an administrator lifts the block early, that is recorded with the IP address too. This lets us trace which action came from which connection, recognise misused accounts and API keys, and stop repeated attacks from the same address. Retention: 365 days. The copy in our central logging system (section 9) holds the IP address only as a hash.

The legal basis is again Art. 6(1)(f) GDPR: our legitimate interest in security and abuse prevention, i.e. in protecting your account, our systems and our users' pages against abuse.

Proof of email delivery: for every email our platform sends (such as the confirmation of your email address, password resets, team invitations, security notices, the form digest or emails about your subscription), we record in our internal audit records the recipient address, the kind of email, the time and the outcome: sent, failed (only the kind of error) or not sent and why (for example because you switched these emails off, because too many emails would have gone to the same address in a short time, or because there is no account for the address). If the address belongs to an account, we store its ID with it, and if the email belongs to a workspace, that workspace too. If a request triggered the email (for example a password reset), the entry also holds the IP address of that request, as every audit record does (see above). We do not store the subject, content or links of the emails there. This lets us prove whether and when an email was sent, resolve support requests ("I didn't get an email") and detect abuse, such as mass requests to other people's addresses. Retention: 365 days; entries for emails that do not belong to a workspace (such as confirmations, password resets and security notices) are kept until the end of this period even after an account is deleted. The copy in our central logging system (section 9) contains neither the recipient address nor the IP address in plaintext. Legal basis: Art. 6(1)(f) GDPR, our legitimate interest in proof of delivery, support and abuse prevention; where this proves the delivery of notices required by law, Art. 6(1)(c) GDPR.

Sign-ins from a new device: when you sign in to your account (with your password, a two-factor code, Google or Facebook), we form a device key from the browser family (e.g. Chrome), the operating system family (e.g. iOS), the device class (computer, phone, tablet or app) and the country Cloudflare derives from the IP address. We store it only as a cryptographic hash (HMAC-SHA256 with a secret key, different for every account), together with the time of the first and the last sign-in from that device. We do not use the IP address, the full user agent or the browser version for this. If a device signs in that we don't know for your account, or haven't seen for 180 days, we send you a security notice by email with the browser, operating system, approximate country and time of the sign-in (section 5); the very first recorded sign-in of an account only stores the device. You can switch this email off; we still record the device, so switching it back on later doesn't flood you with notices about every device used in the meantime. Legal basis: Art. 6(1)(f) GDPR, our and your legitimate interest in noticing a sign-in by someone else quickly. We delete a device 180 days after its last sign-in, and at once with your account.

For click/view statistics on an individual published page, we additionally process, per event: the hashed IP address, the User-Agent as a hash and in plaintext as well (needed to detect device type/OS — e.g. "mobile, iOS"), the country, the referring URL (where the click came from) and, for campaign links, the campaign parameters. This applies to every visitor, including without consent: in that case we count the view or click anonymously, without a cookie and without storing anything on or reading anything from your device, using only the details of that request. The legal basis for this is Art. 6(1)(f) GDPR: the page owners' legitimate interest in reach statistics for their pages and our interest in providing them. Only if you chose "Accept" in the page's consent banner or "Allow" in the LinkHarbor app (or use an app version that does not ask yet; section 4) is the visitor ID described there added; we use it to de-duplicate views and clicks, and to tell "new" from "returning" visitors we keep, per page, the visitor ID with the time of its first visit. Unique visitors and new and returning visitors therefore only include visitors who consented (with "Accept" or, in the LinkHarbor app, "Allow") and visitors using an app version that does not ask yet. This raw data exists only to build the aggregate statistics (views, clicks, device and country aggregates) — we don't build per-person profiles from it, and we don't pass it on in plaintext to the page owner, who only ever sees the aggregate numbers. What we pass on to a link's target when you click is described under "Placeholders in link targets". See section 11 for how long it's kept.

Placeholders in link targets: the page owner can put placeholders into a link's target address. Only then do we fill them in on the click and pass the values on with the redirect to that link's target, i.e. to a website the page owner chose. Without placeholders we add nothing to the target address. This applies equally to published pages on linkharbor.com and on custom domains. The placeholders are:

• {{LH_IP_HASH}}: a keyed hash (HMAC with a secret key) of your IP address. The same IP address gives the same value across all pages and links served the same way, so the target can recognise repeated clicks from the same connection. Pages on linkharbor.com and custom domains served directly by our API use different keys, so the value differs between them. This value is filled in on every click, regardless of your choice in the consent banner.
• {{LH_VISITOR_ID}}: the visitor ID from the page's visitor cookie (vid on pages on linkharbor.com, lt_vid on custom domains served directly by our API; section 4), only if you chose "Accept" in the consent banner or "Allow" in the LinkHarbor app (section 4), otherwise empty.
• {{LH_COUNTRY}} (the country derived from the IP address, e.g. DE), {{LH_DEVICE_TYPE}} (mobile, tablet, desktop or bot), {{LH_BROWSER}} and {{LH_OS}} (browser and operating system).
• {click_id} or {{LH_CLICK_ID}}: a random number per click that lets the page owner's shop attribute a later purchase to that click (sale callback); it is not stored on your device.
• Page and link details ({{LH_PAGE_ID}}, {{LH_HANDLE}}, {{LH_HOSTNAME}}, {{LH_WORKSPACE_ID}}, {{LH_DOMAIN_ID}}, {{LH_LINK_ID}}, {{LH_LINK_TITLE}}): they contain no data about you.
• Parameter pass-through (from Creator Basic): if the page owner switches this feature on and puts placeholders such as {{utm_source}} (on custom domains served directly by our API: {utm_source}) into a link target, we pass on to that target, on the click, the parameters you opened the page itself with: UTM parameters and ad network click IDs such as gclid, fbclid, ttclid or msclkid. Nothing is stored on your device for this.

We only pass these values on at the instruction of the page owner, who chooses the link's target and is responsible for it (as for other content on the page, section 8). What the target does with the values is governed by its own privacy policy. The legal basis for {{LH_VISITOR_ID}} is your consent (§ 25(1) TDDDG, Art. 6(1)(a) GDPR, section 4); for all other values and passed-through parameters it is Art. 6(1)(f) GDPR: the page owner's legitimate interest in evaluating campaigns and links.

4. Cookies, local storage and consent

We set no advertising cookies and no tracking pixels. Our own cookies are first-party (valid only for the domain that sets them; lh_consent and lh_aff on linkharbor.com also for its subdomains, see below) and contain no name, email address or IP address. The cookies our servers set are HttpOnly (not readable by scripts on the page) and SameSite=Lax, and Secure over HTTPS. Exceptions: lh_consent is set by a script on the page and lh_aff by a script or our redirect, both without HttpOnly; lh_admin_session is SameSite=Strict.

Consent banner on published LinkHarbor pages: published pages (on linkharbor.com and on custom domains) show a compact bar on your first visit with two equal buttons: "Accept" and "Decline". The choice is all or nothing: "Accept" consents to all cookies and external content listed below under "Only with your consent", "Decline" to none of them. As long as you don't choose, this counts as declining. The "Cookie settings" link in the footer of every page reopens the bar at any time so you can change or withdraw your choice. Your decision is valid for 12 months and carries a version number; if we change the processing described here, we ask again. On linkharbor.com one decision applies to all pages on linkharbor.com; every custom domain asks separately. In the LinkHarbor app published pages show neither the bar nor the "Cookie settings" link. Instead the app asks you once, before the first page opens, whether pages opened in the app may use these cookies and load external content, with two equal buttons: "Allow" and "Don't allow". The app works the same either way. With "Allow" pages in the app behave as after "Accept": they set the cookies listed below under "Only with your consent" and load external content such as videos and images from other websites by themselves. With "Don't allow" they behave as after "Decline": we only count your visits anonymously, and external content only loads one item at a time when you tap "Load content from …". You can change your answer at any time in the app under Settings → "Statistics cookies on pages"; it applies from the next page you open. The app stores your answer with its date and version on your device and passes it to the pages as the lh_consent cookie described below. It is valid for 12 months and carries the same version number as the banner; after that, or if we change the processing, the app asks again. App versions released before the app asked this question don't ask: until you update the app, pages opened in it set vid, lt_vid, lh_ref and lh_utm as they did before, but no lh_aff, and external media only load after a tap (legal basis below). This website (linkharbor.com outside published pages) and the dashboard show no banner: they only use strictly necessary cookies and storage, and reach measurement on this website works without cookies (section 14).

On published pages, strictly necessary (no consent needed):

• lh_consent: stores only your choice in the banner with its date and version (e.g. v1.all.20261104 or v1.none.20261104), 12 months. A script on the page sets it as soon as you choose "Accept" or "Decline"; in the LinkHarbor app the app sets it before each page it opens, with your answer in the app. On linkharbor.com it is valid for linkharbor.com and its subdomains, on custom domains only for that domain.
• lh_pw_… (7 days), lh_pv_… (24 hours) and lh_age_18 / lh_age_21 (30 days): only after you entered a protected page's password, opened an invite link to a private page or confirmed an age check. They hold nothing but a signed confirmation, so you aren't asked again on every visit.

In your browser's local storage (localStorage) published pages keep only two kinds of entries, both only after an action of your own: lh_embed_consent_…, if you ticked "Remember my choice on this page" when loading an embedded video (section 8; the entry applies only to the page where you ticked the box and carries that page's ID in its name), and lh_follow_banner_dismissed, if you closed the banner for the LinkHarbor app (it then stays hidden for 48 hours).

On published pages, only with your consent ("Accept"):

• vid: random visitor ID, 1 year. Used to recognise returning visitors: for the number of unique visitors (a single visit isn't counted twice in the aggregate statistics) and to tell new from returning visitors (section 3).
• lt_vid: random visitor ID, 180 days, same purpose as vid. Set by our API on pages and redirects it serves directly (e.g. /go/… and some custom domains).
• lh_ref: only when you arrive from another website; holds the first external referrer of your visit to this page, 30 days, and applies only to the page where it was set. A later click then counts towards the original source in this page's statistics.
• lh_utm: only when the link you opened carries campaign parameters (e.g. utm_source or ad network click IDs such as gclid, fbclid, ttclid and msclkid); holds the first such parameters, 30 days, only for this page, same purpose.
• lh_aff: only on pages under linkharbor.com, not on custom domains and not on white-label pages; holds the page owner's partner code, 30 days. If you later sign up for LinkHarbor yourself, the referral is credited to that person (partner programme, section 6). A script on the page sets it and does not overwrite an existing lh_aff; opening a partner link (linkharbor.com/r/…) sets that link's code through the redirect. The cookie is valid for linkharbor.com and its subdomains so the dashboard sign-up (deck.linkharbor.com) can read it. Without consent a partner link still works: the redirect then only passes the code to the sign-up form in the address (?ref=…), without a cookie.
• External media: images and videos in integration widgets, embedded videos, and images or backgrounds a page includes from other websites load only after your consent or when you click "Load content from …" (with the name of the provider or website) on that single item (section 8). Loading them gives the provider your IP address and technical details of your browser, and the provider may set its own cookies.

Without consent we still count views and clicks on published pages, but anonymously on the server: without a cookie and without storing anything on or reading anything from your device. We only process the details of that request: the IP address as a hash (HMAC with a secret key, never stored in plaintext), the user agent (as a hash and to detect device type and operating system, section 3), country, device type, and the referrer and campaign parameters of that request. Unique visitors and new and returning visitors therefore only include visitors who consented or opened the page in the LinkHarbor app.

In the dashboard: lh_oauth_nonce (at most 10 minutes, only while you sign in with Google or Facebook, protects against forged sign-ins). lh_admin_session: only for LinkHarbor staff in the internal admin area, keeps their admin sign-in (HttpOnly, Secure, SameSite=Strict); it expires 2 hours after the last activity, and every action in the admin area extends it. The dashboard keeps your sign-in, language and display settings in your browser's local storage (localStorage), not in cookies. It also keeps the last workspace you used, the currency of the price display, a reserved handle or invite link until you sign up, and whether you have already seen the product tour and the setup checklist; for the lifetime of the browser tab also where to return to after signing in.

On this website (linkharbor.com) your browser stores your light/dark choice locally (lh-theme) and, for the lifetime of the tab, whether you closed the sticky banner. For cookieless reach measurement see section 14.

Cloudflare security cookies: Cloudflare sits in front of this website, the published pages, the dashboard and the API (section 9). To protect against attacks, Cloudflare may set its own cookies there: cf_clearance when a security challenge runs (e.g. in "Under Attack" mode) and __cf_bm when Cloudflare's bot management is active. These are first-party cookies Cloudflare sets on our domains; they serve only to fend off attacks and automated traffic, not statistics or advertising.

Legal basis: storing and reading information on your device where this is strictly necessary for a service you asked for (lh_consent, password, invite, age check, sign-in, remembered settings, Cloudflare security cookies) is based on § 25(2) no. 2 of the German TDDDG; the further processing on Art. 6(1)(b) GDPR, and for lh_consent and the Cloudflare security cookies on Art. 6(1)(f) GDPR (our legitimate interest in respecting your choice and protecting our services against attacks). For vid, lt_vid, lh_ref, lh_utm, lh_aff and loading external media it is your consent: § 25(1) TDDDG and Art. 6(1)(a) GDPR. This applies to pages opened in the LinkHarbor app too: there you give your consent with "Allow" in the app's question, with the same scope as "Accept". App versions released before the app asked this question set vid, lt_vid, lh_ref and lh_utm without asking, because using the app requires an account and signing up includes accepting this privacy policy (section 5); once you update the app, it asks you. You can withdraw your consent at any time with effect for the future via "Cookie settings" in the page footer, or in the app with the switch under Settings → "Statistics cookies on pages"; from then on we no longer set these cookies, delete or stop using existing ones, and external media only load again after a click. This does not affect the lawfulness of processing before the withdrawal. The anonymous counting without consent is based on Art. 6(1)(f) GDPR (section 3). None of this builds a cross-site profile, fingerprints you or serves advertising. You can also delete all cookies and local storage in your browser at any time; the banner then asks again on your next visit.

5. Registration & account

Signing up processes: email address, first and last name, salutation (with a gender-neutral option), date of birth (age verification, minimum age 13 under Art. 8 GDPR, or COPPA for US users — details in the terms, section 3), a password hash (never the password itself), and the account type you chose (consumer or creator).

You can only sign up if you tick the checkboxes accepting our terms and this privacy policy. As evidence (Art. 7(1) GDPR) we store, for both documents, the version you accepted (its "last updated" date), the time, how you signed up (email, Google or Facebook), and the IP address and user agent exclusively as a cryptographic hash (HMAC-SHA256 with a secret key); the audit record of the sign-up itself holds the full IP address for 365 days (section 3). Optionally we record whether you opted into marketing communications (we don't currently rely on this consent for any bulk mailing — it's captured only in case that changes in future, and is revocable at any time). If you delete your account, we detach these records from it at once and keep them in pseudonymised form for three more years: without your name and without your email address in plaintext, only with the document, version, sign-up method, time, the hashes of IP address and user agent, and a hash of your email address (HMAC with a secret key). Through that hash we can only find them again when someone gives us the address, for example in an access request or a dispute. After the three years we delete them.

Legal basis for account data: Art. 6(1)(b) GDPR (performance of a contract) — without this information we cannot create an account; for the evidence of consent Art. 6(1)(c) in conjunction with Art. 7(1) GDPR; for keeping it after the account is deleted Art. 6(1)(f) GDPR (our legitimate interest in being able to prove the acceptance in case of a dispute).

Sign-in and sign-up via Google or Facebook are also available; in that case we only receive the basic data you approve sharing in the OAuth dialog (typically name and email). If you create a new account this way, we first ask for your date of birth (minimum age 13) and your acceptance of the terms and this privacy policy; only then do we create the account and store the evidence as described above. Until then we keep the details received from the provider (provider, your ID there, name, email address) in our cache for at most 30 minutes; if you don't complete the sign-up they expire and no account is created. An account created this way holds the name from your account with the provider instead of first and last name, and no salutation.

Connected accounts (integrations): when you connect an account of another platform to show its content on your page, you sign in with that platform and approve the access in its own dialog. We store the access granted to us (access and refresh tokens, encrypted with AES-256-GCM), the ID and name of the connected account and the content the widget shows. We use this data only to show that content on your LinkHarbor pages and to keep it up to date; we do not sell it, do not use it for advertising and do not use it to train AI models. If you disconnect the account in the dashboard, we delete both tokens at once and remove its content from your pages. If you delete your account, its integrations are switched off at once and deleted with the rest of your workspace after 30 days (section 11). Legal basis: Art. 6(1)(b) GDPR (providing the widget you asked for).

YouTube: the YouTube widget uses the YouTube API Services and asks Google for read-only access to your YouTube account (scope youtube.readonly). With it we read your channel (ID, name, link, number of subscribers) and your latest public videos (title, description, thumbnail, link, views, length and publication date, up to 10 videos), regularly and only for the channel you connected. We never upload, change or delete anything on YouTube, and we don't read private videos, comments, messages or your watch history. By connecting YouTube you agree to the YouTube Terms of Service; Google processes your data under the Google Privacy Policy. LinkHarbor's use and transfer of information received from Google APIs to any other app adheres to the Google API Services User Data Policy, including the Limited Use requirements. Besides disconnecting in the dashboard, you can revoke our access at any time in your Google account under Security → Third-party apps with account access; the widget then stops updating.

Emails about your account: we send security notices to your account's email address when a new device signs in (section 3), when you switch two-factor authentication on or off, create new recovery codes or sign in with a recovery code, when you create an API key or connect an app (section 9), and when your password is changed, including a reset via the link. If you are the owner or an admin of a workspace, you also get a summary of new form submissions at most once an hour. It only gives the number per form and page, never the content of the submissions. So that no submission is reported twice, we store per account up to which submission the last summary went and when it was sent. If you take part in the partner programme, you get an email as soon as a payout is on its way (section 6). You can switch off the form summary, the payout emails and the new-device notices in the dashboard under Account → Profile → Notifications; each of these emails links there. You always get the other security notices. Legal basis: Art. 6(1)(b) GDPR (providing your account), for the security notices also Art. 6(1)(f) GDPR (protecting your account).

6. Paid plans and partner programme

Upgrading to a paid plan processes your billing address and, where applicable, VAT ID. Payment processing itself runs through Stripe (Stripe Payments Europe, Ltd.), acting as an independent controller for payment data — see Stripe's privacy policy. We never store full card details ourselves.

Partner programme: if you join the partner programme, we process for commissions and payouts your partner code, the account holder, IBAN (stored encrypted and only ever shown shortened), BIC, address, tax status, tax number or VAT ID, the time you accepted the programme terms, and the accounts created through your referral together with the commissions and credit notes they produced. You only see those accounts' email addresses masked in your overview. Legal basis: Art. 6(1)(b) GDPR (taking part in the programme) and Art. 6(1)(c) GDPR (retention duties under tax and commercial law). Commissions and credit notes are kept for the statutory periods; the payout profile is deleted with the final deletion of the account (section 12).

7. Push notifications (optional)

When you sign in to the LinkHarbor app, the app asks for permission to send notifications. If you allow them, we register a device token (Apple/Google) after every sign-in, together with the device's platform, language and time zone; you only get pushes for pages you follow. When you sign out of the app we delete that device's token, and also as soon as Apple or Google report it as invalid. Legal basis: Art. 6(1)(a) GDPR (consent via the operating system's notification prompt; revocable at any time in your device's system settings). There are two layers: an account-wide switch (controls whether push is delivered at all) and, per subscribed page, a switch just for that page — the account-wide switch always takes precedence at delivery time and can mute everything at once. You can change both at any time in the app (Settings and "My subscriptions").

8. Third-party content on published LinkHarbor pages

This is the section that matters most when you're visiting someone else's LinkHarbor page — not just our own. Anyone running a page on LinkHarbor can add content to it that's technically loaded directly from a third-party provider, not from us:

• Video embeds (YouTube via youtube-nocookie.com, Vimeo, Loom) — your browser loads the player as an iframe directly from that provider, but only after you chose "Accept" in the consent banner or "Allow" in the LinkHarbor app (section 4) or clicked "Load content from …" on that single video; nothing is preloaded before that. If you tick "Remember my choice on this page", videos on that page load straight away on later visits; other pages ask again (see section 4). The provider receives your IP address and technical details of your browser and may set its own cookies, independent of our own cookies described in section 4.
• Images — usually uploaded to LinkHarbor and delivered from our own asset storage (Bunny CDN); these always load, without consent. If a page includes images from other websites instead (image block, gallery, link thumbnails and icons, profile, header or logo picture, background image or background video with an external address), your browser loads them directly from that server, and only after your consent (section 4). Until then the image block, gallery, link block and widget show a neutral placeholder with a "Load content from …" button (with the website's name) that loads only that one block's content; external profile, header and background pictures appear after "Accept"; until then the page shows a plain colour instead of an external background or template picture, so it stays readable. In the LinkHarbor app your answer to the app's question counts (section 4): with "Allow" external content loads as after "Accept"; with "Don't allow", and in app versions that don't ask yet, it only loads one item at a time via "Load content from …", and external profile, header and background pictures stay hidden. When loading, the other server receives your IP address and technical details of your browser and may set its own cookies.
• Integration widgets — live content from currently 19 connected platforms: Instagram, TikTok, Spotify, YouTube, Twitch, GitHub, GitLab, RSS / Podcast, Google Places, Yelp, Shopify, WooCommerce, Eventbrite, Ticket Tailor, Ticketmaster, Calendly, Calendar (iCal) (a calendar feed the page owner provides), Careers Page (open positions from the public job board of an applicant tracking system) and match-day data from a sports data service (scores and fixtures, no visitor data). In addition, page owners can send data from their own tools through the Custom (API) interface. This content is shown on the page. Depending on the widget, either our server fetches the data ahead of time (server-to-server — your browser never contacts the provider directly) or your browser loads content such as images and videos directly from the provider, e.g. for Instagram, TikTok, YouTube, Twitch, Spotify, Yelp, Calendly, Shopify, WooCommerce or RSS / Podcast. Such content only loads after your consent or when you click "Load content from …" on that single item; the same applies as for video embeds. Google Places photos (review widget) are loaded through our own server and CDN; your browser does not connect to Google for them, and the page contains no Google API key.
• Donation / support buttons — use Stripe Connect; clicking one leads to a Stripe-hosted checkout, see section 6. For this we store the amount, currency and status of the payment, an optional message to the page owner (at most 280 characters, visible only in the page's dashboard), and the device type, referring site, campaign parameters and country at checkout time. Your name, card and bank details go to Stripe only.

We have no control over these third parties' data processing and can't fold it into our own aggregate analytics. Each third party's own privacy policy applies to that data flow. Responsibility for choosing what content appears on a specific page lies with that page's owner — not with LinkHarbor as the platform.

Forms: if you submit a form on a published page, we store the field values and consent ticks for the page owner, together with the page, time, referrer and campaign parameters, the user agent in plaintext and the IP address only as a keyed hash. The page owner sees the submissions in the dashboard and can export them as CSV (without IP hash and user agent). If the page owner has set up a webhook, field values and consents (not the IP hash or user agent) are also sent to their server. The page owner is responsible for the submissions; we process them on their behalf. See section 11 for retention and section 3 for abuse protection (security log, counters).

9. Recipients / processors

We use carefully selected service providers, with Data Processing Agreements per Art. 28 GDPR in place where required: hosting/infrastructure (our primary servers in Frankfurt am Main, where data is stored and analysed, see section 10), Bunny.net (BunnyWay d.o.o., Slovenia: storage and delivery of uploaded files, and hosting of our worldwide edge servers, see section 10), Stripe (payment processing), an email delivery provider (registration confirmation, password reset and similar transactional email), and Google and Apple (push notification delivery via Firebase Cloud Messaging and the Apple Push Notification service respectively, see section 7), Cloudflare (Cloudflare, Inc.: the proxy with DDoS protection in front of this website, the published pages, the dashboard and the API, which processes IP addresses and request data and may set the security cookies cf_clearance and __cf_bm to protect against attacks, see section 4; also the Turnstile sign-in check in the dashboard, which loads a script from Cloudflare) and OVHcloud (OVH SAS, France: our email mailboxes; if you write to us, your message is stored there and in our own support system). Copies of the access logs and audit records (section 3, IP address and user agent as a hash only, even where the audit record in our database holds the full IP address) and of the security log (section 3, with the IP address in plaintext) also go to our central logging system. DPA available on request for Enterprise customers, with possible modifications.

For push delivery the LinkHarbor app includes Google's Firebase SDK. It contacts Google as soon as the app starts, even before you sign in or allow notifications; Google receives your IP address and technical details about the app installation. We do not use Firebase's analytics or advertising features.

For the strict bot-protection tier our edge servers check IP addresses against a locally stored MaxMind database (GeoLite2-ASN) to recognise traffic from data centres; no data is sent to MaxMind.

If you sign in via OAuth (see section 5), Google or Meta (Facebook) additionally process the account data they hold about you as independent controllers, to the extent you approve sharing it in the OAuth dialog — their own privacy policy applies to that processing, not this one.

Connected apps (AI assistants): if you connect an AI assistant such as Claude or ChatGPT to LinkHarbor through our MCP access, you sign in with us and approve exactly one workspace and the permissions you choose on our consent page. We store the approval (app, workspace, permissions, time of approval and of last use) and the details the app registered with (name, redirect addresses); every access by the app is logged as described in section 3. Within the approved scope the app gets access to that workspace's content, e.g. pages, statistics and — if approved — form submissions. The app's provider is responsible for processing on its side; its own privacy policy applies. You can revoke an approval at any time under Account → Callback & API → Connected apps; it also ends automatically when you change or reset your password, sign out on all devices or delete your account. Legal basis: Art. 6(1)(b) GDPR (a feature you asked for).

10. International data transfers

Primary region Frankfurt am Main (Germany), backups within the EU. Some of the providers listed above (e.g. Stripe, Google, Meta, Apple, Cloudflare) also process data outside the EU/EEA; in those cases we rely on the EU Standard Contractual Clauses or an adequacy decision covering the respective provider.

Published pages and redirects are additionally delivered by our edge servers at locations around the world (see section 9); some locations are outside the EU/EEA. Edge servers accept the encrypted connection and answer the request (to do so, it is decrypted there). Everything that is stored, they transfer, encrypted again, to Frankfurt; data is stored and analysed only there. The only things that stay on the edge servers themselves are their server logs (section 3) and statistics events they could not transfer (section 11).

11. Retention

• Account data: until the account is deleted (section 12).
• Evidence of your acceptance of the terms and this privacy policy and of your marketing choice (section 5): until the account is deleted, then in pseudonymised form for another three years.
• Access logs (section 3): 30 days, including the copies in our central logging system (section 9); there, audit records are deleted after 365 days as in our database, all other application and error logs after 30 days.
• Security log with the IP address in plaintext (section 3): 90 days, including the copy in our central logging system. Server logs of the edge servers: not archived; newer entries continuously replace older ones. Abuse counters: at most one hour.
• Raw click and view events (section 3): 30 days; a reduced copy without IP hash, user agent and full referring URL in our statistics database for up to 35 days. After that only the aggregate figures built from them remain.
• Your choice in the consent banner (lh_consent, section 4): 12 months, only in your browser.
• Visitor ID with the time of the first visit to a page (only with consent, section 3): as long as the workspace's plan shows the statistics history, at least 30 days and at most one year after the first visit (one year is the lifetime of the vid cookie); at once when the page is deleted. If you come back after that, you count as a new visitor.
• Statistics events an edge server could not transfer because they were unreadable or rejected by our primary servers: 7 days after they were set aside on the edge server.
• Internal audit records (who did, published or changed what, with the full IP address of the request, section 3): 365 days; this also applies to the entries on blocked IP addresses and to the proof of email delivery with the recipient address (section 3). Their copy in our central logging system holds the IP address only as a hash and is deleted after 365 days as well.
• Push device tokens (section 7): until you sign out of the app, Apple or Google report the token as invalid, or you delete your account.
• Connected apps (section 9): until you revoke the approval; revoked approvals are deleted 90 days after revocation.
• Known sign-in devices (section 3): 180 days after last use; at once with the account.
• Form summary status (section 5): until the account is deleted.
• Uploaded images and files: until you delete them in the media library. We remove the file itself from storage (Bunny CDN) 90 days later, provided no page still uses it; when the account is finally deleted, all of its files go.
• Form submissions on published pages: for as long as the page owner keeps them. If a form has an automatic deletion period set, older submissions are deleted every night.
• Donations (section 8): as long as the page's workspace exists.
• Partner programme (section 6): the payout profile until the account is finally deleted; commissions and credit notes for the statutory retention periods.
• Invoices: for the statutory retention periods (commercial and tax law) at our payment provider Stripe and in our accounts.

Daily cleanup jobs enforce these periods. They are technical defaults, not a to-the-minute guarantee.

12. Your rights

Access, rectification, erasure, restriction, portability, objection: contact privacy@linkharbor.com. We provide a copy of your data (access, portability) on request; there is currently no export button in the dashboard.

You delete your account yourself in the dashboard or the app, confirmed with your password (instructions: delete your account). This works as long as you don't own a workspace with other members (transfer ownership first) and don't have an active paid subscription (cancel it first). We then immediately end all your sessions and the access of connected apps, take your own pages offline, disable and anonymise your account and delete your personal account data (profile, billing address, two-factor data, push devices, linked sign-ins). We detach the evidence of your consents from your account at once and keep it in pseudonymised form for three years (section 5). The remaining content of your workspaces (pages, forms, files, statistics), a partner programme payout profile and the anonymised account record are permanently deleted after 30 days. They cannot be restored. Invoices, commissions and credit notes are kept for the statutory period (section 11).

13. Right to complain to a supervisory authority

You have the right to lodge a complaint with a data protection supervisory authority — e.g. the Estonian Data Protection Inspectorate (Andmekaitse Inspektsioon, AKI), which is competent for us as an Estonian company, or the authority in your own EU country of residence.

14. Fonts, app and reach measurement

Our three typefaces (Lexend, Public Sans, JetBrains Mono) are self-hosted on this website and in the dashboard from our own server as local files — no Google Fonts CDN, which would otherwise send your IP address to Google on every page load. The LinkHarbor app for iOS and Android, however, downloads its font from Google Fonts servers on first launch and then keeps it on the device; this gives Google your IP address.

To measure reach on this website (linkharbor.com) we use Plausible Analytics, run by ourselves and reachable at ping.linkharbor.com, without cookies and without storing anything on your device; the data goes to no other recipient. It records the page viewed, the referrer and campaign parameters, the country, device type, browser and operating system. The IP address and user agent only go into a daily-rotating salted identifier used to count one day's visits; the IP address and user agent themselves are not stored, and after the day ends the identifier can no longer be linked to anyone. Published LinkHarbor pages and the dashboard do not include this script; for the statistics of published pages see sections 3 and 4. There are no other analytics or tracking scripts on this website. Legal basis: Art. 6(1)(f) GDPR (legitimate interest in privacy-friendly reach measurement of our website).

15. Changes to this notice

We update this notice whenever our processing or the legal situation changes. The current version is always available at this address.