Restaurant and Food Delivery: Monitoring Menu Pages Across Delivery Platforms

A restaurant with any real delivery presence maintains its menu in several places at once — its own site, and however many delivery platforms it's listed on — and keeping all of them in sync is a genuinely hard operational problem. A price update that only propagated to one platform, a seasonal item still showing as available after it's off the menu, a photo that never made it to a newly added platform: none of these are unusual, and all of them cost either money or a bad customer experience.

Where This Comes Up

• Price consistency across platforms. A menu price change that updates the restaurant's own site but not a delivery platform's cached listing.
• 86'd items still showing as available. An item that's out of stock in the kitchen but still orderable on a platform that didn't get the update.
• New location rollout accuracy. Confirming a newly added location's menu actually matches the brand's current lineup across every platform it's listed on.
• Photo and description drift. Menu photos and descriptions maintained separately per platform tend to drift out of sync with the "real" current menu over time.

Capturing a Menu Page

curl --request POST \
  --url https://api.prod.ss.snapshot-site.com/api/v1/screenshot \
  --header 'Content-Type: application/json' \
  --header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
  --data '{
    "url": "https://example-delivery-platform.com/restaurant/example-location",
    "format": "png",
    "width": 1440,
    "fullSize": true,
    "hideCookie": true
  }'

fullSize: true matters — a full menu is almost always longer than one screen, and a partial capture won't catch an issue further down the list.

Comparing Across Platforms, Not Just Over Time

Where most monitoring use cases compare a page against its own past state, menu consistency benefits from a second comparison: the same location's menu on Platform A against Platform B, captured at roughly the same time, to catch drift between platforms directly rather than only catching drift from a stored baseline:

curl --request POST \
  --url https://api.prod.ss.snapshot-site.com/api/v3/compare \
  --header 'Content-Type: application/json' \
  --header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
  --data '{
    "before": {"url": "https://example-delivery-platform-a.com/restaurant/example-location", "width": 1440, "fullSize": true, "hideCookie": true},
    "after": {"url": "https://example-delivery-platform-b.com/restaurant/example-location", "width": 1440, "fullSize": true, "hideCookie": true},
    "threshold": 0.3
  }'

A wide threshold is appropriate here — two different platforms render a menu with entirely different layouts and branding, so the comparison is realistically a rough signal ("something is very different") rather than a precise pixel match, and it's most useful as a trigger for a human to actually look, not as a fully automated pass/fail.

A More Precise Alternative: AI Analysis Per Platform

For a more reliable cross-platform check than a raw pixel diff, running v3/analyze with enableSummary on each platform's menu page and comparing the resulting text summaries can catch content differences (missing items, different prices mentioned in context) that a visual diff alone might mis-weight due to layout differences between platforms. See Combining Visual Diff and AI Analysis for how the two signals work together.

Building the Watch List Around Multi-Location Operations

For a restaurant group with many locations, the practical setup is a spreadsheet or database of {location, platform, url} rows, checked on a schedule that matches how often menus actually change — weekly is usually enough outside of a active price or menu rollout, tightened up during one.

For multi-location restaurant and delivery operators, Snapshot Site turns a manual "let's spot-check a few platforms" habit into a running check across every location and platform combination.