Glade APIGlade API
Sign inGet an API key

Price monitoring

Price monitoring across every Amazon marketplace

Observe products, offers, stock, and sales context without maintaining a browser fleet. Every observation keeps its marketplace, delivery context, and freshness metadata.

Start freeSee the recipe

/api/amazon

One ASIN, every price signal

GET/api/amazon/productGET/api/amazon/product/offersGET/api/amazon/product/stockGET/api/amazon/product/sales

A price monitor needs more than a number. Glade API returns currency, condition, seller, delivery, cache state, and observation time through the same contract, so a change can be distinguished from a stale page or a failed acquisition.

What teams build with it

These are complete monitoring patterns, each with the operation chain visible before you build it.

One ASIN, complete observation

Resolve the product once, then attach offers and availability to the same timestamped observation.

Endpoint chainproduct -> offers -> stock

Buy-box movement

Compare seller, condition, delivery, and buy-box signals without treating every price as equivalent.

Endpoint chainoffers -> seller

Availability watch

Keep an out-of-stock state separate from an acquisition or parsing failure.

Endpoint chainstock -> offers

Modeled sales context

Place a price move beside a versioned demand estimate instead of implying causal certainty.

Endpoint chainoffers -> sales

Deal discovery lane

Find active deals first, then resolve durable product records for downstream monitoring.

Endpoint chaindeals -> product

Category benchmark

Compare watched products with current best-seller context inside the same marketplace.

Endpoint chainbestsellers -> product

How the price monitoring workflow works

Four calls cover the useful observation. Resolve identity first, then add the volatile signals that need shorter cache windows.

Every step is independently cacheable. Reuse stable product data while refreshing offers and stock more often.

  1. GET /api/amazon/product

    Resolve the stable product record

    Start from a validated ASIN and marketplace so later observations attach to the same product identity.

    catalog cache · 6 hours
  2. GET /api/amazon/product/offers

    Capture price and seller context

    Collect price, condition, seller, Prime, delivery, availability, and buy-box signals together.

    volatile cache · 5 minutes
  3. GET /api/amazon/product/stock

    Attach bounded availability

    Store the derived stock signal with its ruleset version and observation time instead of overstating precision.

    estimate cache · 15 minutes
  4. GET /api/amazon/product/sales

    Add versioned demand context

    Keep the observed price separate from a clearly labeled sales estimate and its immutable model version.

    model result · 6 hours

APIs used in a price monitor

Each operation is a bounded lane on the same key. Open an API to inspect its parameters, cache policy, and example response.

Compared with the usual setup

Most teams either maintain marketplace parsers or assemble several providers. Here is what changes when the acquisition layer becomes one API.

CapabilityGlade APITypical setup
Marketplace coverageOne key works across 13 supported Amazon marketplaces.A locale-specific integration or scraper configuration per marketplace.
Response shapeOne versioned response envelope and normalized operation catalog.Different page shapes, selectors, and field names maintained by hand.
FreshnessFetched time, cache state, and operation-specific TTLs travel with the result.Freshness is inferred from a job timestamp or omitted entirely.
Failure handlingTyped failures stay separate from empty or out-of-stock results.Retries, proxy failures, parser failures, and empty pages can look alike.
Pricing modelSuccessful normalized operations consume one published request unit.Proxy, browser, compute, storage, and maintenance costs are metered separately.
Getting startedGoogle sign-in, an API key, and a documented request are enough.Provider selection, browser infrastructure, parser code, and monitoring come first.

Price monitoring questions

How often can I refresh prices?+

The offers operation uses a five-minute cache window. Repeating an identical request inside that window can reuse the cached result while retaining the original fetched time.

Can I monitor all supported marketplaces?+

Yes. Select one documented marketplace per request and keep comparisons scoped to the same currency, locale, and delivery context.

Does a failed request look like out of stock?+

No. Typed acquisition and parsing failures remain distinct from a successful product response whose availability is out of stock.

Is stock an exact warehouse count?+

No. Stock is a bounded estimate with explicit evidence, ruleset version, and observation time—not a guaranteed inventory declaration.

Can I schedule these calls?+

Yes. Use your scheduler or workflow system and persist the fetched time, request ID, and cache metadata with each observation.

How is a successful call billed?+

A successful normalized operation consumes one request unit. Cached responses can avoid unnecessary upstream work while preserving the response contract.

Ask AI about Glade API

Ask ChatGPTAsk PerplexityAsk GeminiAsk ClaudeAsk Grok

Start monitoring in four calls

Sign in with Google, create a key, and replace the sample ASIN with a product you monitor.

Start freeRead the docs

Request

curl -G "https://gladeapi.com/api/amazon/product" \
  -H "API-KEY: glade_live_YOUR_API_KEY" \
  --data-urlencode "asin=B0D1XD1ZV3" \
  --data-urlencode "domain=US"
curl -G "https://gladeapi.com/api/amazon/product/offers" \
  -H "API-KEY: glade_live_YOUR_API_KEY" \
  --data-urlencode "asin=B0D1XD1ZV3" \
  --data-urlencode "domain=US"

Both calls use the same key, response envelope, request metadata, and documented failure model.