Library

Recipes

21 working automations, grouped by the job they belong to. Each one arrives with the tables it reads and writes, loads into your workspace as ordinary rows, and is yours to edit from the moment it lands.

On this page

What a recipe is

A recipe is an automation we wrote for you: a tree of steps run top to bottom against one profile, through that profile's own proxy and with its own cookies. The steps that touch a page run inside the browser session you already have, so a site sees the identity rather than a harness bolted to it.

Most of them are the same shape, and it is worth learning once. The work list lives in a dataset — a typed table your workspace owns. One parameterised automation loads its own profile's rows, walks them, reads each page, and writes a verdict back into the row it came from. Re-running updates rows rather than adding them, so a table that doubles in size is a bug and not a habit.

Which means the addresses come from your rows, never from us. No recipe on this page contains a link to somebody else's site, an API key, a password or a wallet address, and the launcher's own tests refuse to ship one that does.

The 5 packs

A pack is one vertical's worth of it: three to five automations, the tables they use, and a project that holds them together with the written practice that a step engine cannot do for you.

Loading one

In the launcher, open Automations and choose Load a starter pack. Pick the vertical, untick anything you do not want, and load. The tables are written first, then the automations, then a project linking them — in that order, because an automation finds its table by name at run time and a workflow loaded without its table fails on its first run.

Loading again makes a fresh copy of each automation, the way the built-in example does. Tables are the opposite: a table that already exists under that name is reused and keeps every row it holds, because two tables with one name would leave every workflow in the workspace unable to tell them apart.

The project's runbooks are written to that computer only. Teammates see the project and everything linked into it, but not those notes — which reads as a sync failure if nobody says so first.

Everything that lands is an ordinary row. Rename it, rewrite a step, delete it, put it on the calendar — with the one caveat that a schedule entry fires only while the launcher is open, and a slot it was closed for is marked missed rather than caught up later.

What they do not do

A recipe is a starting point, not a finished integration, and two things about that are worth reading before the first run.

The selectors are guesses.Where a recipe reads a table off somebody else's page, the row selector arrives as a parameter with a default that fits an ordinary table and will not fit every site. Open the page, check it, and expect to set it once. A template that pretended to know a particular platform's markup would be wrong for everyone else and, within a month, for that platform too.

Nothing acts on your behalf at the point that matters. The workflows read pages and file what they find. Where one fills a form that moves money, it stops at the confirmation screen and hands it back to you — no step in any pack types a two-factor code, and that is not a limitation waiting to be lifted.

They also stay inside the rules of whatever you are running. Argus separates accounts you are entitled to hold — a second account a platform permits, separate brands, separate clients, separate regions. It does not make an account you are not allowed to hold into one you are.

Start from one

The packs ship inside the launcher. Nothing to install, nothing to import — open Automations and pick one.