The cheapest way to run scrapers that don't break.
Most extraction tools run an LLM on every request. SelectorLock runs deterministic CSS selectors on the happy path, and only calls an LLM on the rare request where a target site's DOM actually changed — then writes the fix back, so that repair is billed once, not on every call after. Bring your own proxy: no markup on bandwidth, no markup on tokens.
What a repair looks like:
How it works
- 1. Register a scraper
Give it a name and a field map of CSS selectors. Leave the URL blank to use it as a template against a different page every call. You get back a
scraperId. - 2. Extract
Call
/v1/extractwith the scraperId and your own proxy credentials. If the stored selectors still match, you get data back immediately — no LLM involved. - 3. Self-heal, permanently
If the site's DOM drifted, a repair pass finds the right elements, returns healed data, and persists the corrected selectors on the scraper — the next call already uses them, automatically.
One API call
curl https://api.selectorlock.com/v1/extract \
-H "x-api-key: $API_KEY" \
-H "content-type: application/json" \
-d '{
"scraperId": "scr_...",
"proxy": { "url": "http://user:pass@your-proxy-provider.com:8000" }
}'{
"status": "ok",
"healed": true,
"data": { "title": "Wireless Mouse", "price": 29.99 },
"updatedSelectors": { "title": ".product-title", "price": ".price" },
"scraperId": "scr_..."
}Don't want to register anything upfront? Selectors can be sent inline as fields instead of a scraperId — useful for one-off scripts, but without write-back there's nowhere to persist a repair. See the docs for both shapes.
Compatible proxy providers expose an HTTP-proxy-over-HTTP(S) endpoint (e.g. Bright Data, Oxylabs, Smartproxy, Webshare, IPRoyal). Providers that only support raw TCP CONNECT tunneling from a desktop HTTP client are not currently supported — check yours with Test a proxy before you integrate.