Building a Price Monitoring Agent Across Amazon, Walmart and Target

A price monitoring agent keeps a watch list of products, reads each retailer's current listing on a schedule, compares it with the last reading and tells you when something moved. This post builds one for Amazon, Walmart and Target, reachable over REST or MCP: the data model, the three retailer sources, a real Walmart response, the cost per check and where the approach stops being reliable. Each source page in the catalog is the reference for exact fields and prices.

The short version

• —What you build: a small agent with four parts: a watch list, a scheduled lookup per retailer, a normalizer that turns three response shapes into one record, and a diff that decides what is worth an alert.
• —How it reads prices: each retailer is its own pay-per-lookup source. You send an identifier (ASIN, Walmart item ID or Target TCIN) and get one structured product back, so there is no page layout to maintain.
• —What it costs: 5 points per product lookup on all three, which is $5 per 1,000 lookups according to the source pages. Searches cost 1 point per record returned, and a lookup that does not resolve is not billed.
• —Who it is for: brand owners, retail buyers, resellers and anyone giving an assistant a "check this price" tool. It is not for tracking a competitor's own pricing page; that is a job for extraction with a schema.

What a price monitoring agent has to do

Price monitoring sounds like one job but is really four: find the right product at each retailer, read its current price, remember what it was before, and decide whether the difference deserves a human's attention. Most of the engineering effort sits in the first and last of those, not in the middle one.

Reading a price is the easy part once you have a structured source. The harder questions are about meaning. Is the Target listing the same item as the Amazon one, or a different pack size? Did the price change, or did the buy box move to a different seller? An agent that cannot answer those questions produces alerts nobody trusts.

Marketplace sources or page extraction

If the thing you are tracking is a competitor's own pricing page, there is no product identifier to look up, and a schema-driven extraction call is the right tool. Marketplaces are different: Amazon, Walmart and Target each publish a product listing keyed by an identifier, and a dedicated source can return that listing in a fixed shape. You skip the schema and the page-layout risk, and you give up flexibility, because you only get the fields the source returns.

The three retailer sources

The agent talks to three sources, one per retailer. Each takes an identifier and returns one product. The point cost is the same for all three according to their source pages.

Each source page also states that a lookup that does not resolve is not billed. The product search source for each retailer, used to find identifiers by keyword, costs 1 point per record returned, and a search that matches nothing costs nothing.

Amazon

The Amazon product source takes an ASIN and an optional marketplace domain. According to its source page it works against 19 Amazon marketplaces, and the same ASIN can resolve to a different price, availability and seller depending on the country you ask. The response includes price, list price, currency, rating, availability, an in-stock flag, features, the product details table, the buy-box seller, who ships and who sells, and variations.

The currency field holds a symbol such as "$", not an ISO code, so the agent should keep the marketplace domain alongside it. The seller block can have a null id for first-party listings, so compare seller identity by name unless you have a better key.

Walmart

The Walmart product source takes an item ID or a full product URL. Its response includes the price as a number and as a formatted string, the ISO currency, a list price when the item is marked down, rating, availability status, an in-stock flag, condition, and a seller block that marks the listing as INTERNAL (sold by Walmart) or EXTERNAL (a third-party seller). For a price monitor that seller type is useful: a drop from an external seller is a different signal from a drop on a listing Walmart sells itself.

Target

The Target product source takes a TCIN, which is the number at the end of a Target product URL after A-, or the full URL. The response includes price, list price, currency, a sale flag, a discount percentage, a star-by-star ratings breakdown, specifications, package dimensions and return policy windows. The documented response has no stock field, and the source page lists store-level stock and pickup availability as not included. If stock matters to you, treat Target as a price source and not as an availability source.

Building the agent, step by step

Each step has a different failure mode, so keep them separate.

1. Build the watch list

A watch list is a table with one row per retailer listing: your internal product name, the retailer, the identifier for that retailer (ASIN, item ID or TCIN) and, for Amazon, the marketplace domain. The decision that "this is the same product at all three retailers" is made once, by hand or with help from a search source, and stored. Do not infer it again on every run.

To seed the list, the keyword search source for each retailer returns candidate listings at 1 point per record. A human, or a rule such as a matching UPC or model number, picks the right ones. The Walmart and Target responses include a UPC or barcode field, and the Amazon details table includes UPC and model number when the listing publishes them.

2. Read each listing on a schedule

A scheduler (cron, a queue worker, whatever you already run) takes each row due for a check and sends one request to the matching source. The retailer-specific code is short: a function per retailer that sends the identifier and returns the product object.

3. Normalize to one record

The three responses name things slightly differently, so the agent maps each into the same small record: retailer, identifier, price, list price, currency, in-stock (or unknown), seller, and the time of the reading.

def normalize(retailer, product, domain=None):
    if retailer == "amazon":
        return {
            "retailer": "amazon", "id": product["id"], "market": domain,
            "price": product["price"], "list_price": product["list_price"],
            "currency": product["currency"],           # a symbol, e.g. "$"
            "in_stock": product["is_in_stock"],
            "seller": product["seller"]["name"],
        }
    if retailer == "walmart":
        return {
            "retailer": "walmart", "id": product["id"], "market": "walmart.com",
            "price": product["price"], "list_price": product["list_price"],
            "currency": product["currency"],           # ISO code, e.g. "USD"
            "in_stock": product["is_in_stock"],
            "seller": (product["seller"] or {}).get("display_name"),
        }
    if retailer == "target":
        return {
            "retailer": "target", "id": product["id"], "market": "target.com",
            "price": product["price"], "list_price": product["list_price"],
            "currency": product["currency"],
            "in_stock": None,                          # not in the Target response
            "seller": None,
        }

4. Diff against the last reading

Each new record is compared with the previous record for the same retailer and identifier. The comparison is where you decide what counts as a change:

• —Price change. The obvious one. Compare the normalized price, not the raw JSON.
• —List price change alone. Usually a promotion started or ended.
• —Seller change at the same price. Worth logging separately, because the buy box on a marketplace moves for reasons unrelated to price.
• —Stock flip. Only on Amazon and Walmart, since Target does not return stock.

5. Alert, with context

An alert that says "price changed" is not much use. Include the old and new price, the retailer, the seller where known, and a link to the listing, so someone can decide in seconds. Send big moves immediately and batch small ones into a daily digest.

REST and MCP

The agent can reach each retailer over REST from your backend, or over MCP when the agent is an assistant that picks its own tools. It is the same source and the same JSON either way, and AI research is the only part of the platform that is REST-only. The request below is the one shown on the Walmart source page. Replace YOUR_API_KEY with your key; the endpoint and parameters are documented at docs.neuralverge.ai.

curl -X POST https://api.neuralverge.ai/functions/v1/run-walmart-product \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "item": "15290971475" }'

Through MCP the same lookup is a call to the tool run_walmart_product with the same item argument; the Amazon and Target product sources work the same way. Setup is covered in the MCP server guide. A sensible split is REST for the scheduled loop, where you control the cadence, and MCP for the on-demand "what is the price right now?" question an assistant gets from a person.

The JSON below is the captured sample response from the source page. To keep it readable I have shortened a few long values (the image list, the description and the return policy) and marked each with ...; every other field and value is as returned.

{
  "session_id": "11111111-1111-1111-1111-111111111111",
  "kind": "walmart_product",
  "item": "15290971475",
  "human": "# Walmart product\n\n- **Item:** 15290971475\n- **Response size:** 508.2 KB\n- **Name:** LoopTone Vinyl Record Player Turntable with Bluetooth, CD, Tape, Radio, USB Recorder, Stereo Home System\n- **Price:** USD129.99\n- **Rating:** 4.3 (644 reviews)\n- **Availability:** IN_STOCK",
  "machine": {
    "product": {
      "id": "15290971475",
      "us_item_id": "15290971475",
      "walmart_internal_id": "0W0FAWCUKZIK",
      "name": "LoopTone Vinyl Record Player Turntable with Bluetooth, CD, Tape, Radio, USB Recorder, Stereo Home System",
      "brand": "LoopTone",
      "brand_url": "/search?q=LoopTone&facet=brand:LoopTone",
      "model": "18CDBB-B",
      "upc": "797457436581",
      "manufacturer_product_id": "18CDBB-B",
      "price": 129.99,
      "price_string": "$129.99",
      "currency": "USD",
      "list_price": 199.99,
      "rating": 4.3,
      "review_count": 644,
      "image": "https://i5.walmartimages.com/seo/LoopTone-3-Speed-Vinyl-Record-Player-...",
      "images": [ "..." ],
      "availability_status": "IN_STOCK",
      "is_in_stock": true,
      "short_description": "<p>This LoopTone Audio Turntable offers a vintage-themed entertainment experience ... </p>",
      "seller": {
        "id": "47D6101AABDC40719510F4D0079EEF41",
        "name": "huizhoushideshengyuandianziyouxiangongsi",
        "display_name": "LoopTone",
        "storefront_url": "https://www.walmart.com/global/seller/102730552",
        "type": "EXTERNAL"
      },
      "breadcrumbs": [
        "Musical Instruments",
        "DJ Turntables, Controllers, Mixers, and other DJ Equipment"
      ],
      "category": "Turntables and Record Players",
      "return_policy": { "returnable": true, "freeReturns": true, "returnWindow": { "value": 30, "unitType": "Day" }, "...": "..." },
      "variants": [],
      "badges": [],
      "condition": "New",
      "is_preowned": false
    },
    "response_bytes": 520381
  },
  "total_points": 5
}

Reading the response as a price monitor

Several fields in this one response do the work of a monitor:

• —price and list_price. The current price is 129.99 and the list price is 199.99. A monitor stores both; the gap is the markdown the retailer is showing.
• —is_in_stock and availability_status. Both say the item is in stock now.
• —seller.type. This listing is EXTERNAL, meaning a third-party seller. The storefront_url is the working identifier if you decide to look the seller up separately.
• —upc and model. These are the keys you use to confirm that the Amazon and Target listings you track are the same item.
• —total_points. The lookup cost 5 points.

Cost and limits

Cost is simple to estimate because every product lookup is 5 points on these three sources. The plans on the pricing page start at $50 for 50,000 points a month, which works out to $1 per 1,000 points at the listed rates. The arithmetic below is illustrative; use your own numbers.

A worked example

Say Acme Oy, a Finnish retailer-supplier, wants to watch 100 products across all three US retailers once a day. That is 300 lookups a day, or 1,500 points a day, and over a 30-day month 45,000 points. A check every six hours quadruples that; weekly checks on half the list cut it sharply. Cost scales with products times retailers times frequency, and you control all three.

To keep it down, match cadence to volatility, and search only to build the watch list (1 point per record returned), then look up by identifier.

Where it stops being reliable

Prices are a moment in time. Each source page says the listing is read at request time. A price can change a minute after the reading. Scheduled monitoring gives you a sampled history, not a continuous feed, and a flash sale shorter than your interval can be missed.

Field coverage differs by retailer. Target's documented response has no stock flag. Amazon's seller id can be null. Walmart's storefront_url is null for items Walmart sells itself. Treat missing as unknown, not as zero or false.

The price shown is not always the price paid. The response reports the listing price. Shipping, membership discounts, coupons applied at checkout and tax are outside it. If your decision depends on landed cost, account for those separately.

Coverage follows the listing. A delisted product may not resolve.

How to decide

Go through this before building on any price source, this one included:

1. —Does it cover your retailers and markets? Confirm the ASIN domains, countries and listing types you need are supported.
2. —Can you match products reliably? Check that UPC, model number or another key is present for the products you track.
3. —Which fields does each retailer return? Write down the gaps, such as stock on Target or seller id on Amazon, and decide how the agent treats them.
4. —How is a failed lookup billed? Each source page here says unresolved lookups are not billed; check the current terms for any source you use.
5. —What is the cost at your cadence? Multiply products by retailers by checks per month by points per lookup.
6. —How will the agent reach it? REST from your backend for the schedule, MCP tools for an assistant.
7. —Which workflow is yours? The ones that fit best:
   • —Brand and MAP monitoring: a brand owner sees where its price falls below the price it asks resellers to hold, and which seller lists it.
   • —Retail buying: a buyer compares what the same item sells for at competing retailers before a supplier negotiation.
   • —Resale: a reseller watches cost at one retailer against selling price at another, using seller type and condition to avoid mixing new and pre-owned stock.
   • —Agent tools: a shopping or procurement assistant gets a "check price" tool instead of reading a stale spreadsheet.

Frequently asked questions

Do I need a separate integration for each retailer?

No. Amazon, Walmart and Target are separate sources, but they are called the same way: you send an identifier (an ASIN, a Walmart item ID or a Target TCIN) and get structured JSON back. The field names differ a little between retailers, so the agent normalizes them into one record before comparing.

What does one price check cost?

Each product lookup on Amazon, Walmart and Target costs 5 points, which is $5 per 1,000 lookups according to the source pages. Keyword and category searches cost 1 point per record returned. A lookup that does not resolve is not billed.

How current is the price in the response?

The listing is read when you make the request, so the price matches the page at that moment. It can change right after, which is why a monitoring agent stores each reading with a timestamp and compares readings over time.

Does the response include stock status for all three retailers?

Not equally. The Amazon and Walmart responses include an in-stock flag. The documented Target product response has price, list price, sale flag and discount percentage but no stock field, and store-level stock and pickup availability are not part of it.

Can I use this from an AI agent through MCP?

Yes. The Amazon, Walmart and Target product sources are available over REST and as MCP tools, with the same arguments on both routes.

How is this different from extracting prices from a web page with an LLM?

Extraction reads a page you point it at and maps it to a schema you define, which suits pages with no structured source behind them, such as a competitor's pricing page. A marketplace source takes a product identifier and returns a fixed set of fields, so there is no schema to write for these three retailers.