Real-time vs cached pricing data

What the two terms mean

A real-time price is fetched from the retailer while your request waits. A cached (or stored) price was collected earlier and is served from a database. Most pricing services mix the two: they keep a store of prices and refresh parts of it on a schedule or on demand.

The label on the product page matters less than one field in the response: when was this price seen? A stored price from ten minutes ago is fresher than a “real-time” page that a retailer served from its own cache an hour ago.

The trade-offs

Request-time fetching earns its cost when the exact current price decides something right now: confirming a price at checkout, or acting during a short sale. For comparison listings, catalog enrichment, analytics and history, a store with honest timestamps is usually the better fit.

How the ShopSavvy Data API handles it

The Data API serves offers from its store: tens of millions of current offers across tens of thousands of retailers. Every offer carries a timestamp field, the time ShopSavvy last saw that price, so you can always tell how fresh it is.

• Scheduled monitoring: scheduled refreshes hourly, daily or weekly for retailers we can re-check through an official retailer API. Today that means Amazon (for products with an ASIN) and Best Buy (for products with a Best Buy SKU). Scheduling costs 1 credit per product; the refreshes themselves are not charged.
• Other retailers update as ShopSavvy sees them, through shopper activity and regular catalog crawls, not on a guaranteed schedule.
• Price history comes from the same store: each change is kept with the time it was seen.

Nothing here is fetched while your request waits, so a lookup never fails because one retailer was slow. The price you get is the last one seen, and the timestamp says when that was.

Scheduling API documentation → What gets refreshed on your cadence, the schedule values, and what it costs.

Checking freshness in your code

Decide how old a price may be for each use, and filter on the timestamp before you show or act on it. This works the same for any API that returns a seen-at time per price.

type Offer = { retailer: string; price: number; timestamp: string }

// Offers seen within maxAgeHours of now, newest first.
function freshOffers(offers: Offer[], maxAgeHours: number, now: Date = new Date()): Offer[] {
  const cutoff = now.getTime() - maxAgeHours * 3_600_000
  return offers
    .filter((offer) => Date.parse(offer.timestamp) >= cutoff)
    .sort((a, b) => Date.parse(b.timestamp) - Date.parse(a.timestamp))
}

// The cheapest offer that is fresh enough, or null when none is.
function cheapestFresh(offers: Offer[], maxAgeHours: number, now: Date = new Date()): Offer | null {
  const fresh = freshOffers(offers, maxAgeHours, now)
  return fresh.length === 0 ? null : fresh.reduce((best, offer) => (offer.price < best.price ? offer : best))
}

A price comparison page might accept a day; a deal alert might want a few hours and say “last checked” next to the price; an analytics job might keep everything and record the age as a column.

Questions to ask any pricing data provider

1. Does every price come with the time it was seen, per offer rather than per response?
2. Which retailers are refreshed on a schedule you control, and which are not?
3. What happens when a retailer cannot be reached: an error, a missing offer, or the last known price?
4. Are refreshes charged separately from lookups?
5. For your own product list, how old are the prices today?

How to evaluate a product pricing data API → Due-diligence questions with ShopSavvy’s own answers and where to check them.