Help

Workflow Step Reference

Reference for the standard workflow editor, including step behavior, common options, and where each step fits best.

Workflow Basics

Common ideas used across many steps.

Variables

Many steps can save output into variables like page_text, job_link, or llm_output. Those values can be reused in prompts, formatted text, tool inputs, endpoint calls, and loop conditions.

{{job_title}}
{{page_text}}

Selectors

Many interaction and extraction steps target page elements with a CSS selector so the workflow can act on exactly the right field, button, or region.

input[name="email"]
button[type="submit"]
.jobs-easy-apply-modal

nth and mode

Some steps support mode: nth to use one matching element, mode: all to use every matching element, and n or nth to choose which match to use. 0 means the first match.

Muted Steps

Muted steps stay in the workflow for editing and testing, but they are skipped during run and test execution.

Loop Steps

Start Loop and End Loop let a workflow repeat a block of steps until a stop or continue condition changes.

Extract Steps

Read the page without changing it.

These steps are mainly used for extraction, summaries, and building structured context for later workflow actions.

Extract Values

Extract one kind of value from matching elements, such as links, image URLs, text, form values, HTML, or a custom attribute.

Best for

  • Collecting result links
  • Pulling image sources
  • Getting visible text from repeated elements

Important options

  • source: href, src, text, value, html, or a custom attribute
  • mode: all or nth
  • unique: remove duplicates
  • absolute_url: convert relative URLs to absolute URLs
  • save_as: store the result

Extract Cards

Extract structured data from repeated card-like elements using a JSON field definition.

Best for

  • Search results
  • Job cards
  • Product lists
  • Repeated content blocks

Important options

  • selector: card container selector
  • fields_json: extraction map for fields inside each card
  • mode: all or nth
  • save_as: store the structured array

Get Content

Get readable page content, usually as markdown-like text, optionally scoped to one part of the page.

Best for

  • Page summaries
  • Content extraction
  • Feeding an LLM with readable page text

Important options

  • selector: optional scope selector
  • mode: all or nth
  • include_images: include image references
  • save_as: store the content

Get Inputs

Extract the visible inputs on the page, including labels and metadata.

Best for

  • Understanding forms
  • Building autofill logic
  • Sending form structure into an LLM step

Important options

  • scope_selector: limit extraction to one area
  • include_iframes: include iframe content when possible
  • include_hidden: include hidden inputs
  • save_as: store the payload

Extract Element

Extract a single element or matching elements in one of several output formats.

Best for

  • Getting plain text
  • Capturing markup
  • Pulling a compact or detailed JSON overview of a section

Important options

  • property: text, html, overview, or essentials
  • mode: all or nth
  • n: which match to use in nth mode
  • save_as: store the result

Extract Full HTML

Capture a page-level snapshot in HTML or JSON-oriented formats.

Best for

  • Full-page inspection
  • Debugging extraction issues
  • Sending a broader page snapshot downstream

Important options

  • output: full HTML, sanitized HTML, JSON full, JSON compact, or controls-only JSON
  • Include toggles for header, body, footer, modals, inputs, upload targets, nav buttons, and iframes
  • inputs_view: grouped or flat input formatting
  • save_as: store the snapshot

Wait for Selector

Wait until a selector appears on the page or times out.

Best for

  • Waiting for a section to load
  • Waiting for results after navigation
  • Waiting for modals, forms, and buttons

Important options

  • selector: required
  • timeout_ms: how long to wait

Interaction Steps

Change the page by clicking, typing, or selecting.

Click

Clicks a target element.

Best for

  • Buttons
  • Links
  • Tab controls
  • Modal actions

Important options

  • selector
  • nth
  • trusted
  • humanize, mode, move_first, pre_click_wait_ms
  • block_file_chooser

Type

Types text into a field.

Best for

  • Form inputs
  • Search boxes
  • Textarea entry

Important options

  • selector: required
  • text: required
  • text_format: plain, markdown, or html
  • clear
  • press_enter

Push Key

Presses a keyboard key, optionally against a targeted element.

Best for

  • Tabbing through forms
  • Enter / Escape / Arrow keys
  • Keyboard-driven UI actions

Important options

  • selector: optional
  • nth
  • key: required
  • repeat
  • delay_ms

Select Option (native)

Selects an option in a native HTML <select> control.

Best for

  • Standard dropdowns
  • Native select menus

Important options

  • selector: required
  • value: value, label, or text to choose

Timing, Debug, And Data Steps

Pause runs, format data, and generate decisions.

Wait (ms)

Pauses the workflow for a fixed time.

Best for

  • Waiting for animation or UI settle
  • Adding a small delay between steps
  • Giving uploads or transitions time to finish

Important options

  • ms: required duration in milliseconds

LLM Step

Sends a prompt to the configured LLM and returns the response.

Best for

  • Summaries
  • Decisions
  • Classification
  • JSON generation
  • Turning page data into workflow instructions

Important options

  • prompt: required
  • system: optional
  • temperature
  • max_tokens
  • endpoint, model, api_key
  • save_as

Format Text

Builds a string from a template using workflow variables.

Best for

  • Prompt assembly
  • Endpoint payload text
  • Creating reusable formatted blocks

Important options

  • template: required
  • source_var: optional
  • save_as

Run Steps JSON

Runs a JSON array of steps generated elsewhere.

Best for

  • LLM-generated workflows
  • Dynamic step execution
  • Applying a tool-generated step list

Important options

  • source_var: variable containing steps JSON
  • steps_json: inline JSON step list
  • per_step_delay

Tools, Control Flow, And Integration

Use built-in tools, loops, and external integrations.

Run Tool

Runs one of the built-in tools or playbooks from inside a workflow.

Best for

  • Mixing higher-level browser tools into a normal workflow
  • Reusing tool behavior without rebuilding it step by step

Important options

  • tool_name: required
  • Current options include Application Runner, LinkedIn Easy Apply, Google Search, Get Youtube Content, Auto Form Fill, Auto Upload, Smart Button Click, Page Understanding, Page Section Focus, and Detect Form Errors
  • source_var
  • include_vars
  • save_as

Some tools show additional tool-specific fields in the editor based on the selected tool.

Start Loop

Marks the start of a loop block.

Best for

  • Repeating a set of steps
  • Pagination flows
  • Iterative modal flows
  • Retry logic

Important options

  • loop_name: optional label
  • max_iterations: safety limit

End Loop

Marks the end of a loop block and decides whether to stop or continue.

Best for

  • Ending a repeat cycle based on workflow state
  • Stopping when a variable becomes truthy, empty, equal to a value, and so on

Important options

  • loop_name
  • stop_var, stop_operator, stop_value
  • continue_var, continue_operator, continue_value
  • wait_ms
  • Operators include truthy, falsy, empty, not_empty, equals, not_equals, contains, not_contains, greater_than, less_than, length_equals, length_greater_than, and length_less_than

Call Endpoint

Runs one of the saved custom endpoints configured in the plugin.

Best for

  • Sending data to your own APIs
  • Calling reusable backend operations
  • Mixing browser automation with external services

Important options

  • endpoint_id: required saved endpoint
  • Reference fields show the endpoint parameters, inputs, and output mapping

Screenshot

Takes a screenshot of the current page.

Best for

  • Debugging
  • Capturing proof of state
  • Saving visual checkpoints

Important options

  • path: optional save path
  • full_page: capture the full page instead of just the viewport

Inject Values

Writes values into page inputs using a structured payload rather than manual typing.

Best for

  • Bulk form fill
  • Applying tool-generated fill plans
  • LLM-generated locator/value payloads

Important options

  • payload: required object or array of values to inject
  • debug: emit extra debug information

Upload File(s)

Uploads one or more files into a file input.

Best for

  • Resumes
  • Cover letters
  • Attachments
  • Any file upload field

Important options

  • selector: target upload input or control
  • use_input_type_file: use input[type=file] directly
  • paths: URL(s) or JSON array of file paths/data sources
  • wait_ms: delay after upload
  • close_key or close_button_text: optional close action after upload

Endpoints Help

Saved endpoints and the Call Endpoint step.

Endpoints are reusable HTTP request templates managed in the plugin and then called from workflows. They are the bridge between browser automation and external APIs or backend services.

What Endpoints Are

An endpoint is a saved HTTP request template that you can reuse inside workflows. Instead of rebuilding the same API call every time, you create it once in the Endpoints tab and then call it from any workflow with the Call Endpoint step.

  • Send page content to your own API
  • Call a Python or Node backend
  • Trigger resume rewrite or content generation services
  • Mix browser automation with external systems

How The Endpoint Flow Works

At runtime, the workflow only picks a saved endpoint. The plugin loads the saved request definition, resolves variables into the request, sends it, parses the response, and can store the selected result back into workflow variables.

  • Create and save an endpoint definition
  • Workflow reaches a Call Endpoint step
  • Step looks up the saved endpoint by endpoint_id
  • URL, headers, body, and response path are resolved with current variables
  • Plugin makes the request and parses the response
  • Selected output is optionally saved using the endpoint output_var

Endpoint Fields

Each saved endpoint definition has a small set of core fields that control request behavior and response handling.

  • Name: human-readable label used in the picker
  • URL: request target, with variable interpolation support
  • Method: POST, GET, PUT, PATCH, or DELETE
  • Headers JSON: request headers as a JSON object
  • Body JSON: JSON request body for methods that allow one
  • Response Path: dot-path to select one nested value from the response
  • Timeout (ms): request timeout
  • Input Variables: reference list of expected workflow variables
  • Output Variable: workflow variable name where the selected result is stored

Variable Interpolation

Endpoints support variable interpolation in url, headers_json, body_json, and response_path. The plugin resolves templates using the current workflow variables before the request is sent.

{{page_output}}
{{job_title}}
${page_output}

How Call Endpoint Works In Workflows

The Call Endpoint step is intentionally simple in the workflow editor. It mainly shows the saved endpoint picker plus reference information. At runtime, the endpoint definition does the heavy lifting.

  • Load the selected endpoint
  • Attach current workflow variables
  • Resolve URL, headers, body, and response path
  • Send the request
  • Parse the response
  • Save selected output into the endpoint output_var when configured

Typical Workflow Example

A common pattern is extracting browser content, passing it to an API, then saving one returned value for later steps.

  • Get Content saves page_output
  • Call Endpoint picks Resume Rewriter
  • Endpoint body uses {{page_output}}
  • Endpoint response returns a rewritten file URL
  • response_path selects url
  • output_var stores the result as resume_url
  • Later workflow steps use {{resume_url}}

Testing And Importing

The endpoint editor includes tools for validating requests before they are used in production workflows.

  • Test resolves variables using Test variables JSON and shows status, resolved URL, response path, selected output, and raw response
  • Paste cURL parses a curl command and attempts to fill URL, method, headers, and body automatically
  • Always review imported body format, authorization headers, and inferred method

Response Handling And Errors

When an endpoint succeeds, the plugin keeps the response in several forms internally. For workflows, the most important part is the selected output and whether it is stored into output_var. If the request fails, the Call Endpoint step fails the workflow.

  • Internal response forms include HTTP status, raw text, parsed JSON, and selected response_path value
  • Common failures include invalid JSON, missing endpoint, invalid URL, HTTP errors, timeout, and network failure
  • If the request succeeds, the result can be logged and saved as a variable

Best Practices

Saved endpoints work best when they are treated like reusable building blocks instead of one-off request snippets.

  • Keep endpoint names clear and purpose-driven
  • Treat input_vars as documentation for future-you
  • Use response_path when you only need one nested value
  • Use output_var when later workflow steps depend on the result
  • Test the endpoint before using it in a production workflow

API Help

How the browser connector API works.

The API is the bridge between external systems and the live connected browser plugin. It is designed for curl, n8n, Python, and similar integrations that need to run workflows or tools in a real browser session instead of a server-only environment.

What The API Does

The plugin API lets external systems call into the connected browser plugin to check browser status, list workflows, and run saved workflows or built-in tools. It does not run against a server-only browser session. Instead, it routes commands into the real browser instance currently connected for that user.

  • Check whether a browser is connected
  • List saved workflows
  • Run a saved workflow
  • Run built-in tools through the connector examples shown in the plugin
  • If no browser is connected, browser actions cannot run

Two Different Connector Buttons

There are two connector-related controls in the plugin, and they do different jobs. One controls live connector ownership, and the other only shows usage examples.

  • Top bar Connect / Disconnected button: claims or releases connector ownership for the current browser
  • Workflow or tool Connector button: opens a usage modal with API payload shape plus curl and Python examples
  • Signing in does not automatically connect the browser
  • The usage helper does not connect the browser by itself

Basic Integration Flow

A normal API setup starts in the plugin, then hands off to curl, n8n, Python, or another service using the generated request examples.

  • Log in to the plugin with your NodeCodeStudio account
  • Click Connect in the top bar on the browser that should own the connector
  • Copy or generate your API key from the plugin
  • Use the Connector button on a workflow or tool if you want a ready-made example
  • Send requests to the connector API from curl, n8n, Python, or another service

Authentication And Base URL

The connector API uses the run API key header. The hosted connector URL used by the plugin examples points at the NodeCodeStudio browser connector service.

X-Run-API-Key: your_key_here

https://nodecodestudio.com/browser-connector

GET /health
GET /workflows
POST /run

Main API Endpoints

Most integrations only need three routes: health checks, workflow listing, and workflow or tool execution through the connected browser.

  • GET /health: check whether the connector sees a connected browser for the requested account or session
  • GET /workflows: return saved workflows for the connected account
  • POST /run: run a workflow, tool, or direct payload through the connected browser
  • Workflow variables are commonly flattened as variables.some_name in connector examples
curl -H "X-Run-API-Key: your_key_here" \
  https://nodecodestudio.com/browser-connector/health

curl -H "X-Run-API-Key: your_key_here" \
  "https://nodecodestudio.com/browser-connector/workflows?include_steps=1"

curl -sS -X POST https://nodecodestudio.com/browser-connector/run \
  -H "Content-Type: application/json" \
  -H "X-Run-API-Key: your_key_here" \
  --data-raw '{
    "workflow_name": "My Workflow",
    "variables.input_text": "Example value",
    "timeout_s": 180
  }'

Using The Workflow And Tool Connector Buttons

The Connector button on workflows and tools is the fastest way to get a working request example. It shows the payload shape, required fields, and copyable curl or Python examples built around the current workflow or tool.

  • Workflow Connector button shows expected workflow name, variables, curl example, and Python example
  • Tool Connector button shows tool-specific input fields and copyable examples
  • Useful when a workflow has several variables and you do not want to build the payload by hand
  • Useful when you want the exact workflow name or tool field names the API expects

Single-Browser Connection Limitation

Only one browser connection should be active per user account at a time. You can be signed in on multiple browsers, but only one should own the live connector session that receives API runs.

  • If a second browser connects with the same account, it can take over connector ownership
  • The previous browser may be disconnected and returned to an idle state
  • Keep one browser connected for execution and use others for editing only when needed
  • Only click Connect on the browser that should receive API runs

Live Browser State Limitations

API runs execute against the real connected browser session, so results depend on what that browser is doing at that moment. This is powerful, but it also means the API depends on live page state instead of a detached server session.

  • The browser must be actively connected, not just signed in
  • Results depend on the current page, login state, and UI state of the browser
  • If another browser claims connector ownership, this browser can be disconnected
  • In-progress expectations about where runs execute may change if ownership moves

Troubleshooting And Best Practices

Most connector issues come down to browser ownership, missing variables, or the target page not being in the expected live state. Start with health checks and connector ownership before debugging deeper run failures.

  • Use GET /health before debugging more complicated run failures
  • Confirm the top bar shows Connected on the intended execution browser
  • Check that the workflow name matches exactly and required variables were included
  • Treat the connected browser as the active execution environment for that account
  • If you use multiple browsers with the same login, reconnect the intended owner whenever control changes

Legacy Notes

Hidden or older commands

The runtime still supports some older or less commonly used commands for backward compatibility, but this help page focuses on the standard steps exposed in the workflow editor for normal workflow creation.