Home/Offers/E-commerce & Retail/Product Matching API

E-commerce & Retail

Product Matching API

The same vacuum cleaner is listed nine different ways across nine sellers. Every downstream feature you want to build — comparison, repricing, assortment analysis — depends on knowing those nine are one product.

Marketplaces
Price comparison sites
Retailers
Distributors
Commerce data vendors

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Product identity is the unglamorous foundation of almost every commerce data product, and it is where most of them quietly fail. Titles are written by whoever uploaded the listing. Bundles are sold as single items. Colour and capacity variants share a model number. Barcodes are missing, wrong, or reused across a product family.

Teams usually begin with exact identifier matching, which works for perhaps half the catalogue, then add fuzzy title matching, which produces confident nonsense — a 256GB phone matched to the 128GB version, a four-pack matched to a single. The cost of that error is not abstract: it reprices the wrong item or tells a buyer two incomparable things are comparable.

Getting this right means treating it as a classification problem with a rejection option rather than a similarity search. The system has to be allowed to say it does not know, because for a reasonable share of real listings that is the honest answer, and a human reviewing two hundred ambiguous pairs is far cheaper than an automated rule acting on two hundred wrong ones.

Who buys this

Marketplaces, Price comparison sites, Retailers, Distributors, Commerce data vendors

Category: E-commerce & Retail

What the API returns

What comes back

Match decision per candidate pair: match, variant-of, bundle-containing, or no match
Confidence score with a calibrated threshold you set per use case
The evidence behind each decision — which identifiers, attributes and image features agreed
Extracted normalised attributes: brand, model, capacity, colour, pack size, units
Variant grouping, so colours and sizes cluster under one parent product
Bundle and multipack detection with the implied unit count
Cluster identifiers that stay stable as new listings arrive
An explicit review queue of pairs the model deliberately declined to decide

Endpoints

Method	Path	Returns
POST	/v1/match	Match one listing against a candidate set or your master catalogue
POST	/v1/match/batch	Batch matching for catalogue-scale runs
POST	/v1/attributes/extract	Extract normalised attributes from a title, description and image
GET	/v1/clusters/{id}	All listings currently grouped under one product cluster
POST	/v1/review/decisions	Submit human decisions on queued pairs to retrain the thresholds
GET	/v1/review/queue	Pairs awaiting human adjudication, ranked by value

Request and response

illustrative

Request

{
  "listing": {
    "title": "Dyson V15 Detect Absolute Cordless Vacuum - Gold, 2 Year Warranty",
    "brand": "Dyson",
    "gtin": null,
    "mpn": "447294-01",
    "price": 599.00,
    "image_url": "https://seller.example.com/i/447294.jpg"
  },
  "match_against": "master_catalogue",
  "min_confidence": 0.90,
  "return_evidence": true
}

Response

{
  "decision": "match",
  "confidence": 0.962,
  "matched_to": {
    "cluster_id": "pc_01HX8K2",
    "canonical_title": "Dyson V15 Detect Absolute cordless vacuum cleaner",
    "master_sku": "VAC-DY-V15DA"
  },
  "normalised_attributes": {
    "brand": "Dyson",
    "model": "V15 Detect Absolute",
    "colour": "gold",
    "pack_size": 1,
    "bundle": false
  },
  "evidence": [
    { "signal": "mpn_exact", "agreement": 1.00, "weight": 0.41 },
    { "signal": "model_token_match", "agreement": 0.95, "weight": 0.22 },
    { "signal": "image_embedding_similarity", "agreement": 0.89, "weight": 0.18 },
    { "signal": "price_band_plausibility", "agreement": 0.74, "weight": 0.09 }
  ],
  "rejected_candidates": [
    { "cluster_id": "pc_01HX8K9", "reason": "variant_mismatch_colour", "confidence": 0.61 }
  ],
  "warranty_text_ignored": true
}

Where the data comes from

Your master catalogue	The canonical products you want everything matched into, with whatever identifiers and attributes you already hold
Listing data you are permitted to use	Marketplace feeds, affiliate catalogues or supplier files — collection terms are checked per source before anything is ingested, and sources that forbid it are excluded
GTIN and brand reference data	Licensed identifier registries, which resolve a large share of pairs outright and anchor everything else
Manufacturer specification sheets	The authoritative source for which model numbers are genuinely different products rather than regional codes
Product images	Image similarity carries real signal where titles are unhelpful, subject to the usage rights attached to the images
Your historical human decisions	Past merchandiser adjudications, which are the single most valuable training input and usually already sitting in a database

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

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 pairwise classifier over identifier, text, attribute and image features rather than a single similarity metric, because the signals disagree in informative ways
Blocking and candidate generation first, so catalogue-scale matching does not become a quadratic comparison
Text embeddings combined with rule-based extraction for the attributes that must be exact — capacity, pack size, voltage, model suffix
Image embeddings used as corroboration only; sellers reuse stock photography across variants, so images alone mislead
A rejection option with calibrated thresholds, tuned separately for high-stakes repricing and low-stakes browsing
Active learning on the review queue, prioritising the pairs whose adjudication improves the model most
Precision and recall reported per product category, since consumer electronics and apparel behave nothing alike
Drift monitoring on match rate and confidence distribution, which is how you find out a seller changed their title format

What it changes for the business

Comparison that holds up

Downstream pricing and assortment features stop being undermined by bad identity.

Less manual reconciliation

Merchandisers adjudicate a small ranked queue instead of auditing the whole catalogue.

Cleaner onboarding

New seller or supplier feeds map into your catalogue in hours rather than weeks.

Fewer wrong decisions

An explicit no-match state keeps mismatched products out of automated rules.

How it fits into your product

How it embeds

Synchronous endpoint for real-time matching during seller onboarding or listing creation
Batch endpoint with job polling for full-catalogue reconciliation runs
Stable cluster identifiers your database can key on, with documented merge and split events
A review queue API your existing admin tooling can render, plus a feedback endpoint that closes the loop
Deployment inside your environment where catalogue and supplier data cannot leave
Confidence thresholds configurable per category and per downstream consumer

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 20 weeks

Discovery and feasibility

Weeks 1–3

This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.

Architecture and baseline model

Weeks 4–6

A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.

Production build

Weeks 7–16

Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.

Validation and integration

Weeks 17–20

Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.

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

What accuracy can you promise?

None before we have seen your data. Accuracy depends almost entirely on identifier coverage and category: a catalogue with good GTINs in consumer electronics behaves very differently from unbranded apparel with free-text titles. The prototype phase exists to measure it on your records and report the real figure, per category, including the share we cannot decide.

Can it match everything automatically?

No. A proportion of real listings are genuinely ambiguous — regional model codes, retailer-exclusive variants, bundles described loosely. For those the API declines and queues the pair. Designing for a human in the loop is not a shortcoming; pretending the ambiguity does not exist is how these systems fail quietly.

Where does the listing data come from?

From you, or from sources we have confirmed permit it. We do not assume that a page being publicly visible means its contents may be collected, stored and used to build a commercial dataset. Official feeds and licensed catalogues are preferred precisely because the permission is unambiguous.

Does it handle variants and bundles?

Yes, as distinct outcomes. A listing can be a variant of a cluster or a bundle containing it, and collapsing those into a plain match is a common and expensive error. The decision field distinguishes them so your pricing logic can treat them differently.

Can we use our existing manual decisions?

We would want to. Historical merchandiser adjudications are the best training data available for this problem, and they are usually already stored somewhere. If you have none, the first weeks of the review queue generate them.

All E-commerce & Retail offers →

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.

Discuss This Build Browse All Offers