Cookie Bridge.
Authenticated scraping with zero cookies stored on Stekpad servers. Architecturally, not as a policy.
Most APIs save your cookies. We can’t.
Most scraping APIs let you “save your cookies” so they can scrape behind a login. Convenient — and a four-alarm fire from a security review’s point of view. Your session cookies live on a vendor’s server. Their employees can read them. Their database can be breached. Their logs can be subpoenaed. SSO with hardware keys often breaks anyway.
The Stekpad Chrome extension fetches the authenticated page inside your own Chrome, attaches your existing cookies the way the browser normally would, and posts back the rendered HTML. Stekpad servers never see the cookies. There is no place to store them, by design.
Five steps. Cookies never leave Chrome.
- 01
You call /v1/scrape
Pass `use_session: "stripe.com"` alongside the URL. No cookie data flows in this request.
- 02
Backend pushes a fetch job
A workspace-scoped websocket pushes the URL, actions, and timeout to your Chrome extension. No auth data flows backend → extension.
- 03
Extension fetches in your Chrome
The extension opens the URL in a background fetch context. Chrome attaches its cookies. The page renders.
- 04
Extension posts back HTML
The rendered HTML comes back over the same websocket — only the HTML, never the cookies.
- 05
Backend post-processes
Markdown conversion, JSON extraction, dataset storage, enrichment. Returned to your API call.
What you get.
- Scrape any logged-in page. Stripe dashboard, LinkedIn search, internal CRMs, anything you can reach in your own Chrome.
- No “session save” anywhere. Nothing to revoke from a vendor dashboard. The bridge is per-domain, per-user.
- Works with hardware keys and SSO. The browser does the auth dance, not us.
- Local audit log. Every fetch is recorded in the extension journal. Exportable as CSV. Not transmitted.
curl -X POST https://api.stekpad.com/v1/scrape \ -H "Authorization: Bearer stkpd_live_..." \ -d '{ "url": "https://dashboard.stripe.com/customers", "use_session": "stripe.com", "formats": ["html", "markdown"] }'If the bridge isn’t connected, you get:
{ "error": { "code": "session_unavailable", "domain": "stripe.com", "message": "The cookie bridge for stripe.com isn't connected.", "guidance": "Open Chrome with the Stekpad extension active, or remove use_session from this request." }}Cookie bridge vs server-side cookies.
| Feature | Stekpad | Server-side cookies |
|---|---|---|
| Where cookies live | Your Chrome | Vendor database |
| Vendor employee can read | Never | Yes, technically |
| Survives SSO + hardware key | Often broken | |
| Revoked by closing browser | No, requires dashboard action | |
| Works on a server |
Common questions.
Does the bridge work in CI?
No. The bridge requires a real Chrome with the Stekpad extension installed and a logged-in user. That’s the security model.
Can my whole team use one bridge?
No. The bridge is per-user. That’s how the guarantee survives.
What if I need automated authenticated scraping at scale on a server?
That’s a different product. We don’t offer it because we can’t offer it without storing your cookies. We’re transparent about the tradeoff.
Is the extension open source?
Yes. Read the code on GitHub before installing.
Will async crawls wait for the bridge to come back online?
Yes. Authenticated runs sit in waiting_for_bridge for up to 24 hours and resume automatically when you reopen Chrome.
Scrape behind a login. Without saving a cookie.
Install the Chrome extension, authorize a domain, scrape from your own browser.