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.
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). |
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. |
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 for exactly how this looks per marketplace.
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 and confidence score, 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.
MAP monitoring builds on 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 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 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):
{
"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.
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.
MAP monitoring is billed the same way as any other kwery lookup — each freshly crawled result costs the source's credit weight; cache re-serves are free, and event deliveries themselves are never billed. Nothing about MAP monitoring changes the underlying billing model.
- Webhooks — full delivery mechanics: signing, retries, and replay.
- Change events — the general change-detection system this guide builds on: event catalog, thresholds,
delta_only. - Confidence score — a low-confidence product match can produce a false MAP signal; worth checking before treating an observation as reliable.
- Pricing — credit cost and the source-weighting table.