The webSlinger Workflow

Plan → Record → Generate → Execute

Every webSlinger automation follows the same four-step flow. You never write a line of code — you describe what you want, show webSlinger how to do it, and let it handle the rest.

Step 1
Plan

Set the starting URL, describe the task in plain English, and define your goals — what to input, what to extract, and any key navigation steps.

Step 2
Record

Perform the task in your browser. webSlinger replicates every action in a validation tab in real time, confirming it can navigate, fill forms, and extract data as you demonstrate.

Step 3
Generate

Select one or more session maps. Review the matched inputs and outputs. webSlinger's LLM generates a complete automation script that handles your entire dataset.

Step 4
Execute

Run the script manually or put it on a schedule. It runs in your own browser with your cookies and credentials — no bot detection, no cloud infrastructure.

Step 1: Plan — Writing Goals

Before recording, you define session goals — a short specification of every input and extraction in your workflow. Goals stay visible as a checklist in the webSlinger overlay during recording, so you always know what's left to demonstrate.

The four goal types:

input: variableName - description of what this input represents
extract: variableName - description of what to collect
array: arrayName (field1, field2, field3) - repeating structure to extract
navigate: description of a navigation step to include as a reminder

Goals also guide the script generator. The LLM sees your goals when generating the script and uses them to understand what the automation is supposed to accomplish.

Tip: Use camelCase for variable names (e.g., fromDate, invoicePrice). This is a convention, not a requirement, but it keeps your outputData consistent.

Step 2: Record — The Session Map

When you activate the extension, webSlinger opens your starting URL and begins recording. Everything you do — clicks, form fills, navigation, data designations — is captured in a session map.

A session map is not a script. It's a structured record of your demonstration: which elements you interacted with, what selectors were proven valid, and what data was extracted. One session map can be combined with others to automate complex multi-site workflows.

You save the session map when you're done recording. It's stored on the server and available for script generation.

Step 3: Generate — Script Wizard

The script generation wizard walks through four steps:

  1. Select session map(s) — choose one or more recorded sessions as the source
  2. Name and describe — give the script a name; optionally add guidance to the task description before generation
  3. Review metadata — verify that inputs and extractions are matched correctly to your goals; adjust assignments if needed
  4. Input structure — mark any inputs that should be treated as arrays (lists of values to loop over); click Generate

Generation takes one to two minutes. The result is a complete JavaScript automation script, ready to run.

Step 4: Execute

Select the script on the Automation page, upload your input data file (a JSON file matching the template webSlinger provides), and click Ready. Activate the extension to start.

The script runs in two automation tabs in your browser. You can watch it work or minimize the window — either way, the results download automatically when it finishes.

To run on a schedule, see Scheduled Execution.

Side-by-Side Validation

Proven While You Record

Most automation tools record your actions and hope they work on replay. You discover broken selectors during execution — often when you're not there to fix them.

webSlinger takes a different approach. A second browser tab — the validation tab — programmatically replicates every action you take in the main tab, in real time. You see immediately whether webSlinger can navigate as you navigate, fill forms as you fill them, and extract data from the same elements you designate.

Main Tab — Your workspace

You interact normally with the website. webSlinger captures every click, form fill, and navigation event as you work.

Validation Tab — webSlinger's proof

webSlinger replays every action programmatically. If it succeeds here, the selector is proven and saved. If it fails, you know immediately.

Follow the Leader

The validation tab follows main tab navigation with only a few tens of milliseconds of latency. This is a novel capability and the core around which webSlinger is built.

Once the main tab overlay is visible and the tab is stable, you can navigate in the main tab and the validation tab will follow almost instantly — replicating your action using robust selectors generated from the current page state. If the navigation fails, you'll know immediately and can try a different approach.

If the tabs ever get out of sync, clicking the refresh button in the main tab overlay will re-synchronize them.

The Validation Log

The webSlinger overlay in the main tab includes a validation log at the bottom. Every action produces a log entry with the outcome of each action in green when sucessful and in red when not.

How Validation Works

As soon as the validation tab is stable, sets of selectors for all the interactive elements on the page are generated. When you interact with an element on the main tab the features of that element are used to find the corresponding set of selectors for the validation tab. Those selectors that successfully find the target element are saved and one is used to replay the action in the validation tab.

During automation execution, all retained selectors vote on which element to interact with. The element with the most votes wins. This voting-based consensus is what makes webSlinger automations resilient. There's no untested primary selector with untested fallbacks, but rather a set of context-based selectors that have already been tested on the validation tab.

Result: Multiple selectors for each element you interact with are proven valid during the recording session and vote during automation.

Extract Structured Data

Array Extraction — Entire Arrays in One Action

Click the Arrays button and webSlinger automatically detects every repeating structure on the page — product cards, order histories, search results, data tables. Each detected array is numbered and its instances are labeled.

Right-click an instance to open the field selection panel. You see every field webSlinger detected across all instances, with occupancy percentages (how many instances contain each field) and sample values. Check the fields you want. Click Record.

That's it. One interaction captures a structured extraction for every instance on the page.

Hover to preview: After recording an array extraction, hover over the validation log entry to see a tooltip with the complete extracted data for all instances — so you can verify the extraction before generating any script.

What webSlinger Can Detect

Lists and Card Grids

Product listings, search results, news feeds, job postings — any repeating div-based structure where each instance has a similar layout.

Tables

HTML tables and data grids, including those with header rows that label each column. Column labels become field names automatically.

Dynamic Class Names

React and Vue components often generate class names that encode data values. webSlinger's partition merging handles this, recognizing structurally equivalent fields even when their classes differ.

Paginated Data

Data loaded in batches via "Load More" or infinite scroll is automatically merged into a single logical array, even when it spans multiple container elements in the DOM.

Extraction and Script Generation

Extraction goals you defined during planning are matched to the fields you demonstrated during recording. The script generator sees both and produces code that loops over the structure, navigates to detail pages if needed, and organizes the output exactly as you specified.

For complex cases — like Amazon invoices with variable numbers of items per order — demonstrate two or three examples with different structures. See Intelligent Generalization for how webSlinger handles variation.

Automate Logins with MFA

The Problem with Credential Automation

Every other automation tool either stores your passwords in the cloud (a significant security risk) or gives up entirely on sites that require multi-factor authentication. Banking portals, brokerage accounts, government websites — the most valuable automation targets — are exactly the ones that use MFA.

webSlinger handles MFA natively, and does it without your credentials ever leaving your machine.

The keyCocoon + keyBunker System

webSlinger's companion extension, keyCocoon, handles all credential entry. It communicates with keyBunker — a native application that stores your credentials in an encrypted vault on your local machine.

Zero-Knowledge Architecture

Your passwords and TOTP secrets never leave your machine. webSlinger's server never sees them. keyCocoon retrieves credentials from keyBunker over an encrypted local channel, decrypts them for sumbission via the webpage, then immediately expunges them from memory.

Time-Bound Authentication

You authorize keyCocoon by entering your keyBunker master password and setting a session duration — from 5 minutes to 24 hours. After the authorization window closes you will be promted again. You can schedule credential-requiring automations to run unattended within the authorization window.

Supported MFA Methods

TOTP (Authenticator App)

keyBunker stores your TOTP secret key and generates time-based one-time passwords identical to those produced by Google Authenticator or Authy. When the automation reaches a TOTP field, keyCocoon retrieves a fresh code from keyBunker and fills it in automatically.

Email-Based MFA

For workflows that send a code to email, webSlinger coordinates across two automation tabs, one holding the login session and one navigating to the email service to retrieve the code. To make this work you would record two session maps; one for interacting with the site, and one for interacting with your email service — searching for the email containing the code and extracting it. The script is generated using both session maps.

Recording a Credential Login

During recording, when you reach a password field, click the Input button on the overlay and right-click the password field. Instead of typing a value, choose Authenticate with keyCocoon. keyCocoon retrieves the password from keyBunker, fills it in, and submits — all without the value ever appearing in the webSlinger session map.

The same process applies to TOTP fields: right-click, choose Get TOTP Code from keyBunker, and the code is generated and entered automatically.

Note: Password submission happens in the main tab only. Since all recording tabs share the same browser session, logging in once covers both the main and validation tabs.

Build Robust Automations

Why Automations Break — and How webSlinger Prevents It

Conventional automation tools store a single selector per element. When a website updates its layout, changes a class name, or shifts a button's position, that selector breaks. The automation fails, silently or with a cryptic error, and you spend time debugging instead of getting work done.

webSlinger takes a fundamentally different approach at every layer.

Voting-Based Selector Consensus

For every element you interact with during recording, webSlinger stores up to ten independently proven XPath selectors. These aren't a primary selector with fallbacks — they are peers, each proven valid against the live page during recording.

During automation execution, every selector is evaluated and each one votes on which DOM element to target. The element with the most votes is used. A selector that produces a different result is effectively outvoted. This consensus approach means that minor page changes — a new class here, a reordered sibling there — affect only a few selectors without breaking the automation.

Feature Based Selectors

webSlinger builds selectors based on features. It does not use positional selectors except as a last resort.

These selectors are inherently more robust than positional features even without the redundancy.

Anchor State Optimization

During recording, a third tab — the copy tab — tests whether each page state can be reached by direct URL navigation. States that pass this test become anchor states: starting points that the automation can navigate to directly, skipping unnecessary intermediate steps. (See Three-Tab Architecture for details on how this works.)

This makes generated scripts shorter and more reliable. Fewer clicks means fewer things that can go wrong.

Multi-Session Composition

Complex workflows sometimes span multiple websites or require switching between contexts mid-task. webSlinger supports combining multiple session maps — recorded separately — into a single generated script. This is how email-based MFA workflows are built: one session map for the primary site, another for the email service.

Avoid Anti-Bot Detection

The Problem with Cloud-Based Automation

Cloud automation tools — Playwright running in a data center, headless Chrome on a remote server — operate from IP addresses that anti-bot systems recognize. Cloudflare, reCAPTCHA, PerimeterX, and similar systems fingerprint the browser, check TLS profiles, analyze mouse movement patterns, and compare the request's origin against known automation infrastructure. They catch most cloud-based bots reliably.

webSlinger doesn't have this problem because it isn't a bot.

Your Browser Is Your Automation

webSlinger runs inside your actual Chrome installation, with your real browser profile. The automation uses:

  • Your actual cookies and active sessions
  • Your hardware fingerprint (canvas, WebGL, fonts)
  • Your real TLS profile and HTTP/2 settings
  • Your IP address and network characteristics
  • Your existing login state — so MFA isn't triggered by a "new device"

From the website's perspective, there is no meaningful difference between you using the site and webSlinger using it on your behalf. Because there isn't one.

Trusted-Mode Interaction

Some sites detect automation by examining whether browser events carry the isTrusted flag — a property that indicates whether an event was generated by a real user interaction or synthesized by JavaScript. Standard automation tools produce untrusted events.

webSlinger uses Chrome's extension APIs to dispatch trusted events where the site requires it. These events are indistinguishable from genuine user input at the browser level. When a site requires trusted mode, you enable it with a checkbox on the webSlinger overlay for that page.

What This Means in Practice

No "New Device" Alerts

Banks and brokerages recognize your session because it is your session. No suspicious login notifications, no forced re-verification, no lockouts.

No Cloudflare Blocks

Sites protected by Cloudflare's bot management see a legitimate Chrome session from a known user. The challenge page never appears.

MFA Works Naturally

Sites that trigger MFA for new devices or suspicious logins don't trigger it for webSlinger — because your hardware and session are already recognized.

No Infrastructure Management

No proxy rotation, no browser fingerprint spoofing, no residential IP pools. The solution is simpler: run in your actual browser.

Intelligent Generalization

The Rosetta Stone

Ask an LLM how to log into a bank, download transactions, and export them as a CSV. It will tell you exactly what to do — navigate to the login page, enter your credentials, find the accounts section, select the date range, click Export. The steps are correct. The problem is that the LLM has no idea how to execute any of them on your specific bank's website. It doesn't know what selector identifies the username field, which button triggers the export, or how the date range inputs are structured.

LLMs know what to do. They don't know how to do it.

The session map is the Rosetta Stone that bridges this gap. By demonstrating the workflow in your browser, you produce a structured record that translates the LLM's abstract understanding of the task into the concrete, proven selectors and navigation steps specific to that website. The LLM reads the session map alongside your task description and goals, and generates a script that knows both what to do and exactly how to do it — on that site, with those elements, in the order you demonstrated.

Show It Once. It Does the Rest.

Traditional automation requires you to handle every variation explicitly: if the page looks different, add a condition; if the data structure changes, update the selector; if there are ten items instead of three, modify the loop. You're programming, not demonstrating.

webSlinger uses an LLM to bridge the gap between your demonstration and a complete automation. You show it one or two examples — enough to convey the pattern — and the generated script handles your entire dataset.

Array Inputs — One Recording, Unlimited Runs

When you demonstrate a workflow on one item (one city, one product, one invoice), you can mark the input variable as an array during script generation. The LLM generates a script that loops over a list of input values and performs the full workflow for each one.

Your input data file contains the list. Change the list, re-run the script — no re-recording needed.

Example: Record looking up the temperature for Memphis. Mark cityName as an array input. Run the script with a list of 50 cities. webSlinger visits AccuWeather for each one and returns a structured JSON file with all 50 temperatures.

Handling Variation — Multiple Examples

For more complex targets — like invoice pages where different orders have different numbers of items — demonstrate two or three examples that cover the variations you expect. An invoice with one item, one with three items, one with four items across two delivery dates.

The LLM sees all three examples in the session map and generates a script that handles variable structures correctly. It extrapolates the pattern, not just the specific cases you demonstrated.

Real result: The Amazon invoice tutorial demonstrates three example invoices. The generated script correctly extracted all 86 orders across nine pages, with varying item counts and payment cards, on the first run.

Scheduled Execution

taskSpinner — Your Local Automation Scheduler

Once you have a working automation script, you can run it on a recurring schedule using taskSpinner — a native Windows application installed alongside webSlinger that integrates with the Windows Task Scheduler.

No cloud infrastructure required. No serverless browser instances to manage. No recurring API costs for keeping a browser alive in the cloud. Your machine runs the automation, on your schedule, using your browser.

How It Works

When a scheduled task fires, taskSpinner launches a Chrome window in the background — minimized, so it doesn't interrupt what you're doing — loads the webSlinger extension, and executes the specified script with the provided input data.

The automation runs to completion, the output downloads automatically, and the window closes. You keep working. The results are waiting for you when you're ready for them.

Example: On the last day of the month before you leave work, authorize a keyBunker authentication session for 12 hours and schedule a bank transaction download for 7 AM the next morning. The script runs within the authentication window, logs in, downloads the prior month's transactions, and logs out. The results will be waiting for you when you arrive.

Setting Up a Scheduled Task

Scheduled tasks are configured from the webSlinger website. Select the script, provide the input data, set the schedule (one-time, daily, weekly, or monthly), and save. taskSpinner picks up the configuration and registers the corresponding Windows Scheduled Task.

taskSpinner must be installed and running for scheduled execution to work. It is included in the webSlinger Windows installer package.

Share Your Scripts

Contribute to the Community

Every script in your library is shown on the Script Management section of the Automate page. Each script has a Contribute button that submits it to the shared webSlinger script library, making it available to other users.

Contributed scripts contain no credential information — credentials are always supplied locally by the recipient's own keyCocoon and keyBunker installation at execution time. What you're sharing is the automation logic and the proven selectors for that website.

All contributions are curated before being added to the shared library to verify they are safe and perform as described.

Why Share?

A script you recorded for your bank's transaction export might work identically for someone else at the same bank. A script for extracting data from a public website is immediately useful to anyone who needs the same data. Contributing costs nothing and saves other users the time of recording and generating their own version.

The shared library grows with the community — the more users contribute, the more automations are available to everyone without anyone needing to start from scratch.

API Discovery

Coming Soon

API Discovery is planned for a future release. The description below reflects the intended design.

The Data Behind the Page

As you interact with a website, the page is continuously receiving structured data — search results, map pins, listings, prices — delivered via API calls that happen behind the scenes. This data is often richer and more complete than what ends up rendered as visible text. Data used to populate maps is a prime example: the coordinates, names, and attributes of every pin on the map exist in the API response, but none of it appears as selectable text on the page.

API Discovery will learn the API calls triggered by your actions as you navigate. webSlinger will then validate that it can make those same calls — with configurable input data — and retrieve the structured data directly from the source.

Data You Can't Get Any Other Way

Some data simply isn't accessible through DOM extraction. If a site renders results as map markers, chart data points, or dynamically positioned elements with no readable text, conventional scraping comes up empty. API Discovery targets the underlying data feed directly, giving you the complete structured dataset regardless of how — or whether — it's presented visually on the page.

Shadow DOM Support

Coming Soon

Shadow DOM Support is planned for a future release. The description below reflects the intended design.

The Shadow DOM Problem

Modern web components increasingly use the Shadow DOM to encapsulate their internals — hiding their elements from standard DOM queries and making them invisible to most automation tools. Selectors that work on regular page elements fail silently when the target is inside a shadow root, with no obvious indication of why.

As more sites adopt web components, Shadow DOM boundaries are becoming one of the most common obstacles to reliable automation — and one of the hardest for users to diagnose or work around on their own.

What You'll Be Able to Do

Shadow DOM Support will extend webSlinger's recording, validation, and extraction capabilities across shadow boundaries transparently. Sites built with web components will work the same way as any other site — you interact with the elements you see, webSlinger handles the complexity underneath. No knowledge of Shadow DOM required.

Integrate Agentically

Coming Soon

Agentic integration is planned for a future release. The description below reflects the intended design.

webSlinger as an Agent Tool

AI agents are becoming capable of reasoning through complex multi-step tasks — but they still struggle with reliable web interaction. Agents that try to control a browser directly face all the same anti-bot, selector fragility, and credential management problems that human-written automation faces, compounded by the cost of calling an LLM on every step.

webSlinger's approach — record once, execute deterministically — is a natural fit for agent tool use. An agent can trigger a webSlinger automation, pass inputData, and receive structured outputData, getting reliable web execution without per-step LLM cost.

The Vision

Planned agentic integration will expose webSlinger scripts as callable tools through a standard API. An agent that needs to "download my bank transactions for last month" can invoke the corresponding webSlinger script as a tool call, receive the structured output, and continue its reasoning — without needing to understand how the browser interaction works.

This combines the LLM's ability to reason about what needs to happen with webSlinger's proven, validated, human-fingerprinted execution of how to make it happen. The agent thinks; webSlinger acts.