Compliance

Public data, user-as-principal capture, DSR + suppression by default.

LinkFetch is built on three commitments:

  1. Public data only. We never read anything you couldn't read by visiting a profile while signed in to LinkedIn.
  2. User as principal. Profile, company, post, group, search, and outbound endpoints all run inside the end user's own signed-in LinkedIn session — through the LinkFetch Chrome extension. LinkFetch the service never logs in to LinkedIn on your behalf.
  3. Provenance by default. Every row carries source, fetched_at, freshness_days so you can build agent workflows for regulated customers without an opaque-data audit hole. See Provenance.

This is what hiQ v. LinkedIn settled into: scraping public-page data on behalf of an authenticated user is fine; impersonating LinkedIn with fake accounts is not.

Data subject rights (DSR)

LinkFetch honours the European GDPR right to erasure (Art. 17), the California CCPA right to delete, and the equivalent Brazilian LGPD right.

Self-service

Email privacy@linkfetch.io with the profile URL or vanity slug to suppress. Within 30 days:

  • The profile is removed from the cache.
  • The slug is added to a permanent suppression list — re-fetches return 410 gone, including via the extension capture path.
  • Any cached search results, post reactors, or company-employee rows referencing the profile are scrubbed.

Programmatic

Pro-tier customers and above can call the suppression endpoint directly:

curl -X POST https://api.linkfetch.io/v1/compliance/suppress \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  --data '{"url":"linkedin.com/in/example","reason":"dsr"}'

We respond with the suppression hash and the date by which all downstream caches will have purged. Suppression is permanent and irreversible — design accordingly.

What we don't do

  • We don't run automated headless LinkedIn accounts. Read endpoints resolve through the user's own session via the extension; the Jobs scraper only hits the public-guest /jobs/view/<id> paths.
  • We don't sell data — we sell typed access to data that is already public to a logged-in viewer.
  • We don't keep a "people database" you can browse outside the context of an explicit lookup. Profile lookups debit credits and are logged per request id, per API key.
  • We don't store LinkedIn session cookies on our infrastructure. They stay in the browser.

Data retention

ClassRetention
Cached profiles, companies, posts, groups30 days, then re-fetched on next access
Jobs dataset rowsUntil the underlying job is closed by the employer + 90 days
Request logs (request_id + params)90 days
Credit-ledger entries7 years (financial requirement)
Suppression listPermanent (that's the point)

DPA, SOC 2, sub-processors

Pro and Scale tiers ship with a DPA on request. We are SOC 2 Type II in progress (target completion 2026-Q3).

Sub-processors:

VendorPurpose
AWS (us-east-1)Hosting, primary Postgres, object storage
PaddleMerchant of Record for billing
CloudflareDDoS / WAF on the API edge
ResendTransactional email

Email security@linkfetch.io for the SOC 2 readiness packet, the DPA template, or the current sub-processor list.

Acceptable use

The LinkFetch terms forbid:

  • Using LinkFetch to build a scraper-style "lead list" decoupled from a user-authorised lookup.
  • Sending unsolicited outbound DMs at scale (we already block strangers' DMs at the API level — no first-degree, no message).
  • Impersonation, harassment, or any content that would violate LinkedIn's own community rules.

We will close accounts that violate these. Email info@linkfetch.io before scaling outbound volume so we can size the limits to your use case.