Authenticated scraping without sending us your cookies.
Your session cookies never leave your browser. Architecturally, not as a policy.
Cookies never touch our servers.
Not encrypted on our servers. Not in our logs. Not in our database. Not even briefly. The Chrome extension is the only piece of Stekpad that can see them, and it lives on your machine.
Three steps. One websocket.
- 01
You call /v1/scrape
Your code POSTs to /v1/scrape with use_session: "stripe.com". The request contains the URL, the actions to run, the domain hint, and your API key. No cookies, no auth headers — we never ask for them.
- 02
Extension fetches in your Chrome
Our backend pushes a fetch job over a workspace-scoped websocket to your extension. The browser fetches the page, attaches its own cookies as it normally would, runs the actions, and posts back the rendered HTML.
- 03
Backend post-processes
We turn the HTML into markdown, run JSON extraction, store the row, run any enrichers — and return the result to your API call. The only artifact stored is the rendered content you asked for.
What the call looks like
curl -X POST https://api.stekpad.com/v1/scrape \ -H "Authorization: Bearer stkpd_live_..." \ -H "Content-Type: application/json" \ -d '{ "url": "https://dashboard.stripe.com/customers", "use_session": "stripe.com", "formats": ["html", "markdown"] }'The data flow, both directions.
Here is exactly what is on the wire — and what is not.
Your code → Stekpad backend
- • The target URL
- • The actions to run
- • A
use_sessiondomain hint - • Your API key
Extension → Stekpad backend
- • The rendered HTML
- • Optional screenshots
- • The final URL after redirects
- • A
cookies_used: falseflag
Mutual auth on the websocket.
The extension signs every websocket message with a device key generated at install time, bound to your workspace's API key. Every fetch_job is logged in the extension's local journal and in the Stekpad Run log — no hidden fetches.
- Device-key signing. Generated on install, bound to your workspace's API key.
- Per-domain authorization. Every domain is added explicitly, per user, in the extension popup. Default OFF.
- Two-sided revoke. Kill a domain from the extension popup or the web app. Both are pushed instantly to the other side.
- Open source extension. Read the code. The entire bridge is < 2,000 LOC.
When the bridge isn't connected.
Stekpad never fakes the data. If the extension is offline, the call fails loudly with a structured error and the exact next step.
- Sync calls return a
session_unavailableerror with the exact next step. - Async crawls and extracts enter a
waiting_for_bridgestate and resume automatically when the extension reconnects, up to a 24-hour TTL. - The dashboard shows a banner: "X pending runs waiting for bridge — domains: stripe.com, linkedin.com".
Cookie bridge questions, answered.
Can Stekpad employees see my cookies?
No. They never reach Stekpad servers. There is no place to look at them, by design.
Does the bridge work in headless Chrome / on a server?
No. The bridge requires a real Chrome with the Stekpad extension installed and the user logged in. That is the point — the cookies live in your Chrome, not anywhere else.
Does the bridge work for OAuth-only sites?
Yes, as long as your Chrome has a valid session cookie for the target. The bridge does not care how you obtained the session.
Can I add domains for my whole team?
Each user adds their own domains to their own extension. The cookie bridge is fundamentally per-user — that is how the security guarantee survives.
Is this slower than server-side scraping?
Slightly. The websocket round-trip plus your local Chrome render adds ~500–1500 ms compared to a Cloudflare Browser Rendering fetch. For authenticated pages, this is the only honest path.
Scrape logged-in pages. Keep your cookies.
Install the extension, add a domain, call /v1/scrape with use_session.