Restaurant Menu Price Tracker & Comparator

Turn public restaurant menu pages into clean, comparable price data and get alerted to price changes between runs.

Give it the URLs of restaurant menus (the restaurant's own website, an online ordering page, a QR-menu page with prices as text). For each menu it returns normalized products, and when you schedule it, it tells you what changed: price increases and decreases, new and removed products, promotions starting or ending. With 2+ restaurants it also compares equivalent products across them.

What you get

recordType	What it is
product	One menu item: name, description, category, price, currency, size / weight / quantity when published, price per 100 g / per liter / per unit when computable, product type, combo vs. single item, a confidence score and quality flags.
change	Detected since the previous run of the same URL: price_up, price_down, new_product, removed_product, promo_started, promo_ended, or extraction_anomaly.
comparison	Equivalent products grouped across restaurants (same type, size, combo/single, burger variant): min / median / mean / max price, cheapest and most expensive restaurant, and a comparison_confidence (high / medium / low).
error	A URL that could not be processed and why (pdf_not_supported, requires_javascript, http_403, blocked_by_robots_txt, no_menu_found...). Errors are never billed.

A SUMMARY record in the default key-value store lists processed menus, failures and counts.

Example product

{
  "record_type": "product",
  "restaurant": "Frisby",
  "name": "Combo Mix",
  "price": 32000,
  "currency": "COP",
  "product_type": "pollo",
  "is_combo": true,
  "size_label": null,
  "price_per_unit": null,
  "confidence": 0.7,
  "flags": ["size_unknown"],
  "group_key": "pollo|combo|unknown|-|COP"
}

Example change

{
  "record_type": "change",
  "change_type": "price_up",
  "restaurant": "Lalitos Burger",
  "product_name": "VEGGIE BURGER DOBLE CARNE",
  "old_price": 20000,
  "new_price": 24500,
  "pct_change": 22.5,
  "currency": "COP"
}

How to track price changes

1. Run the Actor once with your list of menu URLs. This stores a baseline (no changes are reported on the first run).
2. Schedule the Actor (for example weekly). Every later run is compared with the previous one for each URL.
3. Keep the same History store name for the same set of URLs. Use a different name for a different client or market.

Why comparisons are trustworthy

A plain price list mixes things that are not comparable. This Actor keeps them apart:

• A burger and a combo with fries and a drink are different groups.
• Personal, medium, large and family sizes are different groups, and weights / volumes (150 g, 1.5 L) are parsed.
• A single, double and triple burger are different groups.
• When size is not published the group is marked size_unknown and comparison_confidence: low. Nothing is silently assumed.
• Prices abbreviated in thousands ($17.7, $282, $55 mil in Colombian pesos) are expanded, and the ones that had to be inferred are flagged price_scale_inferred with a lower confidence. By default they are left out of cross-restaurant comparisons (comparisonMinConfidence).
• Prices outside a plausible range are dropped rather than guessed.

Input

Field	Description
startUrls	Menu page URLs (HTML with prices as text).
defaultCurrency	Currency assumed when the page does not say (default COP).
detectChanges	Compare with the previous run (default on).
compareAcrossRestaurants	Group equivalent products across the restaurants in the run (default on).
comparisonMinConfidence	Minimum confidence (0-1) for a product to enter comparisons (default 0.5).
historyStoreName	Key-value store used for history (default menu-history).
maxProductsPerMenu, requestTimeoutSecs	Safety limits.

Pricing (pay per event)

• Menu processed: charged once per menu URL from which at least one valid product was extracted.
• Price change detected: charged per detected change (price up/down, new/removed product, promotion start/end).

Failed URLs, extraction anomalies and the baseline run's missing changes are not charged.

What it does NOT do (yet)

Be aware before you rely on it:

• No browser. Menus that only appear after JavaScript runs are reported as requires_javascript or no_menu_found.
• PDF menus are supported only when the PDF contains real text (you can select the words). Scanned or photo-only PDFs have no text and are reported as pdf_has_no_text; image files are reported as image_not_supported. There is no OCR. PDF extraction is less precise than HTML: products get a lower confidence, item names keep the PDF's capitalization, and complex layouts can be misread. Typical issues: item descriptions taken as names (flagged name_may_be_description and left out of comparisons by default), several price columns on one line (e.g. glass / bottle; the first price is used and the item is flagged multiple_prices), and pages laid out in several overlapping columns. Check a sample of your own PDFs before relying on the output.
• Links that open a viewer instead of the file (Google Drive, OneDrive/SharePoint, Dropbox previews) cannot be read. Use the direct link to the PDF file when the restaurant provides one.
• No delivery marketplaces (Rappi, PedidosYa, Uber Eats, iFood...). Their terms restrict automated access; use restaurants' own pages and sources whose use is permitted.
• Product type detection covers common categories (pizza, burger, chicken, pasta, drinks, desserts, ...); other items are extracted and priced but not compared.
• Extraction on arbitrary HTML is heuristic. Check the confidence field and the SUMMARY on your own URLs before automating decisions.

Responsible use

Only public pages. The Actor reads robots.txt and skips disallowed URLs, identifies itself with its own User-Agent, limits concurrency and adds a short delay between requests. It does not log in, solve CAPTCHAs or bypass blocks. You are responsible for complying with each site's terms.