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

E-commerce & Retail

Product Recommendation API

Your recommendation slots are probably filled by best-sellers. That is not personalisation — it is a popularity chart with a personalised label on it.

Marketplaces
Retailers
Commerce platform vendors
Direct-to-consumer brands
Retail media networks

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

Nearly every storefront has the slots already built: customers also bought, complete the look, recommended for you. What sits behind them is usually a popularity query with a category filter, because the team that built the slot never got budget for the model that was supposed to fill it.

The result is predictable. Shoppers are shown the same twelve best-sellers everywhere, accessories are recommended for products the customer already owns, and anything outside the head of the catalogue is effectively invisible. On a marketplace that is also a seller-fairness problem: new listings never accumulate the engagement they would need to be surfaced.

The engineering is well understood — collaborative filtering, content-based retrieval, sequence models, a ranking layer with business constraints on top. The parts that actually decide whether it works are less glamorous: cold-start handling, respecting margin and stock constraints in the ranking, and an online test harness that tells you honestly whether a change helped.

Who buys this

Marketplaces, Retailers, Commerce platform vendors, Direct-to-consumer brands, Retail media networks

Category: E-commerce & Retail

What the API returns

What comes back

Ranked recommendations for a given context: home, product page, basket, email, search null-result
Complementary-item suggestions distinguished from substitutes, which are not interchangeable in a slot
Similar-item retrieval for out-of-stock and discontinued substitution
Basket completion with accessory and consumable logic
Cold-start recommendations for new users and new items from attributes and context
Business constraints applied in ranking: stock, margin, seller diversity, excluded brands
Per-recommendation explanation strings suitable for display
Experiment assignment and per-variant performance reporting

Endpoints

Method	Path	Returns
POST	/v1/recommend	Ranked recommendations for a user and context
GET	/v1/products/{id}/similar	Substitutes for an unavailable or discontinued item
POST	/v1/basket/complete	Complementary items for a basket
POST	/v1/events	Stream view, add-to-basket, purchase and return events
POST	/v1/experiments	Define and assign ranking experiments
GET	/v1/experiments/{id}/results	Measured performance per variant

Request and response

illustrative

Request

{
  "context": "product_page",
  "user": { "id": "u_88213", "consent": { "personalisation": true } },
  "anchor_product": "VAC-DY-V15DA",
  "slots": 6,
  "constraints": {
    "in_stock_only": true,
    "exclude_owned": true,
    "min_margin_pct": 12,
    "max_per_seller": 2
  }
}

Response

{
  "context": "product_page",
  "strategy": "sequence_model_v4+rerank",
  "experiment": { "id": "exp_rerank_margin", "variant": "B" },
  "recommendations": [
    { "product_id": "VAC-DY-FILT-2PK", "score": 0.91, "relation": "complementary",
      "reason": "Replacement filter for the item being viewed", "margin_pct": 38.2 },
    { "product_id": "VAC-DY-WAND-EXT", "score": 0.84, "relation": "complementary",
      "reason": "Frequently bought together", "margin_pct": 31.0 },
    { "product_id": "VAC-SH-DETECT9", "score": 0.72, "relation": "substitute",
      "reason": "Similar specification, lower price", "margin_pct": 19.4 }
  ],
  "cold_start": false,
  "suppressed": [
    { "product_id": "VAC-DY-V15DA", "reason": "anchor_item" },
    { "product_id": "VAC-DY-V11", "reason": "out_of_stock" }
  ],
  "fallback_used": null
}

Where the data comes from

Your behavioural event stream	Views, searches, basket additions, purchases and returns — the primary signal, and the only one that reflects your actual shoppers
Your catalogue and attributes	Categories, attributes, images and descriptions, which carry the cold-start and content-based retrieval
Stock and margin data	A recommendation for an unavailable or loss-making item is worse than no recommendation
Product relationship data	Compatibility, consumables and accessory mappings, often held in a supplier file nobody has connected
Consent and preference records	Whether a given user may be personalised at all, which varies by jurisdiction and by what they agreed to
Return reasons	Optional, and underused — recommending an item a cohort consistently returns is a false positive worth removing

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 retrieval-then-rank architecture: cheap candidate generation over the full catalogue, then an expensive ranker over a few hundred items
Sequence-aware models over session behaviour, because what a shopper looked at three minutes ago matters more than what they bought in March
Content-based embeddings from attributes, text and images to cover items with no interaction history
Explicit separation of complement and substitute relations, learned from co-purchase and co-view patterns respectively
Constrained re-ranking that applies stock, margin and seller-diversity rules without destroying relevance ordering
Popularity debiasing so the head of the catalogue does not crowd out everything a shopper would actually prefer
Offline evaluation on held-out sessions plus an online A/B harness, because offline metrics and revenue regularly disagree
Latency budgeting and monitoring — a recommender that answers in 400ms will be removed from the page regardless of its accuracy

What it changes for the business

Better slot performance

Existing recommendation slots start earning their place on the page instead of repeating the best-seller list.

Larger baskets

Genuine complement detection moves accessories and consumables that currently rely on the shopper knowing to look.

Catalogue depth gets seen

Popularity debiasing surfaces the long tail, which matters most to marketplaces with seller-fairness obligations.

Measurable change

An experiment harness means ranking decisions are settled by results rather than by opinion in a meeting.

How it fits into your product

How it embeds

Single low-latency POST per slot, cached where the context allows, with a documented latency budget and a static fallback
Event ingestion by SDK, server-side API or batch, depending on where your tracking already lives
Platform connectors for the common commerce stacks, plus a generic JSON contract for bespoke storefronts
Server-side rendering support so recommendations are indexable and not blocked by consent tooling
Experiment assignment returned in the response so your analytics can attribute outcomes without a second integration
Multi-tenant keys if you are a platform serving recommendations to many merchants from one integration

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

Do you need personal data?

Less than most people assume. Session behaviour alone, with no identity at all, drives a large share of the value. Where you do personalise across sessions we work within the consent you hold, and the API accepts a consent flag so an unconsented user falls back to session-only ranking rather than being silently personalised anyway.

Will this definitely increase revenue?

We will not promise a number. Recommendation gains depend on how much traffic flows through the slots, what is in them today, and catalogue depth — a site already running a decent recommender has less headroom than one showing best-sellers. That is exactly why the experiment harness is part of the build rather than an extra.

How is cold start handled for new items?

Content-based retrieval from attributes, text and images, with a controlled exploration budget so new items get impressions they could not otherwise earn. It is weaker than behavioural ranking and the response marks it as cold-start so you can treat it accordingly.

Can we force certain products into the results?

Yes, through the constraint layer, and we would ask you to be careful with it. Merchandising overrides and paid placement are legitimate, but stacking too many into a slot turns a recommender back into a promotion carousel and the engagement data will show it.

What happens if the service is slow or down?

The integration ships with a documented fallback — cached rankings and a static merchandised list — so the page renders regardless. A recommendation slot should never be able to break your product page.

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