last updated · 2026-05-11
How nodes work.
A walk through one read — from workspace request to your browser session and back — with the rate, scope, and audit guarantees we make at each step.
The session
When you connect, we establish a LinkedIn session bound to a device fingerprint. We store refresh material encrypted at rest and never write to the underlying account. The session runs from a residential proxy in your declared geography — if you are in Berlin, your node runs from a Berlin IP. We do not move the session.
Pace control
Every node has a per-hour and per-day ceiling. Ceilings are wider than what most human LinkedIn users do, and narrower than what anti-abuse systems flag.
| preset | per hour | per day | quiet hours |
|---|---|---|---|
| conservative | 8 | 80 | 22:00 → 08:00 local |
| standard | 20 | 200 | 23:00 → 07:00 local |
| max | 40 | 320 | configurable |
Scope walls
Three things are structurally impossible — not policy-disallowed, absent from the node binary:
- No POST. The HTTP client is GET-only, enforced at the transport layer.
- No DOM mutation. The session runs headless; there is no input loop.
- No private endpoints. The route table is an allowlist of public paths, signed and shipped per release.
Audit log
Every read appears in your dashboard within 30 seconds: timestamp, path, response size, the workspace it served (anonymized stable hash). Export CSV. We retain 90 days; you can request longer pulls.
You can see everything we did. That is structural — cheap for us, expensive for a scraper to fake. If we silently widen scope, the log says so before PR does.