# MAP Monitoring kwery observes seller identity and pricing across the marketplaces you watch. Applying that data to a MAP (Minimum Advertised Price) policy — evaluating it, deciding what counts as a violation, and acting on it — is yours to build. This guide covers the fields relevant to MAP monitoring specifically, the boundary between what kwery does and doesn't do, and how change-event delivery wires into it. ## What kwery returns Every offer observation relevant to MAP monitoring includes: | Field | Description | | --- | --- | | `seller_id` | Marketplace-issued seller identifier, where the marketplace exposes one. Source-specific — not unified into one identity across marketplaces. | | `seller_name` | The seller's display name on that marketplace. | | `price` | The observed selling price, per offer. | | `shipping` | The observed shipping cost, per offer — relevant for sources where ranking or landed price includes shipping. On Idealo each offer also carries `total`, the landed price (see the [Idealo source guide](/sources/idealo#offer-fields)). | | `source` / `country` | Which marketplace and market the observation came from (on the result's `query`). | | `observed_at` | When the observation was made — on every result, alongside [`served_from`](/guides/audit-and-provenance). | Seller identity, price, and shipping are returned together on every offer — you don't need a separate request to resolve who's selling at what price. See the real captured responses on the [source pages](/sources) for exactly how this looks per marketplace. ## What kwery does not do Stated plainly, once, so this doesn't need to be inferred from anywhere else: - **kwery does not store your MAP floor.** There's no policy-storage feature — your price floor per product lives in your own system. - **kwery does not evaluate policy or classify violations.** A response includes the observed price; whether that price breaks your policy is a comparison you make, not something kwery flags. - **kwery does not capture evidentiary screenshots.** If you need a defensible visual record for a legal or contractual conversation with a reseller, that's a headless-browser capture layer you build separately — kwery returns structured data, not images. - **kwery does not attribute first-mover causality.** Identifying which seller changed price first when several move in sequence isn't a capability this API exposes today. - **kwery does not re-verify a detected change from a second network route.** If you need confirmation a violation wasn't a caching artifact before acting on it, that verification step is yours to add. (Every result does carry its [crawl trail](/guides/audit-and-provenance) and [confidence score](/guides/trust), which cover the most common false-signal causes.) If you need the full evidence chain — screenshots, first-mover attribution, verified detections — pair kwery's data with a dedicated MAP enforcement tool, or build that layer on top of what's documented here. ## Watching a product for MAP-relevant changes MAP monitoring builds on [change events](/guides/change-events): any product you query is eligible for watching, and a **subscription** ties your watch list to a delivery endpoint and the event types you care about. For MAP the relevant events are: - **`price.delta`** — the product's representative price moved. Set a [threshold](/guides/change-events#thresholds) at your MAP floor's distance so you're only notified on meaningful moves. - **`buybox.change`** — Amazon only: the buy-box **seller** or buy-box **price** changed. This is the MAP event for Amazon — a violation there usually surfaces as a new seller taking the buy-box at a lower price. > **Rolling out.** Change-event subscriptions are being enabled account by account — [contact us](https://kwery.co/contact) to join the rollout; we'll configure your watch list, event types, and thresholds with you. The delivery contract below is final and will not change. When a watched product moves, the change event delivered to your `callback_url` looks like this (product identity from a real capture; the prices illustrate a below-MAP drop): ```json { "event": "price.delta", "delivered_at": "2026-09-14T09:41:12.000Z", "product": { "source": "idealo", "country": "de", "key": "gtin", "value": "4006381333962", "name": "STABILO point 88 ocker" }, "changes": { "price": { "old": 17.40, "new": 14.90 } } } ``` `changes` carries each moved field as an **old → new pair**, so you can branch logic without diffing snapshots yourself. By default the event also includes the full current record — every offer with `seller_name`, `seller_id`, `price` and `shipping` — so you can compare the offending offer (landed price included, if your MAP policy is landed-price-inclusive) against your own floor without a follow-up lookup. Deliveries are signed and retried exactly like [stream webhooks](/guides/webhooks). ## Multi-market sources Sources with multi-country reach are queried independently per market — Amazon's 21 country codes and Kaufland's 7 markets each need their own watch per country. A seller holding their price in one market while undercutting in another won't surface unless both markets are being watched separately. Per-source market lists are on each [source page](/sources). ## Credit cost MAP monitoring is billed the same way as any other kwery lookup — each freshly crawled result costs the source's [credit weight](/guides/pricing#source-weights); cache re-serves are free, and event deliveries themselves are never billed. Nothing about MAP monitoring changes the underlying billing model. ## Next steps - [Webhooks](/guides/webhooks) — full delivery mechanics: signing, retries, and replay. - [Change events](/guides/change-events) — the general change-detection system this guide builds on: event catalog, thresholds, `delta_only`. - [Confidence score](/guides/trust) — a low-confidence product match can produce a false MAP signal; worth checking before treating an observation as reliable. - [Pricing](/guides/pricing) — credit cost and the source-weighting table.