Travel and Hospitality: Monitoring OTA Listings and Booking Pages

A hotel or travel brand rarely controls how its own listing looks on the online travel agencies (OTAs) that drive a large share of bookings. Rates get parity-checked against the wrong currency, photos get swapped during a platform migration, availability calendars glitch, and nobody at the property notices until a guest complains or a revenue manager happens to click through.

Scheduled screenshots of a property's own listing pages turn "nobody's watching" into a monitored, dated record.

Where This Comes Up

• Rate parity checks. Confirming a listing shows the negotiated or expected rate, without relying on the OTA's own reporting.
• Photo and content accuracy. Catching a platform update that reordered, cropped, or dropped photos from a listing.
• Availability calendar issues. A sync bug between a property management system and an OTA can show a room as unavailable when it isn't, quietly losing bookings.
• Seasonal campaign verification. Confirming a promotional rate or banner actually appears on the listing during the campaign window it was scheduled for.

Capturing a Listing 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-ota.com/hotel/property-12345",
    "format": "png",
    "width": 1440,
    "fullSize": true,
    "hideCookie": true
  }'

fullSize: true matters for booking pages specifically — the rate, availability calendar, and photo gallery are often spread across a long scroll, and a partial capture can miss the exact section that actually needs checking.

Turning Captures Into a Monitor

A single capture is a record. A useful monitor compares each new capture against the last known-good state with v3/compare:

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": {"imageUrl": "https://cdn.example.com/baselines/property-12345.png"},
    "after": {"url": "https://example-ota.com/hotel/property-12345", "width": 1440, "fullSize": true, "hideCookie": true},
    "threshold": 0.15
  }'

A wider threshold makes sense here — OTA listing pages carry rotating promotional banners and dynamic pricing widgets that shift on their own, so the baseline needs some tolerance before flagging a real change. See Tuning the threshold Parameter for how to find that number for a given page.

Watching More Than One Platform, More Than One Property

The practical setup is a spreadsheet or small database of {property, OTA, url} rows, with a scheduled job looping over the list — daily is usually enough, since listing content doesn't change minute to minute. Route anything that crosses the threshold into whichever channel the revenue or marketing team already watches, with the diff image attached so the reviewer sees exactly what changed without opening two tabs.

What This Catches That Manual Checks Miss

Nobody on a revenue or marketing team has time to click through every listing on every OTA every day. A scheduled monitor does not replace judgment about whether a change matters — it replaces the much larger problem of nobody looking at all until a guest or a booking dip forces the issue.

For hospitality teams managing listings across multiple platforms, Snapshot Site turns that manual spot-check habit into something that runs on its own.