The same readings the panel shows, delivered machine to machine: stock levels per variant, prices, the units worked out from the drops, and events. Pull them from the API, or have a webhook reach you the moment something changes. No signing in, no clicking through reports, no export to a spreadsheet.
There is no off-the-shelf price, because it depends on how many shops, how often and how much of the data. Tell us what you want to pull and one reply comes back with the scope and the price.
Every one of these is already collected for the panel. The API is not a separate product with separate data; it is a different way of receiving the same checks.
The number of units of every variant at every check. Where a shop publishes an exact count, you get the exact count. Where it publishes only "in stock" or "last few left", you get that, plus a plain statement that it is not a counter.
Units worked out from the drops in stock, and revenue at that day's price. Daily, broken down by variant, by product and by shop.
The price of every variant at every check, with the price it was reduced from where the shop shows one. The whole history of changes, not just today's figure.
Products and variants with name, size or colour, page address and the shop's own identifier. You can see what has joined the catalogue and what has left it.
Sold out, restocked, reduced, product withdrawn. The same things the panel draws on a timeline. The one dataset worth taking as a webhook, because what matters is the minute you find out.
The shop's campaigns and creatives on Meta, Google and TikTok: what is running, since when, and what it says.
The search terms a shop ranks for and where it ranks. Plus reviews, the technologies the shop runs on, and its social profiles.
Some chains publish stock separately for each physical store. For those you get the breakdown by location as well as the total.
* The per-store breakdown exists only for chains that publish it, and how much advertising data is available differs between Meta, Google and TikTok. The quote says plainly what is achievable for your shops and what is not.
The API is usually the answer when the data has to land in a system that already exists, or when there are too many shops for anyone to look at them one at a time.
Competitors' stock and sales next to your own figures in Looker Studio, Power BI or Metabase. One place where you compare yourself with the market instead of two windows side by side.
A competitor's variant price, refreshed every two hours, as an input to your own rules. With the stock level next to it, because the price of something nobody can ship is not competition.
A webhook straight into Slack, n8n or Make, with nothing polling us in a loop. A competitor's bestseller going out of stock is a reason to spend on ads the same day, not a line in Monday's report.
A history of stock and prices is ready-made input for a demand model. The same dataset is what an agent needs to answer questions about the market with figures.
An estimate of a brand's or a whole category's sales, worked out the same way across many shops at once. A fund or an adviser gets a measurement rather than the seller's own claim.
Collect for several clients and put the data into your own reports. One set of credentials, as many shops as you like, your logo on the result.
You say which shops, which datasets and how often. Before anything is agreed on paper, we establish for free whether those shops can be read at all.
The same run and the same validation. A run that looks suspicious never becomes data, which is why a figure from the API matches the figure in the panel.
Two routes, and you can use both. Pull when you want the whole state of a catalogue; or give us an address and a webhook goes out after every run and on every event, whether that is a sell-out, a restock or a price cut. The key is yours and you can replace it whenever you want.
The documentation comes with the credentials. It is not published, because the shape of the response and the list of events we send as webhooks are settled around what you actually receive.
Four things worth knowing before the conversation about price rather than after the first month.
Stock levels cannot be reconstructed backwards. The earlier a shop is connected, the longer the history you have later.
Sales are worked out from drops in stock. For a shop that publishes exact numbers it is very close to the truth. For a shop that shows only "in stock", we say we do not know instead of writing a zero.
We have no access to anyone else's admin panel, orders or customers' personal data, and we do not deal in them. We read a shop the way a buyer reads it.
Rather than promise the data and deliver empty fields, we say so before quoting. The check is free and ends in a clear answer.
The starting point is the ordinary monitoring rate card: catalogue size against how often it is checked. The API is not a separate fee for having credentials.
Every shop is priced on its own, because the cost depends on how hard it is to read.
Between two and twelve hours. More often means more precise and more expensive, because it is more work on every shop.
Stock and prices are one thing. Advertising, search visibility and reviews are extra datasets and extra work.
Billing is prepaid and in USD, exactly as monitoring in the panel is. You pay for successful checks: a day on which we could not read the shop is not charged.
A list of shops and one sentence about where the data is going is enough. We come back with the scope, the price and a date.
We answer by email, usually within one working day.