Compliance
Public data, user-as-principal capture, DSR + suppression by default.
LinkFetch is built on three commitments:
- Public data only. We never read anything you couldn't read by visiting a profile while signed in to LinkedIn.
- 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.
- Provenance by default. Every row carries
source,fetched_at,freshness_daysso 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
| Class | Retention |
|---|---|
| Cached profiles, companies, posts, groups | 30 days, then re-fetched on next access |
| Jobs dataset rows | Until the underlying job is closed by the employer + 90 days |
Request logs (request_id + params) | 90 days |
| Credit-ledger entries | 7 years (financial requirement) |
| Suppression list | Permanent (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:
| Vendor | Purpose |
|---|---|
| AWS (us-east-1) | Hosting, primary Postgres, object storage |
| Paddle | Merchant of Record for billing |
| Cloudflare | DDoS / WAF on the API edge |
| Resend | Transactional 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.