Home/Offers/Media, Gaming & Sports/Content Recommendation API

Media, Gaming & Sports

Content Recommendation API

Your catalogue is probably larger than your audience ever sees. Most of what goes unwatched is not unwanted — it is simply never surfaced to the person who would have liked it.

Streaming platforms
Publishers
Podcast apps
Video-on-demand operators
Education platforms

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 growth and attention do not scale together. A service with forty thousand titles still shows a visitor five or six rows on a home screen, which means ranking decides what the catalogue effectively is. Editorial curation handles the top of that list well and the long tail badly, and the long tail is where most of the licensing cost sits.

The usual first attempt is a popularity row plus a genre carousel. It works, in the sense that popular things are popular, and it fails in the way that matters: it recommends the same twenty titles to everyone, so the rest of the library earns nothing and subscribers conclude there is nothing new on.

Building the real thing is less about the matrix factorisation and more about the awkward edges. New users with no history. New titles with no interactions. Shared accounts where three people's tastes are mixed into one profile. Rights windows that remove a title mid-session. These are the parts that decide whether a recommender ships or quietly gets switched off.

Who buys this

Streaming platforms, Publishers, Podcast apps, Video-on-demand operators, Education platforms

Category: Media, Gaming & Sports

What the API returns

What comes back

Ranked personalised rows with a reason label per row
Related-item lists for any catalogue entry, including cold items
Next-item and continue-watching ordering for session continuity
Cold-start rankings driven by content features when no history exists
Diversity and novelty controls applied per row, with the trade-off measurable
Profile-level taste vectors you can store and inspect
Candidate explanations: which signals contributed to each placement
Availability filtering so expired or geo-restricted titles never appear

Endpoints

Method	Path	Returns
POST	/v1/recommend	Ranked items for one profile in one surface context
GET	/v1/items/{id}/related	Related items for a catalogue entry
POST	/v1/rows	A full home-screen layout of ranked rows
POST	/v1/events	Stream view, completion, skip and rating events
GET	/v1/profiles/{id}/taste	Current taste representation for a profile
POST	/v1/experiments	Register a ranking variant for A/B evaluation

Request and response

illustrative

Request

{
  "profile_id": "prof_2291",
  "surface": "home",
  "locale": "en-GB",
  "available_only": true,
  "rows": ["because_you_watched", "new_for_you", "finish_watching"],
  "diversity": 0.35,
  "limit_per_row": 12
}

Response

{
  "profile_id": "prof_2291",
  "generated_at": "2026-10-22T09:14:03Z",
  "model_version": "rank-2026.09",
  "rows": [
    {
      "row": "because_you_watched",
      "seed_item": "ttl_8841",
      "seed_title": "Northern Line",
      "items": [
        { "item_id": "ttl_9210", "score": 0.874,
          "reasons": ["same_creator", "co_viewed_by_similar_profiles"] },
        { "item_id": "ttl_4417", "score": 0.802,
          "reasons": ["genre_match", "completion_rate_high_in_cohort"] }
      ]
    },
    {
      "row": "new_for_you",
      "items": [
        { "item_id": "ttl_9933", "score": 0.611, "cold_item": true,
          "reasons": ["content_similarity_only"] }
      ]
    }
  ],
  "diagnostics": {
    "profile_events": 184,
    "cold_start": false,
    "catalogue_coverage_in_response": 0.0009,
    "novelty_index": 0.42
  }
}

Where the data comes from

Your interaction logs	Plays, completions, skips, searches and abandonments — the single most valuable input and one you already store
Your catalogue metadata	Titles, genres, cast, crew, synopses, durations and language tracks, which carry the cold-start load
Rights and availability windows	Which title is playable in which territory on which date; without this the ranker recommends things nobody can watch
Derived content features	Embeddings computed from your own synopses, subtitles and artwork, kept inside your environment
Licensed enrichment data	Third-party title databases where your metadata has gaps — licence terms usually restrict redistribution, so these are used for ranking rather than display
Editorial inputs	Curator pins, suppressions and campaign boosts, which must be expressible rather than fought against

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 two-stage architecture: cheap candidate retrieval over the full catalogue, then a heavier re-ranker over a few hundred items, because scoring forty thousand titles per request is not serveable
Collaborative signals combined with content embeddings, so a title with no interactions still has a representation
Implicit feedback handling that treats a skip at four minutes differently from a skip at four seconds
Explicit diversity and novelty terms in the objective, tunable per row rather than globally
Session-aware ranking so the second row is not a reshuffle of the first
Offline evaluation on held-out time periods, then online A/B with pre-registered metrics — offline lift frequently does not survive contact with live traffic
Popularity-bias measurement reported as a standing metric, not a one-off audit
Drift monitoring on catalogue coverage and profile freshness, since a ranker degrades silently rather than erroring

What it changes for the business

Catalogue utilisation

More of the library earns its licensing cost, which is usually a larger number than any engagement metric.

Search abandonment

Fewer sessions end at a search box with nothing chosen.

Editorial leverage

Curators set policy and boosts rather than hand-building every row for every market.

Measurable ranking changes

Each variant ships behind an experiment, so a ranking change has an attributable effect instead of an opinion.

How it fits into your product

How it embeds

Single POST per surface render, with a latency budget set so it fits inside your page load rather than after it
Event ingestion by batch or stream, whichever your client already emits
Availability filtering applied server-side against your rights data so expired titles cannot leak into a row
Editorial override layer: pins, suppressions and campaign slots applied after ranking
Deployment inside your own infrastructure where viewing data cannot leave
Experiment framework with holdout groups so the effect of ranking is always measurable

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 happens with a brand new user?

Cold start is the real constraint, and we would not pretend otherwise. With no history the ranking falls back to content features, locale, device and whatever signal the signup flow legitimately collects — which is meaningfully worse than a warm profile. The API marks these responses as cold_start so you can present them differently rather than silently serving weak recommendations.

Does this create a filter bubble?

A recommender optimised purely for short-term engagement does narrow what people see, and it also over-serves the already-popular. That is a measured outcome, not a theoretical worry. We build diversity and novelty as explicit controls with reported metrics, and we would show you the trade-off curve so the decision about how much variety to inject is yours and visible, rather than an accident of the loss function.

Can editorial still override it?

Yes, and it must be able to. Pins, suppressions, contractual promotion slots and regulatory requirements are applied as a layer over the ranking rather than fought against inside it. Where an override materially changes a row, the diagnostics say so.

How much interaction data is needed before it beats a popularity row?

Enough that profiles have real histories — typically a few months of logged events across an active user base. Below that, content-based ranking plus popularity is often genuinely the better choice, and we would say so during discovery instead of training something thin.

Can we use third-party metadata in the output?

For ranking, usually yes. For display to your users, often no — title databases commonly licence lookup and internal use while prohibiting redistribution. We check the terms per source and design so that anything shown to an end user comes from metadata you are entitled to publish.

All Media, Gaming & Sports 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