Automation

Automation repeats a task you have already done by hand, in profiles you control. It drives a real browser through the same proxy and fingerprint as a normal launch.

Recording

Pick the profile to record in, press Record, do the task in the browser that opens, then Stop & Save. The recorder captures the steps into the same shape you would build by hand, so a recorded macro opens in the editor like any other.

Two honest limits: selectors are worked out from the page heuristically, so check them in the editor before a large run, and navigation inside single-page apps may not be captured as its own step.

The step types

13 of them: goto, click, type, keypress, scroll, wait, move, hover, select, waitFor, submit, check, clear.

The step types: table

Step	Fields
goto	url
click	selector
type	selector, value
keypress	key
scroll	steps (optional)
wait	ms
move	selector, or x and y
hover	selector, ms (optional)
select	selector, value, by: auto, value, label or index
waitFor	selector, state: visible or hidden
submit	selector, a form, or any field inside one
check	selector, state: checked or unchecked
clear	selector

Every step that targets an element also takes a timeout in milliseconds and can be marked optional. An optional step that fails is logged as skipped and the run carries on. That is how “fill this in only if the site shows it” is expressed. A normal step that fails is logged and the macro moves to the next one.

Running across profiles

The Parallel Runs tab takes one macro, a selection of profiles and a concurrency from 1 to 10.

• Profiles already open are reused; the ones the run opens are closed when it finishes.
• Bind a .xlsx, .xls and .csv file and each row goes to one profile, in order. Use a column name in double braces inside a macro’s url or value field, those two fields only. Extra profiles run without values.
• The run console shows each profile as queued, launching, running, passed or failed. It never carries typed values, cookies or credentials.
• Macro runs, parallel runs and cookie warm-ups land in Task History, which keeps the last 50 with their status.

Schedules run a macro on chosen profiles every set number of minutes, for as long as the app is open. There is no content calendar and no queue.

Cookie Warmer

The warmer opens a list of ordinary sites in the selected profiles for a set number of seconds each, either just browsing, clicking at random or following links. It can loop until stopped, or run without windows. Cookies and cache stay in each profile, and the console reports how much landed on disk.

Local API

Off until you turn it on in Settings, under Developer API Access. It listens on 127.0.0.1, port 8080, and answers only requests addressed to your own computer.

Local API: table

Route	Auth	Returns
GET /api/v1/health	None	A status check
GET /api/v1/profiles	API key	Profile configurations
POST /api/v1/profiles/:id/start	API key	ok, profileId, sessionId, wsEndpoint

Generate a key in the same settings area. Keys start sg_, are shown once, and are stored only as SHA-256 hashes; Settings shows when each was last used, and you can revoke it.

curl -X POST http://127.0.0.1:8080/api/v1/profiles/42/start \
  -H "Authorization: Bearer sg_…"

The response carries a wsEndpoint, which you attach to:

const browser = await puppeteer.connect({ browserWSEndpoint: wsEndpoint });

A key opens every profile. Keys are not tied to a member or a role, so anyone holding one can list and start every profile in the workspace. Keep them out of shared scripts and revoke the ones you no longer use.

Requests without a valid key get a 401. Requests whose Host header isn’t 127.0.0.1 or localhost are refused, which stops a web page from reaching the API by pointing its own domain at your machine.

What isn’t here

No hosted runner, no cloud scheduler, and no extraction: automation drives the browser, and what you do with what appears is your own code’s job. Runs are Chromium sessions only.