The problem with watching competitor prices by hand is not the effort. It is that you only look when you remember to. The price drop happened Tuesday at 3am; you noticed Friday, and the traffic has already moved.
A job that runs once a day fixes that, and three endpoints are enough.
export ECOMMERCE_DATA_API_KEY="your_api_key"Each endpoint covers a different time range
| Endpoint | Range | What it is for |
|---|---|---|
| Product Details | Now | Today's price, BSR, rating, review count, seller count |
| Coupon Trends | Recent | The on/off rhythm of promotions |
| Product History | Long run | Price and rank curves, to judge whether today's move is unusual |
Only the first one needs to run daily. Coupon trends weekly is plenty, and the historical curve only when you need to decide whether a drop is big. That split is what determines your call volume.
The daily snapshot
curl --request POST \
--url https://ecommercedataapi.com/v1/amazon/asin/detail \
--header "Content-Type: application/json" \
--header "X-API-Key: ${ECOMMERCE_DATA_API_KEY}" \
--data '{
"marketplace": "US",
"asin": "B08CK5Z5Q1"
}'Store each day's response keyed by (asin, date) rather than keeping only the latest value. Keeping only the latest value means giving up change detection — you need yesterday's row to know what moved today.
If you want coupons at the same time, Product Details with Coupon Trends returns both in one call, which is one billable unit instead of two.
Coupon cadence
curl --request POST \
--url https://ecommercedataapi.com/v1/amazon/asin/coupon-trend \
--header "Content-Type: application/json" \
--header "X-API-Key: ${ECOMMERCE_DATA_API_KEY}" \
--data '{
"marketplace": "US",
"asin": "B08CK5Z5Q1"
}'The value of coupon data is in the rhythm, not the current state. Whether a competitor runs a coupon permanently or concentrates them around specific dates decides whether you follow. Today's on/off flag alone supports no conclusion.
The historical curve
curl --request POST \
--url https://ecommercedataapi.com/v1/amazon/keepa/detail \
--header "Content-Type: application/json" \
--header "X-API-Key: ${ECOMMERCE_DATA_API_KEY}" \
--data '{
"marketplace": "US",
"asin": "B08CK5Z5Q1"
}'This endpoint answers "how big is this move in historical terms". Without it, your alerts mix routine noise with real action.
Setting alert thresholds
Do not use a fixed percentage. "Alert on any drop over 5%" means very different things in different price bands. Use historical ranges as the baseline instead:
- Price falls below the N-day historical low → worth a look.
- BSR crosses an order of magnitude in one day (five digits into four) → worth a look.
- Seller count jumps → possible new resellers, higher priority than a price move.
- Review count spikes in a single day → log it, but it does not always need action.
The first two need history, which is what the third endpoint is for.
Scheduling and call volume
Say you monitor 50 competitor ASINs:
| Job | Frequency | Calls per run | Roughly per month |
|---|---|---|---|
| Daily snapshot | Daily | 50 | 1,500 |
| Coupon trends | Weekly | 50 | 200 |
| Historical curve | On trigger | As needed | Depends on alert count |
One successful billable request consumes one call by default, so monitoring cost is essentially "ASIN count × frequency". To cut cost, reduce ASINs or frequency — not fields. The endpoint returns all its fields and bills the same either way. Pack sizes are on pricing.
Three things the implementation has to handle
One: limits are per account. Fifty ASINs in sequence is fine; fifty in parallel is not. Back off on 429 using Retry-After; the full error list is in errors and rate limits.
Two: failures are not billed, so retry is safe. Requests that fail before returning a billable result are not charged. Add retries, but cap them and log X-Request-Id so a failure is diagnosable.
Three: distinguish "the value changed" from "the lookup failed". On failure, do not write 0 or an empty value — that becomes a fake crash in your curve. Skip the day and flag it.
Limits
- A snapshot is the value at query time. Once a day means intraday moves are invisible.
- BSR and price are platform-visible and verifiable; sales figures are estimates.
- Historical granularity and coverage depend on what the endpoint returns. Not every ASIN has an equally long history.
- This flow monitors public market data. It does not include your own ad spend, inventory, or orders — export those from your own back end.
To run the same flow by hand before writing a scheduler, hand it to an agent: Competitor analysis in Cursor or Codex.