Recipe · E-commerce

Price watch

Opens each product page in this profile's Product watch rows, reads the price and whether the page says it is in stock, and writes both back into the row. The selectors are a guess — every store draws a price differently, so open one of your pages and check them before trusting a run.

On this page

What it does

Walks this profile's watched product pages and writes back the price and whether the page says it is in stock.

It runs against one profile, through that profile's own proxy and with its own cookies — so the pages load the way that account's owner would see them. It navigates, so give it a profile whose session you are happy to have in use.

One profileIts own proxy and cookiesThe Product watch table2 settings on the run

The 10 steps

The real tree, read out of the pack the launcher ships. Indentation is nesting: the steps under a loop run once per row, and the ones under a branch run only when the condition above them holds. Every {{…}} is a value filled in at run time — from the row being walked, from a setting on the run, or from the profile itself.

loadRowsLoad this profile's watch rowsLoad Product watch into rows
evaluateStamp the sweepRun script
loopEach product pageLoop forEach

Each time

setVarForget the previous rowSet watch
gotoOpen the product pageGo to {{loop.item.url}}on failure: continue
waitWait
evaluateRead price and availabilityRun scripton failure: continue
saveRowsWrite the reading backSave to Product watchon failure: continue
screenshotScreenshoton failure: continue
waitWait

Each of those is one of the step types on the automation reference, with the same fields the editor shows and the same fields an agent is handed over the local API.

The tables it uses

These load with the recipe. A dataset is a typed table your workspace owns — the columns are named and typed up front so the steps can address them, and every one of them is yours to rename, extend or fill from a file afterwards.

Product watch

readswrites

One row per product page you are watching. The sweep writes the price and whether the page says it is in stock.

url
URL · url
title
Title · text
price
Price · number
currency
Currency · text
availability
Availability · select · Unchecked | In stock | Out of stock | Unknown page
checked_at
Checked at · datetime
profile
Profile · profile
notes
Notes · longText

Re-running updates the row it already wrote rather than adding a second one. That is what the match column in the save step is for, and it is the difference between a status check and a table that doubles in size every pass.

What it asks you for

Settings are filled in when the run starts, and every profile can hold its own values — which is how one workflow serves a whole folder of accounts.

price_selector
Price selector · text · required

A CSS selector matching the element that holds the price. The default is a guess: it fits pages that publish schema.org markup and nothing else. Open the page, inspect the price, and put the real one here.

title_selector
Title selector · text · required

A CSS selector matching the product's own heading. `h1` is right more often than anything else and wrong often enough to check. It is read into the run log so you can see what the sweep was looking at.

Loading it

In the launcher, open Automations, choose Load a starter pack, and pick E-commerce. Untick anything you do not want. The tables land first, then the workflows, then a project called E-commerce Ops that links them together.

What arrives is an ordinary automation row. Open it in the editor, change a step, rename it, delete it — nothing in the app treats it as special afterwards, and loading the pack a second time makes a fresh copy rather than overwriting the one you edited. Tables are the opposite: an existing table of the same name is reused and keeps its rows.