Home/Offers/E-commerce & Retail/Product Content Enrichment API

E-commerce & Retail

Product Content Enrichment API

Half your catalogue is probably missing the attributes your own filters depend on. Shoppers notice this as search that does not work.

Marketplaces
Retailers
Distributors
PIM vendors
Commerce platform 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

Catalogue data arrives from suppliers in whatever shape the supplier felt like sending. One feed puts capacity in the title, another in a free-text spec block, a third omits it. Category assignment is done by whoever uploaded the product, against a taxonomy they do not know well. Dimensions arrive in three unit systems.

The consequences are easy to see and hard to fix. Faceted navigation only works for the subset of products that happen to carry the facet, so filtering by capacity hides perfectly good listings. Search relevance suffers because the matchable text is thin. Feeds to shopping channels get rejected for missing required fields, which quietly removes products from paid traffic.

The usual remedy is a data-entry team working through a backlog that grows faster than they clear it. The automatable share is large — most missing attributes are recoverable from text, images and the manufacturer's own specification, and category assignment is a well-behaved classification problem. The part that cannot be automated is the long tail of genuine ambiguity, which needs a review queue rather than a confident guess.

Who buys this

Marketplaces, Retailers, Distributors, PIM vendors, Commerce platform vendors

Category: E-commerce & Retail

What the API returns

What comes back

Normalised attribute set per product against your own schema, with units standardised
Category assignment against your taxonomy, with confidence and runner-up candidates
Missing-field completion from title, description, images and specification text
Provenance per field: extracted, inferred, inherited from a matched product, or supplier-provided
Generated titles and descriptions built only from verified attributes
Feed-readiness checks against channel requirements such as shopping feed specifications
Image quality and compliance checks: resolution, background, text overlay, aspect ratio
A review queue of fields the model declined to fill, ranked by commercial impact

Endpoints

Method	Path	Returns
POST	/v1/enrich	Enrich one or many products against your schema
POST	/v1/categorise	Assign products to your taxonomy with confidence
POST	/v1/attributes/extract	Extract attributes from unstructured text and images
POST	/v1/feeds/validate	Check products against a channel feed specification
GET	/v1/review/queue	Fields awaiting human completion, ranked by impact
POST	/v1/schema	Define or update your attribute schema and taxonomy

Request and response

illustrative

Request

{
  "products": [
    {
      "id": "SUP-77120",
      "title": "Brevell 1.7L Stainless Kettle Rapid Boil Brushed Steel 3kW",
      "description": "Fast boil kettle with removable limescale filter. 360 base.",
      "supplier_category": "Kitchen > Small Appliances",
      "images": ["https://cdn.example.com/p/77120_1.jpg"]
    }
  ],
  "target_schema": "yourco_v3",
  "fill_missing": true,
  "min_confidence": 0.85
}

Response

{
  "id": "SUP-77120",
  "category": {
    "assigned": "Home & Kitchen > Appliances > Kettles",
    "confidence": 0.97,
    "runner_up": "Home & Kitchen > Appliances > Coffee & Tea"
  },
  "attributes": {
    "brand":        { "value": "Brevell", "provenance": "extracted_title", "confidence": 0.99 },
    "capacity_l":   { "value": 1.7, "provenance": "extracted_title", "confidence": 0.98 },
    "power_w":      { "value": 3000, "provenance": "normalised_from_title", "confidence": 0.96 },
    "material":     { "value": "stainless steel", "provenance": "extracted_title", "confidence": 0.93 },
    "finish":       { "value": "brushed", "provenance": "extracted_title", "confidence": 0.88 },
    "cordless_base":{ "value": true, "provenance": "inferred_description", "confidence": 0.81 },
    "colour":       { "value": null, "provenance": null, "confidence": null }
  },
  "generated_title": "Brevell 1.7L Brushed Stainless Steel Rapid Boil Kettle, 3000W",
  "feed_readiness": {
    "google_shopping": { "ready": false, "missing": ["gtin", "colour"] }
  },
  "image_checks": [
    { "image": "77120_1.jpg", "resolution_ok": true, "white_background": false, "text_overlay": true }
  ],
  "review_queue": [
    { "field": "colour", "reason": "not_stated_and_not_visually_determinable", "impact": "facet_coverage" }
  ]
}

Where the data comes from

Your supplier feeds	The raw product data as it arrives, including the inconsistencies — which are the actual input to this problem
Your schema and taxonomy	The attribute definitions and category tree the output must conform to; enrichment against someone else's taxonomy is of little use
Manufacturer specification sources	Official specification sheets and brand data, used where licensing or a supplier relationship permits it
Product identifier references	GTIN and MPN registries, which allow attributes to be inherited from an already-enriched matched product
Product images	A real source of attributes — colour, form factor, included accessories — subject to the usage rights on the images
Your existing enriched records	Products your team has already completed by hand, which are the best available training and validation data

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.

Hierarchical text classification for category assignment, trained on your taxonomy and your historical assignments rather than a generic tree
Attribute extraction combining pattern rules for well-formed values with a language model for the unstructured remainder
Unit normalisation and value canonicalisation against your schema, including controlled vocabularies for colour and material
Vision models for attributes that are visible rather than written, used only where they validate against a confidence threshold
Attribute inheritance from matched products via identifier resolution, which is usually the highest-precision path available
Field-level confidence with a rejection option, because a wrong attribute propagates into filters and feeds and is worse than a blank
Validation against a held-out sample of your hand-enriched records, reported per attribute and per category rather than as one figure
Monitoring on fill rate, confidence distribution and supplier-level quality, which is how a changed feed format is caught quickly

What it changes for the business

Filters that work

Facet coverage rises across the catalogue, so navigation stops hiding products that qualify.

Faster onboarding

New supplier feeds reach publishable quality in hours rather than sitting in a data-entry backlog.

Channel eligibility

Products stop being rejected from shopping feeds for missing required fields.

Data-entry effort redirected

The team works a ranked queue of genuinely ambiguous fields instead of transcribing recoverable ones.

How it fits into your product

How it embeds

Synchronous enrichment at product-creation time, so items are complete before they are published
Batch endpoints with job polling for full-catalogue backfill runs
Direct connectors into the common PIM and commerce platforms, plus plain file ingestion for warehouse-based catalogues
Field-level provenance in every response, so your PIM can decide what to overwrite and what to protect
Review queue API your merchandising tooling can render, with a feedback endpoint that improves later runs
Deployment inside your environment where supplier agreements restrict where catalogue data may be processed

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 weeks

Discovery 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

Will it fill every missing field?

No, and it should not try. Where a value is not stated, not inferable from the image and not available from a matched product, the API returns null with a reason rather than a plausible guess. A fabricated attribute feeds your filters, your feeds and your product page, and is harder to find later than a blank.

Are descriptions written by a language model?

Generated text is, but under tight constraints: it may only reference attributes that were verified, and every factual claim is checked against the extracted values before the text is returned. Generated copy that fails validation is withheld. We would not ship a system that invents product claims you are legally responsible for.

May we use manufacturer specification data?

Sometimes, and it depends on the source. Brand data supplied under a supplier or distribution agreement is usually fine; bulk collection from a manufacturer's website often is not. We check the terms per source and tell you which routes are open before anything depends on them.

How accurate is category assignment?

High in categories with clear language and plenty of training examples, noticeably weaker at taxonomy boundaries where your own team disagrees. We measure it against your existing assignments and report per-branch accuracy, which usually also reveals where the taxonomy itself is ambiguous.

Can it work with our taxonomy rather than a standard one?

That is the normal arrangement. Enrichment against a generic taxonomy creates a mapping problem rather than solving one. The models are trained against your schema, and schema changes are handled as a retraining event rather than a breaking change.

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