watch the number, not the page

Price monitoring API that tells your code the moment a price moves.

A price monitoring API checks the pages that carry a price on a schedule and reports the move as structured data. Verid takes any public product page, marketplace listing, pricing page, distributor catalogue, fare page or JSON price endpoint, extracts the price and the fields around it with CSS, XPath, regex, JSONPath or an LLM prompt, compares each check against the last, and fires an HMAC-signed webhook when the move clears the threshold you set. Down to every five minutes, across up to 1,500 pages on the Scale plan.

It is price tracking as an event rather than a report. A cut arrives as price 49.99 to 44.99, which a repricing service can act on inside the hour. It does not arrive as a row in a dashboard that somebody opens on Monday.

Track your first price free See a JSON price monitor Read the quickstart

5 monitors free, no card
4 numeric threshold rules
5 min fastest check
one POST to start

retailer.example/p/cordless-drill-18v3 sellers · hourly

price: 49.99→44.99; Δ -10.0%
shipping: 0.00→4.95; under rule
availability: in stock→in stock; unchanged

last 24 checkswebhook 200

the price under watchthe band you setΔthe move, as data

Straight answers

Price monitoring API at a glance

Twelve answers with no adjectives in them. Every number is read from the shipping product rather than from a sales sheet, and the ones that differ by plan say which plan. Row five is the one that decides whether your first monitor works, and the parsing table takes it apart properly.

What it ischange detection: Scheduled change detection pointed at a price, with the numeric move and the alert as the product rather than the page.
What it is notno repricer: Not a repricing engine and not a product catalogue. Nothing here sets your price, matches a SKU across retailers, or discovers listings you did not name.
Inputurl + fields: A public URL and one selector per field: the price, and usually the list price, the currency and the availability beside it.
Outputprice diff: A JSON webhook holding the previous price, the current price and the field names that moved. The full body is printed below.
The number ruleparseFloat: Numeric predicates read the field with parseFloat. 39.00 works, 39.00 USD works, $39.00 is NaN and 1,299 is 1. The parsing table below is the whole story.
Threshold rules4 numeric rules: Four numeric predicates: decrease and increase, by percent or by absolute amount. Nine rules in total once regex, exact value and composite are counted, and all nine are tabled below.
Extraction methods6 methods: CSS, XPath, regex, JSONPath, whole page text, or an LLM prompt with a response schema. One method per monitor, so a page read two ways is two monitors on the same URL.
Fastest check5 min on Scale: Set per monitor in seconds and floored by your plan: daily on Free, every two hours on Lite, hourly on Starter, 15 minutes on Pro. Every floor is on the pricing page.
Scale unit1,500 pages: One monitor per watched page, not per price. Five on the permanent Free plan, 25 on Lite, 50 on Starter, 250 on Pro and 1,500 on Scale, which is 1,500 product pages checked as often as five minutes apart.
Where alerts land4 channels: Signed webhook, Slack, Discord or email, capped per monitor by plan from one on Free to 25 on Scale. See notifications.
Delivery guarantee6 attempts: Six attempts spread across roughly four hours, each signed with HMAC-SHA256, then the dead letter queue for a manual replay.
Price history24 months: Every run stores the extracted object, from 14 days on Free to 24 months on Scale. There is no price chart here, and the durable series is the one your own handler writes.

Where a price lives

Retail, marketplace, B2B and SaaS price monitoring, page by page

Price monitoring is usually sold as a retail product, which quietly leaves out most of the prices a business actually cares about. A distributor break price, a fare for a fixed date, a partner API rate and a rival plan tier are all prices on public pages, and all four monitor the same way. Below is every surface worth watching, with the fields to name and an interval that matches how fast the number really moves.

Page types that carry a price, the fields to extract from each, and a suitable check interval
Surface	What moves there	Fields	Interval	What the change tells you
Retail product page	The sale price, the struck list price, the promotion badge and the stock line.	price, list_price, availability	Hourly	A markdown you can match today rather than notice at the end of the week.
Marketplace listing	The buy box price, the seller behind it, and the delivery charge underneath.	price, seller, shipping	Every 15 minutes	A competing seller taking the box, which is a price move and an inventory move at once.
SaaS pricing page	Tier prices, per-seat prices, the annual discount and the number of plans.	entry_price, seat_price, annual_discount	Hourly	A repricing or a repackaging you are about to be compared against in a deal.
Distributor or B2B catalogue	Break prices per quantity, the minimum order, and the lead time beside them.	price_qty_1, price_qty_100, moq	Daily	An input cost moving before your supplier gets around to telling you.
Reseller and MAP listing	The advertised price on each authorised reseller page you name.	advertised_price, seller	Every 6 hours	A reseller drifting below the advertised floor, on the page a customer actually sees.
Hotel, flight or ticket fare	The fare for a fixed date and occupancy, and the fare class attached to it.	fare, fare_class, currency	Every 15 minutes	A fare window opening, which is a decision with a very short shelf life.
JSON price endpoint	Whatever the API returns: unit price, rate, tier, quota cost.	data.price, data.currency	Every 5 minutes	A supplier or partner repricing an API you are billed against.
Ticker or rate page	A spot rate, a commodity quote, an exchange rate, a token price.	rate, updated_at	Every 5 minutes	A threshold crossing on a number that nobody is going to email you about.

One product, every seller

8 monitors

A single SKU sold by eight resellers is eight monitors, one per reseller page, and they all deliver into the same endpoint. Five of the eight fit the permanent Free plan; all eight fit the $9 Lite plan at 25, with room for two more products beside them.

A working competitive shelf

40 monitors

Forty products across a handful of rivals is forty monitors, which is Starter at 50 and an hourly floor. Most teams start with the twenty products that carry the margin rather than the whole catalogue, because a monitor you cannot explain gets muted.

A category, checked every five minutes

1,500 pages

Two hundred and fifty product pages is Pro, and 1,500 is Scale with a five minute floor. Both are page counts rather than request counts, so the arithmetic stays the same whether a page changes daily or never.

One check, five stages

How a price monitor works, end to end

Every check is the same five steps, and each one hands the next a smaller object than it was given: a page, then an object, then a list of field names, then one boolean, then one request. Stage two is where price monitoring differs from every other kind, and it is where almost every broken monitor is broken.

Point a monitor at the page that shows the price
One monitor per product page, pricing page, listing or fare. The URL is whatever a customer would open, and the interval is set per monitor in seconds, floored by your plan at daily on Free and five minutes on Scale. Pages that assemble their price in JavaScript get fetch_mode set to browser and load in real Chrome instead of an HTTP client, which is most retail product pages and nearly every marketplace listing.
takesa URL and a cadencegivesone monitor per pageurl + interval
Extract the price as a number, not as a price tag
This is the step that decides whether the rest works. A CSS selector returns the visible text of the node it lands on, so a node reading $39.00 gives you the string $39.00, and the numeric rules read it with parseFloat, which returns NaN on a leading currency symbol and 1 on a thousands separator. Land the selector on a node holding the digits alone, or pull the digits out with a regex capture group, and keep the currency in its own field.
takesthe rendered pagegivesa price that parsesextract_config
Compare it against the last check
The new object is compared key by key with the object stored for the previous run of this monitor. What comes out is the list of field names that moved plus the before and after value of each. A price that held is not in that list, which is why a quiet check costs you nothing to read.
takesa price that parsesgivesthe field level difffields_changed
Gate it on a move worth waking for
One predicate decides whether the change deserves anybody. Four of the nine are numeric: a fall or a rise, measured as a percentage or as an absolute amount. A five percent decrease rule ignores the cent that moved when a currency converter refreshed and fires when somebody made a pricing decision. A run that fails the predicate is still recorded in full, it just does not deliver.
takesthe field level diffgivesone booleandiff_predicate
Deliver it to the system that acts on price
A qualifying change leaves as an HMAC-signed POST carrying the previous price, the new price and the field names that moved, and to Slack, Discord or email at the same time if a human needs it too. That payload is enough for a repricer to recalculate, for a warehouse row to be appended, or for an agent to answer a question about a competitor price without fetching the page again.
takesone booleangivesa signed webhook, or a quiet rundeliveries

The anatomy of a price

What to extract from a product page, and how to reach it

A price monitor with one field is a price monitor you will not trust in a month. The number alone cannot tell a markdown from an out of stock listing, a genuine cut from a raised list price, or your rival undercutting you from a different merchant winning the buy box. Six fields cover all of it, and the drawing shows where each one sits on an ordinary retail page.

extracted object, one run6 fields

01price:"44.99"numeric string

regex"price":"([0-9.]+)"

02list_price:"59.99"numeric string

css.price--was

03currency:"USD"string

css[itemprop="priceCurrency"]

04availability:"In stock"string

css.stock-state

05seller:"Northgate Supply"string

css.offer__merchant

06data.price:44.99number

json_path$.data.attributes.price

An extract_config names exactly one method, so the six fields above are three monitors on the same target: the CSS group, the regex group, and the JSONPath one that only applies when the target is a JSON endpoint.

price

regex

The field the whole monitor exists for. Reaching it through the JSON-LD block the page already publishes is the most reliable route on a retail page, because the markup around the visible price is redesigned far more often than the structured data behind it. A capture group returns the digits alone, which is exactly what a threshold rule needs.

picks: "price":"([0-9.]+)"
rule: field_decreases_by_percent

list_price

css

The struck price beside the sale price. Tracking it separately is what lets you tell a genuine markdown from a raised list price with the same discount printed over it, which is the oldest trick on a retail page.

picks: .price--was
rule: field_changes

currency

css

Kept out of the price field on purpose. A price of 44.99 parses and a price of $44.99 does not, so the symbol lives here where a plain field_changes rule can still tell you the storefront switched currency on you.

picks: [itemprop="priceCurrency"]
rule: field_changes

availability

css

A price with no stock behind it is not a price. Pairing the two in one monitor is what separates a real markdown from a listing that went out of stock and dropped its price display along with it.

picks: .stock-state
rule: field_changes

seller

css

On a marketplace the buy box changes hands, and the price moves because a different merchant won it. Without this field the alert says the price fell; with it the alert says who undercut you.

picks: .offer__merchant
rule: field_changes

data.price

json_path

Where the target is a JSON endpoint rather than a page, JSONPath hands back the value with its type intact, so a number stays a number and none of the parsing advice above applies. Custom request headers carry the API key, up to 20 per monitor.

picks: $.data.attributes.price
rule: field_decreases_by_absolute

The one that catches everyone

A price only works as a number, and most pages do not print one

Numeric predicates read the extracted field with parseFloat. That is the whole implementation, and it is worth knowing because it fails quietly in both directions: a currency symbol makes the rule impossible to satisfy, and a thousands separator makes it satisfiable for the wrong reason. Neither raises an error, neither appears in the run history as a problem, and both look exactly like a page that has not changed.

How extracted price strings behave when a numeric predicate reads them
Extracted value	What the rule reads	Result	What to do about it
44.99	44.99	fires correctly	Nothing to do. The selector landed on a node holding the digits alone, which is the shape every numeric rule wants.
44.99 USD	44.99	fires correctly	Also fine: parseFloat stops at the first character that is not part of a number. Trailing text is harmless, leading text is not.
$44.99	NaN	never fires	The rule can never fire, and nothing errors. Reach the number with a regex capture such as \$([0-9.]+), or point the selector at the inner node that holds the digits.
1,299.00	1	fires wrongly	The worst case, because it fires: parseFloat stops at the comma. A drop from 1,299 to 1,199 is read as 1 to 1 and stays quiet, while a move to 999.00 reads as 1 to 999 and fires as an increase. Capture the digits without the separator, usually from the page JSON-LD.
From $44.99	NaN	never fires	Same as any leading symbol or word. A regex capture group is the shortest route, and it keeps working when the marketing copy in front of the number changes.
(empty string)	NaN	never fires	A selector that stops matching extracts an empty string rather than raising an error, so numeric rules go quiet. Pair the monitor with a second one using field_equals on an empty value, and you get an alert when the page breaks instead of silence.

The shortest reliable route on a retail page

Nearly every product page publishes a JSON-LD block for search engines, and the price inside it is a plain decimal with no symbol and no separator. A regex capture group over the raw document reaches it in one line, and it survives the redesigns that break a class-name selector. A regex without a capture group does something different and occasionally useful: it counts matches, so a pattern like Sale becomes the number of discounted items on a category page.

method: regex
field: price
pattern: "price":"([0-9.]+)"
gives: "44.99", which parses

NaN

what $44.99 becomes

A field that does not parse is treated as no comparison rather than as an error, so the monitor keeps running and the alert never arrives. This is the single most common reason a price rule looks broken, and it is fixed in the selector rather than in the rule.

What deserves a webhook

Threshold rules: the difference between a price alert and a ticker

Change detection asks whether a value moved. Price monitoring asks whether it moved past something, and that is what the four numeric predicates are for. A five percent band around the last check ignores the cent that a currency converter shifted overnight and fires when a human made a decision, which is the difference between an alert channel people read and one they mute in week three.

The nine diff predicates and the price question each one answers
Predicate	Fires when	The price question it answers
field_decreases_by_percentnumeric	A numeric field fell by more than your percentage.	Did a competitor undercut us by enough to matter, ignoring rounding?
field_increases_by_percentnumeric	A numeric field rose by more than your percentage.	Did the market raise prices, which is the moment your own increase gets easier?
field_decreases_by_absolutenumeric	A numeric field fell by at least your amount.	Did this fall by five whole units, which on a cheap SKU is a very different event?
field_increases_by_absolutenumeric	A numeric field rose by at least your amount.	Did the shipping charge climb by three, quietly, while the price stayed put?
field_changes	One named field moved, and the others are ignored.	Did the currency, the seller or the stock line change, whatever the price did?
any_field_changes	Any tracked field on the monitor moved.	Did anything at all move on this listing? The right rule for a first monitor.
field_matches_regex	The new value of a field matches your pattern.	Did the price string enter a range you care about, or a promo word appear?
field_equals	The new value is exactly yours, an empty string included.	Did the selector break, or did the stock line become exactly Out of stock?
composite	Several of the above, joined with AND or OR.	Wake me on a 5 percent cut, or on the seller changing, whichever happens first.

Put a number on the rule, always

A price field with a bare field_changes rule fires when a currency converter refreshes the last cent. The same field with a five percent decrease rule fires when somebody made a decision. The threshold is the single biggest lever on alert volume, and on a price page it is also the difference between a signal and a ticker.

Watch the list price beside the sale price

A discount that deepens while the struck price rises is not a discount. Two fields on one monitor cost nothing extra and turn a percentage claim into something you can check, which matters more in retail than in any other kind of monitoring.

Match the interval to the shelf

A marketplace buy box can turn over several times an hour and a distributor catalogue can hold for a quarter. Both hourly is how a channel gets muted in week three. If a page has moved twice in a year, daily is not a compromise, it is the correct setting.

Request and payload

One POST creates the monitor, one POST arrives when the price moves

There is nothing else to learn. A monitor is a URL, an interval, an extraction config, a predicate and a list of deliveries, and the event that comes back names the fields that moved and carries both values. The payload has been version 2026-05-01 since it shipped, and the version travels in the body so a consumer can branch on it.

create the monitorPOST /v1/monitors

curl -X POST https://api.verid.dev/v1/monitors \
  -H "Authorization: Bearer vrd_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Northgate / cordless drill 18v",
    "url": "https://retailer.example/p/cordless-drill-18v",
    "fetch_mode": "browser",
    "schedule_interval_seconds": 3600,
    "extract_config": {
      "method": "regex",
      "fields": {
        "price":      "\"price\":\"([0-9.]+)\"",
        "list_price": "\"listPrice\":\"([0-9.]+)\"",
        "availability": "\"availability\":\"https://schema.org/([A-Za-z]+)\""
      }
    },
    "diff_predicate": {
      "type": "composite",
      "operator": "OR",
      "conditions": [
        { "type": "field_decreases_by_percent", "field": "price", "threshold": 5 },
        { "type": "field_increases_by_percent", "field": "price", "threshold": 10 },
        { "type": "field_changes", "field": "availability" }
      ]
    },
    "deliveries": [
      { "type": "webhook", "url": "https://api.yourapp.com/hooks/prices" },
      { "type": "slack",   "webhookUrl": "https://hooks.slack.com/services/..." }
    ]
  }'

what arrives when it movesversion 2026-05-01

{
  "id": "1f0b7c94-6a52-4d3e-9c18-83b2e7a51d60",
  "version": "2026-05-01",
  "monitor_id": "9d4e1a37-2c68-4b90-a5f1-70c3e8d24b19",
  "run_id": "5a72c6e0-93b4-4f17-8d26-1e40b9f7c358",
  "fired_at": "2026-08-17T09:12:44.317Z",
  "diff": {
    "fields_changed": ["price"],
    "before": {
      "price": "49.99"
    },
    "after": {
      "price": "44.99"
    }
  },
  "monitor": {
    "name": "Northgate / cordless drill 18v",
    "url":  "https://retailer.example/p/cordless-drill-18v"
  }
}

Verid-Signature: t=1786957964,v1=9f2c...

Every delivery is signed with HMAC-SHA256 over the timestamp and the raw body, and retried six times across roughly four hours at 0, 5, 20, 50, 110 and 230 minutes before it lands in the dead letter queue for a manual replay.

From event to action

What a price event is worth once it reaches your systems

A price alert that ends in a human reading a message is worth a fraction of one that ends in a service recalculating. The same signed event can reach four places on the same run, and because deliveries are configured per monitor, the products that carry your margin can behave differently from the two hundred that do not.

delivery channels, per monitor

Signed webhook, Slack, Discord and email. One endpoint per monitor on the Free plan and up to 25 on Scale, so a single price event can reach a repricer, a warehouse, a channel and an agent without any of them polling anything.

Reprice inside the hour

The handler reads fields_changed, sees price, and compares the new number against your own list price and your floor. If the gap crosses whatever your pricing rules call intolerable it writes the new price, or opens a pull request against the price config. The whole exchange is two numbers, which is why it can be automated at all.

field: price
rule: field_decreases_by_percent, 5

Keep a price series you own

Every delivery is one row: monitor, field, before, after, fired_at. Appended to your warehouse it becomes a price history with no retention cliff and no export button, and it is the series a margin model actually needs. How ecommerce teams use that series is a longer read.

field: any
rule: any_field_changes

Tell the humans, once

A Slack line for the moves a person has to judge: a rival going below cost, a supplier raising a break price, a fare window opening. Delivery is per monitor, so the ten SKUs that carry the margin can post to a channel while the other two hundred stay silent in the warehouse.

field: price
rule: field_decreases_by_absolute, 5

Hand an agent a fresh number

Because every change is a signed JSON POST, an agent can be handed the new price rather than sent to re-read the page. The payload names the fields that moved, so a consumer switches on strings instead of comparing two documents.

field: price
rule: field_changes

The four delivery channels and what each is good for
Channel	Good for	What it carries	Worth knowing
Signed webhook	Anything that has to act: repricing, warehouse appends, an agent, a PIM write.	The full payload, HMAC-SHA256 signed, retried six times.	Custom request headers are allowed, up to 20 per monitor.
Slack	The moves a person has to judge rather than a service has to process.	Monitor name, URL, the changed fields and their before and after values.	One incoming webhook URL per delivery, so channels split per monitor.
Discord	The same job as Slack, for teams that live there instead.	The same summary, formatted for a Discord webhook.	Identical configuration shape, so switching is a one-line change.
Email	Slow shelves and stakeholders who will never open a dashboard.	A readable summary of the same price diff.	One address per delivery. Best on daily and weekly monitors.

Where this fits

Price monitoring API compared with the other four ways to do it

Five honest options, and Verid is the right answer to exactly one of them. If the hard part of your job is finding the same product across eleven retailers, buy the platform that does matching. If the hard part is knowing quickly and acting automatically on pages you can already name, keep reading.

Verid compared with price monitoring platforms, consumer price trackers, scraping APIs and a scraper you maintain yourself
Criterion	Verid	Price monitoring platforms	Consumer price trackers	Scraping APIs	A scraper you wrote
What you receive	A signed JSON event naming the price that moved, with before and after	A dashboard of matched products and a report	An email or a chart for one retail product	The page, or a parsed page, on every request	Whatever you wrote, once it is working
Coverage	Any public URL you name, retail, B2B, SaaS, fares or a JSON endpoint	Retail and marketplace catalogues they support	Mostly Amazon and large retailers	Any URL, but you do the extraction and the diff	Anything, at the cost of maintaining it
Who decides it is worth an alert	A predicate you wrote, with a percent or absolute threshold	A rule builder inside their product	A target price you typed	Nothing. There is no diff	Code you own and have to test
Product matching across sellers	No. You bring the URLs	Yes, and it is the main thing you pay for	Partial, inside their catalogue	No	No, unless you build it
Feeds your own systems	Signed webhooks into any endpoint, up to 25 per monitor on Scale	An export, sometimes an API on a higher tier	Email, occasionally RSS	Yes, it is an API by definition	Yes, you already own the code
Time to know	Your check interval, down to 5 minutes	Usually daily, sometimes hourly	Usually daily	Whenever you call it	Whenever your cron runs, if it ran
What breaks first	A selector, and the run history shows it	Their catalogue coverage for your niche	The retailers they never supported	Nothing, you carry the parsing yourself	Everything, silently, on a redesign
Entry cost	Free for 5 monitors, then $9 a month	Commonly $50 to $500 a month, often per SKU	Free	Per request or per page credit	Engineering time, forever

You pay a price monitoring platform per SKU

Keep it if what you are buying is product matching. Finding the same drill across eleven retailers, deduplicating variants and normalising titles is genuinely hard, and none of it is on offer here. What those platforms are weak at is a precise event your code can act on within the hour at a price that does not scale with your catalogue. The pricing tools roundup goes tool by tool. Many teams keep the platform for matching and run this underneath for the alerting.

You are on a consumer price tracker

CamelCamelCamel and Keepa are excellent at one thing: the Amazon price history of a product you are personally thinking of buying. They are not a business input. There is no webhook into your repricer, no coverage of your own storefront or your distributors, and no way to watch a B2B catalogue. The worked example in competitor price tracking is the same job done as data.

You wrote a scraper and a cron job

Then you already own the hard part and the expensive part: the fetch, the parse, the storage, the diff, the retry, the alert and the day the markup changes. The build versus buy arithmetic puts numbers on it, and scraping and change detection answer different questions in the first place. If you keep the scraper, at least stop hand-rolling the diff.

Where it stops

What this price monitoring API does not do

Six places where this is the wrong tool, is weaker than the copy above would like, or stops on purpose. The first two are the ones a buyer would otherwise discover on day three, which is the only reason to put a section like this on a page trying to sell you something.

There is no absolute floor rule

Every numeric predicate is relative to the previous check: fell by 5 percent, rose by 3. There is no rule that says fire whenever the price is below 39.99, which is exactly the shape MAP enforcement wants. Two honest workarounds: put the comparison in your handler, which is four lines against a payload that already carries the number, or use field_matches_regex to pin a band of values you consider a violation. The MAP compliance use case works the regex version through end to end, floor pattern included. Say the second one out loud before you rely on it, because a regex over a decimal is easy to get subtly wrong.

The number has to parse, and nothing warns you

A numeric rule against $44.99 never fires, and a numeric rule against 1,299.00 reads it as 1. Both fail quietly, because a field that does not parse is treated as no comparison rather than as an error. The parsing table above is the fix, and pairing a price monitor with a field_equals empty-string check is the cheapest way to learn that a selector broke.

No catalogue, no matching, no discovery

You bring the URLs. Nothing here finds the same product on another retailer, resolves a variant, reconciles a title, or tells you which competitors to watch. If matching is the job you are hiring for, a price intelligence platform is the correct purchase and this is the wrong page.

Hardened marketplaces will still fight you

Browser mode renders in real Chrome on every plan, and a residential proxy fallback is available from Starter upwards, which together is enough for a great many retail pages. It is not enough for every one of them all of the time. Some marketplace listings will serve a challenge page, and a challenge page is not a price. Prove a target works at your interval before you build a repricing rule on top of it, and keep prompt extraction in reserve for pages whose markup keeps moving.

A list of prices diffs as a list

A CSS selector matching forty price nodes on a category page returns an array, and the array is compared as a whole. You learn that the shelf changed, not which of the forty moved, and the numeric rules do not apply to an array at all. One monitor per product page is the shape that gives you per-price thresholds, and it is why the arithmetic above counts pages.

Custom request headers cover a JSON endpoint behind an API key or a bearer token, up to 20 headers per monitor. They cannot carry a Cookie header, which is reserved, so a trade price behind a session login is not something to plan around. Public pages and token-authenticated endpoints are the honest boundary.

Price monitoring questions

The fourteen things pricing, ecommerce and engineering teams ask before they wire price signal into their stack, answered with the numbers the product enforces.

What is a price monitoring API?

A price monitoring API checks the pages that carry a price on a schedule and sends your code a structured event when the number moves. With Verid you name the URL and the fields, for example price, list_price and availability, gate the alert with a rule such as a five percent decrease, and every qualifying change arrives as an HMAC-signed JSON webhook carrying the previous price, the new price and the list of fields that moved. There is no dashboard you are expected to live in, and no report to read on Monday.

How do I monitor a competitor price?

Create one monitor per competitor product page. Point an extractor at the price so that it comes back as digits, add the list price and the stock line beside it, then gate the monitor with field_decreases_by_percent at whatever move would actually change your decision, commonly three to five percent. Set the interval to match how fast that shelf moves, hourly for retail and daily for a distributor catalogue, and send the webhook to the service that reprices rather than to a person.

My price rule never fires. What is wrong?

Almost always the price is not parsing as a number. Numeric predicates read the field with parseFloat, so 44.99 and 44.99 USD both work, but $44.99 becomes NaN and the rule can never be true, while 1,299.00 becomes 1 and the rule fires on the wrong arithmetic. Neither case raises an error. Fix it by capturing the digits with a regex group, usually out of the JSON-LD block the page already publishes, or by pointing the selector at the inner node that holds the digits alone. Keep the currency symbol in its own field.

Can Verid do MAP monitoring?

Partly, and the limit is worth knowing before you buy. Verid will watch every authorised reseller page you name and tell you the advertised price and who is selling at it, on the schedule you set. What it does not have is an absolute floor predicate: the numeric rules compare against the previous check, not against a fixed number, so fire whenever this is below 39.99 is not a rule you can configure. That comparison belongs in your webhook handler, where it is a few lines against a payload that already carries the price.

How many products can I track?

One monitor covers one page, and every plan is a monitor count: 5 on the permanent Free plan, 25 on Lite, 50 on Starter, 250 on Pro and 1,500 on Scale. A single SKU sold by eight resellers is eight monitors. Forty products across a few rivals is forty. The count is pages rather than requests, so a page checked every five minutes costs the same as one checked daily.

How fast will I know a price changed?

Detection lag is your check interval plus the time it takes to fetch and render the page. The interval is set per monitor in seconds and floored by your plan: once a day on Free, every two hours on Lite, hourly on Starter, every fifteen minutes on Pro and every five minutes on Scale. Marketplace listings and fares usually run at the floor, while catalogues and pricing pages run hourly or daily.

Can it monitor Amazon prices?

Sometimes, and it depends on the listing. Verid renders in real Chrome on every plan, and Starter and above add a residential proxy fallback, which is enough for a great many retail pages including plenty of marketplace ones. Hardened listings still serve challenge pages, and a challenge page is not a price. Test the exact URL at the interval you want before you build anything on top of it. If what you want is Amazon price history for a personal purchase, a consumer tracker is the better and cheaper answer.

Does it work against a JSON price API?

Yes, and it is the cleanest case. Point the monitor at the endpoint, extract with JSONPath, and the value arrives with its type intact so a number stays a number and none of the parsing advice applies. Custom request headers carry an API key or a bearer token, up to 20 headers per monitor. The Cookie header is reserved and cannot be set, so session-authenticated endpoints are out of scope.

What is the best tool for price monitoring?

It depends on which half of the job you are buying. If the hard part is finding the same product across many retailers, a price intelligence platform that does product matching is worth its price and Verid is not a replacement for it. If the hard part is knowing quickly and acting automatically on pages you can already name, an API that delivers a signed event with the old and new price is the better fit and a great deal cheaper. Many teams run both, with the platform matching and Verid alerting.

What does price monitoring cost here?

The permanent Free plan is five monitors checked once a day with fourteen days of history and no card. Paid plans start at $9 a month for 25 monitors on a two-hour floor, $19 for 50 monitors hourly, $49 for 250 monitors every fifteen minutes and $149 for 1,500 monitors every five minutes. Pricing is per monitored page rather than per SKU or per request, which is why the arithmetic does not change when a shelf gets busy.

Can I get a price drop alert in Slack?

Yes. Slack, Discord, email and signed webhooks are the four delivery types, and they are configured per monitor, so the ten products that carry your margin can post into a channel while the rest write silently to your warehouse. A monitor can hold up to 25 endpoints on Scale and one on Free. The Slack message names the monitor, the URL, the fields that moved and their before and after values.

Do I get price history and charts?

You get history, not charts. Every run stores the object it extracted, kept from 14 days on Free to 24 months on Scale, and you can read it in the dashboard or through the API. There is no charting product here on purpose. The durable series is the one your handler appends to your own warehouse, one row per delivery, which then belongs to you and outlives any retention window.

Is price monitoring legal?

Reading a public price is ordinary market research, and businesses have compared prices since long before it was automated. What matters is how you do it: respect robots directives and terms of service, keep the check frequency reasonable, take only the fields you need, and stay out of anything behind a login you were not given. Verid gives per-monitor interval control precisely so a monitor can stay polite, and the choice of target remains yours.

Can it feed a repricing engine or an AI agent?

That is the intended shape. Every qualifying change is a signed JSON POST rather than an email, so the natural consumers are a repricer that recalculates, a workflow in n8n, Zapier or Make, a warehouse append, or an agent that needs the current competitor price without re-reading the page. The payload names the fields that changed, so a consumer switches on strings rather than comparing two documents.

Start free

Five monitors on the permanent free plan, with every extraction method and every threshold rule on them. Enough for one product across five sellers.

Get your free API keyView pricing