How RolodexIn treats LinkedIn
Read the page you are on, never act on your behalf, never write anything into it, and never take people in bulk. Plus the one disclosure that argument does not cover.
Anyone who has looked at a browser extension for LinkedIn has met the same category of tool: it connects for you, messages for you, scrapes a few hundred profiles overnight, and gets its users' accounts restricted. The objection to installing anything of that shape fires before the install click, and it should.
So here is what RolodexIn does, stated as constraints rather than as promises.
It reads the page you are looking at
The extension reads the profile or the list of people already rendered in your browser, on a page you navigated to yourself. It calls no LinkedIn API. It reads no LinkedIn session cookie and no authentication token. There is no background crawler, and there is nothing that runs while you are not there.
It never acts on your behalf
No auto-connect, no auto-message, no auto-like, no form submission. Nothing in the extension clicks anything. Every action LinkedIn sees is one you took yourself, because the extension is incapable of taking one.
This is the line the tools that get people restricted are on the wrong side of, and it is worth being precise about why the difference is real rather than rhetorical: automation is about the outbound side, and RolodexIn has no outbound side at all.
It never writes into LinkedIn's page
Every piece of RolodexIn's interface lives in a shadow root of our own, appended to the page. LinkedIn's own nodes, styles and layout are never modified — no overlays on their cards, no injected buttons, no per-row controls in their markup. The panel sits beside their page rather than inside it.
The capture list is the clearest case. On a search results page it does not decorate LinkedIn's rows; it lists the people it found in our panel, with our Save buttons.
It takes people one at a time
There is no select-all, no save all, no capture-on-scroll, and no batch write path. There is no bulk-create endpoint on the server, which is the version of this claim that cannot be walked back by a UI change later.
The same rule holds on reads, which is less obvious and mattered more than we expected. A row in the capture list has to know whether you already hold that person — and asking the server once per person listed would itself be a bulk pattern. So it is answered locally: a list of your own contacts' profile slugs, fetched in one request for the whole account, plus whatever is already cached. The search box inside that panel filters the people found on the page, locally, for the same reason.
One exception, and it is not hidden
There is exactly one thing RolodexIn writes without a click, and it is worth stating rather than burying: when someone you already hold appears in a capture list, the stored URL of their profile photo is refreshed. Those URLs are LinkedIn's own and they expire, so the alternative is not fewer writes — it is a contact whose face silently disappears. It creates nothing, it touches one field no user action can set, and it is capped at ten per page.
And one disclosure that none of the above covers
Photos are hot-linked, never copied. avatar_url holds the signed URL LinkedIn
served, and your browser loads the image from LinkedIn's CDN at render time. We
fetch no image bytes, proxy nothing and store no pictures — the alternative would
have the server make a request per person and put us in the business of storing
someone else's assets.
The cost of that choice is real and belongs in plain sight: because your browser loads those images, LinkedIn's CDN sees a request per face you render — including from the dashboard, an origin that otherwise tells them nothing. By IP and timing they can infer when you open it and roughly how many contacts you hold. Two mitigations are in place: no referrer is sent with those image requests, and images load lazily, so a fifty-row page requests only the faces you actually scroll to.
That is a narrowing of private by default, accepted deliberately because the alternative is worse on the same terms. It is written up in full on the privacy page, which is the page that has to stay true rather than persuasive.
Why any of this is our problem
Two reasons, and only one of them is about rules.
The first is that a tool which gets your account restricted is worthless regardless of what it does when it works. Your LinkedIn account is the asset; the annotations are a layer on top of it.
The second is that the constraints above are also what makes the product private. Something with no outbound side, no bulk path and no server-side image fetching has very little it could leak even if it wanted to. The design that keeps you out of trouble with LinkedIn and the design that keeps your notes yours turn out to be the same design.
RolodexIn is an independent product and is not affiliated with LinkedIn — the footer of every page here says so, and it is not boilerplate: the constraints above are ours to keep, not theirs to enforce on us.