Kimono Labs Alternative: Rebuilding a Point-and-Click Scraper

1.What Kimono actually did

The workflow was three steps. You loaded a page in Kimono's browser extension, clicked the elements you wanted, and named them. Kimono inferred CSS selectors from your clicks, generalised them across repeated elements so clicking one product row captured all of them, and published the result as a hosted JSON endpoint on a schedule you chose.

The genuinely clever part was generalisation. Clicking a single price and having the tool correctly infer "every price in this list" removed the step where non-programmers gave up. Everything downstream — fetching, parsing, scheduling, hosting the endpoint — was conventional; the interface is what made it feel like magic.

Understanding this matters for rebuilding it, because it tells you which part you actually need. The scheduling and hosting are commodity today. What you are replacing is selector authoring plus a fetch layer that reaches the page at all — and in 2026 the second half is much harder than it was in 2015.

2.The failure mode that outlived the product

Selectors inferred from clicks are brittle in a specific and dangerous way: when a site redesigns, the selector stops matching and the extractor returns nothing. Not an error — an empty field, in a successful response, on a schedule that keeps running.

The pipeline reports healthy. Requests complete, the endpoint responds, the row count may even stay constant if the container still matches. What changed is that a field that used to hold a price now holds null, and nobody notices until someone downstream asks why the dashboard flattened three weeks ago.

Any rebuild has to solve this or it recreates the problem with a newer logo. The fix is not better selectors — it is asserting on output. Every extraction should validate that required fields are present and non-empty, and fail loudly when they are not. That single discipline is worth more than any amount of selector cleverness.

3.Why the fetch half got much harder since 2016

Kimono operated in a web where fetching a page was mostly solved. Most sites served complete server-rendered HTML, anti-bot systems were rarer and simpler, and a hosted service could fetch from its own datacenter IPs without much friction.

Both halves of that changed. Client-side rendering became the default for exactly the commercial sites people most want to extract, so the HTML a plain fetch returns is often an empty shell. And anti-bot scoring at the TLS and ASN layers became routine, so a datacenter fetch is frequently rejected before the HTML question arises.

This is the real reason no one rebuilt Kimono as-is. The interface was never the expensive part; the fetch layer was cheap in 2015 and is expensive now. A modern equivalent has to sit on top of infrastructure that handles rendering and unlocking, which is why the sensible rebuild is a thin tool over an API rather than a standalone product.

4.Rebuilding the workflow in three parts

Selector authoring is the part you keep from Kimono, and browser DevTools does it well enough. Right-click an element, copy the selector, then simplify it by hand — prefer a stable data attribute or a semantic class over a long descendant chain, because auto-generated selectors encode DOM structure that changes on every redesign.

Fetching and extraction collapse into one API call. OmniScrape's css_selectors parameter takes a map of field name to selector and returns the results in data.css_extracted, so there is no parser to maintain in your code at all. Add js_wait_selector when the content renders client-side, so extraction happens after hydration rather than against an empty shell.

Scheduling is whatever your stack already has — cron, a workflow runner, a serverless timer. This is the part that genuinely became commodity, and it is not worth adopting a product to get.

Click-to-JSON, rebuilt as one request

bash

123456789101112131415curl -X POST https://api.omniscrape.io/v1/scrape \
  -H "Content-Type: application/json" \
  -H "X-API-Key: ${OMNISCRAPE_KEY}" \
  -d '{
    "url": "https://shop.example.com/category/headphones",
    "mode": "auto",
    "enable_solver": true,
    "js_wait_selector": ".product-card",
    "css_selectors": {
      "title": ".product-card h3",
      "price": ".product-card .price",
      "availability": ".product-card .stock-label"
    }
  }'
# Results arrive in data.css_extracted — no parser to maintain.

5.The assertion Kimono never had

Wrap every scheduled extraction in a check that required fields are present and non-empty, and raise when they are not. This is roughly ten lines and it converts the silent-null failure into a loud one you find the same day rather than the same quarter.

Assert on shape as well as presence. A price field that suddenly contains a cookie banner's text is technically non-empty and completely wrong; a cheap type or pattern check catches it. Row count is worth watching too — a category page that returned forty products yesterday and returns two today has not lost thirty-eight products.

Keep the raw HTML for failed extractions. When a selector breaks, the fastest fix is looking at what the page actually returned, and re-fetching later gives you the post-redesign page rather than the one that broke.

Fail loudly instead of storing nulls on a schedule

python

123456789101112131415161718REQUIRED = ("title", "price")

def assert_extraction(payload: dict, min_rows: int = 1) -> dict:
    if not payload.get("success"):
        raise RuntimeError(payload.get("error", "unlock failed"))

    fields = payload["data"].get("css_extracted") or {}
    for key in REQUIRED:
        value = fields.get(key)
        # Empty is the silent failure Kimono users lived with. Make it loud.
        if value is None or value == "" or value == []:
            raise RuntimeError(f"selector for '{key}' matched nothing — site likely redesigned")

    rows = fields.get("title")
    if isinstance(rows, list) and len(rows) < min_rows:
        raise RuntimeError(f"row count collapsed to {len(rows)}")

    return fields

6.If you genuinely cannot write code

Kimono's real audience was people who did not program, and it is worth being honest that an API is not a replacement for them. If that describes you, the visual-scraper category — desktop tools with point-and-click selector builders — is closer to what you want than any API will be.

Their trade-off is the mirror image: the interface is friendlier, and the fetch layer is weaker, because they run from your own machine and IP. On protected targets they hit exactly the wall described above, and most of them cannot get past it at any price.

The hybrid that works reasonably well is using a visual tool to author selectors and an API to do the fetching, with a small script joining the two. It is not no-code, but it is far less code than building a scraper, and it puts the hard half on infrastructure that is maintained for you.

Frequently asked questions

What happened to Kimono Labs?

Kimono Labs was acquired by Palantir and the hosted service shut down in early 2016. A desktop version was released around the shutdown, but the hosted click-to-API product that people remember has not been available for years.

Is there a direct Kimono replacement?

Nothing occupies exactly that position, and the reason is structural. Kimono's interface was the cheap half; the fetch half was easy in 2015 and is expensive now that client-side rendering and anti-bot scoring are standard. Modern equivalents are thin tools over a scraping API rather than standalone products.

How do I get click-to-JSON behaviour today?

Author selectors in browser DevTools, then pass them as css_selectors on a single API request. Results come back in data.css_extracted with no parser to maintain. Add js_wait_selector when the page renders client-side.

Why did my selector-based extractor silently return nulls?

Because a selector that stops matching returns nothing rather than raising. The request succeeds, the schedule keeps running, and empty fields accumulate. Assert that required fields are present and non-empty on every run so the failure is loud.

Is an API right for me if I do not write code?

Probably not on its own — that was Kimono's actual audience and an API does not serve it. Visual scrapers are closer, though their fetch layer is weaker on protected sites. Using a visual tool for selectors and an API for fetching is the practical middle ground.

Related guides

Ready to scrape without blocks?

Published unit rates, clear plan limits, and billing tied to successful work. No hidden fees and no guessing what a scrape will cost. Free trial credit on signup. No credit card required.