E-commerce & Retail
Competitor Price Monitoring API
You already know your competitors move prices. What you probably do not know is which of your own SKUs were undercut overnight, by how much, and whether the rival actually had stock.
- Retailers
- Marketplaces
- Pricing software vendors
- Brand manufacturers
- Distributors
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Price comparison inside a retail business usually starts as a spreadsheet one buyer maintains. It works until the catalogue passes a few hundred lines, at which point the spreadsheet becomes a weekly snapshot of a daily market, and decisions get made against prices that were true last Tuesday.
The hard part is not reading a price off a page. It is knowing that the page you read is the same product you sell, that the figure is the price a customer would actually pay after the promotion and delivery charge, and that the rival has the item in stock at all. A competitor who is out of stock is not a competitor that week, and matching their price costs you margin for nothing.
There is also a compliance dimension that technical teams tend to discover late. What may be collected, how often, and whether the resulting figures may be stored, redistributed or shown to your own customers is governed by each source's terms of use, by contractual arrangements you may already have with marketplaces, and in some markets by law. That has to be settled before the pipeline is designed, not after.
Who buys this
Retailers, Marketplaces, Pricing software vendors, Brand manufacturers, Distributors
What the API returns
What comes back
- Current observed price per competitor and per matched SKU
- Promotional price separated from list price, with the promotion mechanic recorded
- Delivery charge and threshold, so landed price is comparable
- Stock status and, where published, stock level or lead time
- Change events with the previous value, the new value and the observation timestamp
- Price position: your rank among the competitors tracked for that SKU
- Observation confidence and a reason code when a figure could not be verified
- Historical price series per competitor for trend and seasonality work
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/products/{sku}/prices | Latest observed competitor prices for one of your SKUs |
| POST | /v1/catalogue/sync | Push or update the catalogue and competitor set being tracked |
| GET | /v1/changes | Price, promotion and availability changes since a cursor |
| GET | /v1/products/{sku}/history | Historical observed price series per competitor |
| POST | /v1/alerts/rules | Define undercut, availability and promotion alert rules |
| WS | /v1/stream | Push change events as observations land |
Request and response
illustrativeRequest
{
"sku": "KT-4480-BLK",
"competitors": ["rival-a", "rival-b", "marketplace-c"],
"include": ["promotions", "delivery", "availability"],
"since": "2026-10-20T00:00:00Z"
}Response
{
"sku": "KT-4480-BLK",
"your_price": 189.00,
"currency": "GBP",
"as_of": "2026-10-22T05:40:00Z",
"position": { "rank": 3, "of": 4, "cheapest": 174.50 },
"observations": [
{
"competitor": "rival-a",
"list_price": 199.00,
"effective_price": 174.50,
"promotion": { "mechanic": "percent_off", "value": 12.3, "ends": "2026-10-26" },
"delivery": { "charge": 0.00, "free_over": 50.00 },
"availability": "in_stock",
"observed_at": "2026-10-22T05:12:00Z",
"confidence": 0.97
},
{
"competitor": "rival-b",
"list_price": 192.99,
"effective_price": 192.99,
"promotion": null,
"delivery": { "charge": 4.95, "free_over": 75.00 },
"availability": "out_of_stock",
"observed_at": "2026-10-22T05:18:00Z",
"confidence": 0.91
}
],
"unverified": [
{ "competitor": "marketplace-c", "reason": "listing_not_matched_with_confidence" }
]
}Where the data comes from
| Permitted public listing pages | Only sources whose terms of use allow automated collection and the storage of observed figures; we review each one and drop the ones that do not |
| Marketplace and retailer APIs | Where an official feed or affiliate programme exists it is used in preference to page collection, because the terms are explicit and the data is cleaner |
| Supplier and distributor price files | Trade price lists you already receive, which anchor the margin calculation behind any repricing rule |
| Your own catalogue and pricing data | SKUs, identifiers, cost prices and current selling prices, so the comparison is against your real margin position |
| Product identifier references | GTIN, EAN, MPN and brand reference data, which is what makes reliable cross-seller matching possible at all |
| Currency and VAT reference data | Cross-border comparison is meaningless without correct tax treatment and conversion |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- A matching layer that resolves a competitor listing to your SKU on identifiers first, then on attributes, with a confidence score and an explicit unmatched state
- Landed-price normalisation: promotion, multi-buy, delivery charge and tax treatment resolved into one comparable figure
- Change detection against the last verified observation, so a layout change on a source does not emit a fake price drop
- Per-source collection scheduling with politeness limits, respecting published crawl directives and rate expectations
- Observation validation — implausible values are quarantined for review rather than published into your pricing engine
- Availability inference where stock is not stated explicitly, reported as inference rather than fact
- Backfilled historical series with gap flags, so a seasonality model is not fitted across missing weeks
- Monitoring on per-source success rate, match rate and observation latency, with alerts when a source degrades
What it changes for the business
Faster reaction
Undercuts are visible the morning they happen rather than at the next manual review.
Protected margin
Knowing a rival is out of stock stops you discounting against a competitor who cannot sell.
Buyer time back
Category managers stop maintaining comparison spreadsheets and start acting on exceptions.
Auditable pricing
Every repricing decision has a timestamped observation behind it, which matters when a supplier asks why.
How it fits into your product
How it embeds
- Change-feed cursor endpoint so your pricing engine pulls only what moved since it last ran
- Webhooks into Slack, email or your own rules engine when an undercut rule fires
- Direct connectors for the common commerce platforms, or a CSV and SFTP drop if that is what your ERP speaks
- Catalogue sync by API or scheduled file, with match review queues for the ambiguous cases
- Deployment inside your own cloud account where the collected data must stay under your control
- Per-user entitlements so competitor identities can be masked from staff who should not see them
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Can you monitor any website we name?
No, and we would rather say that at the start. Some sites prohibit automated collection in their terms, some are protected by contractual arrangements you may already be party to, and some jurisdictions treat the question differently again. During discovery we review each source you want and tell you which are usable, which need an official feed instead, and which we will not touch.
May we show competitor prices to our own customers?
That is a separate question from whether you may collect them, and the answer is often no. Observing a figure for internal pricing is not the same as republishing it in your storefront. We design the API so internal-only sources are flagged and cannot leak into a customer-facing response by accident.
How often is each competitor checked?
It depends on the source and on what it allows. Fast-moving marketplace listings on an official feed can be refreshed many times a day; a source that only permits light collection might be daily. Every observation carries its own timestamp so your rules can require freshness rather than assume it.
What happens when matching is uncertain?
The API returns the listing as unmatched with a reason code instead of guessing. A wrong match is worse than a missing one, because it feeds a bad price into an automated rule. Ambiguous cases go to a review queue your merchandisers can clear in bulk.
Will this reprice our catalogue automatically?
Only if you build that on top, and we would advise starting without it. The API supplies observations and change events; the rules about how far you will follow a competitor down, and which SKUs you never discount, belong in your business, not in ours.
Related blueprints
Product Matching API
Decide whether two listings are the same product despite different titles, SKUs and images, with a confidence score and the evidence behind it.
Promotion Optimisation API
Measured promotion effectiveness and margin-aware discount recommendations, so a promotional calendar is built on what actually worked.
Demand Forecasting API
SKU-level demand forecasts by location and period, with prediction intervals your replenishment and planning tools can order against.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.