Recommendation systems

Recommendation engine API

Catalogue in, events in, ranked slate out. What the endpoints look like, what to check before you integrate against one, and how the NeuronSearchLab API is put together.

What is a recommendation engine API?

A recommendation engine API is an HTTP interface that returns a ranked list of catalogue items for a user or context. You supply a catalogue and a stream of interaction events; the API answers requests such as “what should this user see on the homepage” or “what is related to this item” with an ordered list of item identifiers, usually within tens of milliseconds.

The value of the API form is that the ranking becomes a service rather than a library. Your application asks a question and renders an answer; the model, the features, the retraining schedule and the serving infrastructure sit on the other side of one stable contract. That contract is the thing worth scrutinising, because it is what you are actually buying.

The NeuronSearchLab recommendation API

NeuronSearchLab is an API-first recommendation platform for building, evaluating and operating personalised recommendations.

The API base is https://api.neuronsearchlab.com. Authentication is OAuth 2.0 client credentials against https://auth.neuronsearchlab.com/oauth2/token, which returns a bearer token carrying the neuronsearchlab-api/read and neuronsearchlab-api/write scopes. There are JavaScript and PHP SDKs, a Vercel integration, an MCP server and a ChatGPT plugin over the same platform.

A single recommendation model gives you one fixed way of ranking. NeuronSearchLab trains and compares several architectures on your own data, keeps the winner behind one unchanging API, and gives you evaluation, experimentation, explainability and editorial control over whatever is serving.

The endpoints

Four core endpoint groups, plus the platform API behind the console. Full reference in the API documentation.

Catalogue

POST /v1/items, GET /v1/items, GET /PATCH /DELETE /v1/items/{item_id} - create, list, read, update and remove catalogue items with their metadata and any embeddings you attach.

Events

POST /v1/events, GET /v1/events, GET /v1/events/{event_id} - record and inspect interactions. Event types and signal templates are configurable, so a custom event such as a completion or a subscription counts as a first-class signal rather than being flattened into a click.

Recommendations

GET /v1/recommendations - the ranked slate, for a user, an item or a context. A context is a named surface with its own pipeline configuration and rules, so the same integration serves a homepage rail and a product detail page differently without branching in your code.

Search

POST /v1/search - personalised search over the same catalogue and the same signals, so search and recommendation results do not disagree about what a user is interested in.

Platform

Beyond the core four: contexts and rules, pipelines and rerank controls, segments, experiments, models and model families, training jobs with approve and promote steps, serving endpoints, analytics and explainability - all reachable through the platform API, the console or the MCP server.

What an integration involves

Four steps, in this order. The first ranked result usually arrives on the same day as the first event.

01 · Credentials

Create a client in the console, exchange it for a bearer token, and scope the key to the tenant it belongs to. Keys are rotated and revoked from the same place.

02 · Catalogue

Push items with their metadata. If you already produce embeddings - from a multimodal model, a text encoder or something your own team trained - attach them here and retrieval and ranking will use them.

03 · Events

Stream interactions as they happen. Define the event types that matter to your business rather than mapping everything onto a generic click, and backfill history so the first model is not starting from zero.

04 · Request

Call the recommendations endpoint with a user, an item or a context. The context determines which pipeline, which rules and which model version answer, so a surface can be changed without touching the calling code.

What to check before you integrate

Six questions that are cheap to ask now and expensive to discover later. Worth asking of every vendor in this category, us included.

The data contract

What has to be true of your catalogue and events before anything works. Required identifiers, how item updates propagate, whether historical events can be backfilled, and what happens to an item with no interactions at all.

Latency and where it runs

p95, not average, and the region. A recommendation call is in the render path; a 200 ms p95 on the other side of an ocean is a design constraint on your page, not a footnote.

Filtering and rules at request time

Whether stock, licensing, region, consent state or editorial decisions can be applied to the slate as it is built, rather than filtered afterwards by your own code - which quietly shortens every result set and breaks pagination.

Idempotency and failure behaviour

What the API returns when the model is cold, when the user is unknown, and when a downstream stage times out. A recommendation endpoint that fails closed takes the page down with it; one that falls back to a sensible default does not.

Whether the model behind it can change

The endpoint is the contract; the model behind it should be free to improve. Check that swapping the architecture, the embedding provider or the model version is not a re-integration.

What you can read back

Per-request explanations, per-model metrics, per-surface analytics. If the only observable output is the slate itself, every future question about why a recommendation happened is unanswerable.

What sits behind the endpoint

A recommendation API is only as good as what you can do to the thing answering it. These are the platform capabilities NSL exposes behind the same integration.

  • Several recommender architectures trained on your data and compared like for like, with the winner serving behind an unchanged endpoint
  • Your own embeddings attached to items and used for retrieval and ranking, from any provider
  • A rules engine covering boost, bury, pin, filter, cap, dedupe, reorder and group, scoped per context and applied at request time
  • Shadow and canary releases with conditional promotion and automatic rollback
  • Per-result explainability: scores, rules and pipeline stages for one item in one slate
  • A/B testing of ranking strategies, with results attributed to the variant
  • Segments defined from behaviour, demographics and item interactions
  • Analytics across relevance, engagement, coverage, diversity, novelty, latency and cost

The NSL Recommender Leaderboard is the public version of the model-comparison work: complete recommender systems measured on ten public datasets, with methodology, downloadable results and every caveat published.

Other recommendation APIs

Six products commonly evaluated alongside NSL, on the dimensions that matter to an integration. Sourced from each vendor’s public documentation.

ProductRecommendation APIEditorial controlsExplainabilityReal-time updatesDeployment options
NeuronSearchLabRecommendation platform: build, evaluate, operateDocumentedDocumentedDocumentedDocumentedPartly
RecombeeRecommendation-as-a-service APIDocumentedDocumentedNot documentedDocumentedPartly
Amazon PersonalizeManaged recommendation service on AWSDocumentedPartlyNot documentedDocumentedPartly
Algolia RecommendRecommendation add-on to a hosted search indexDocumentedDocumentedNot documentedPartlyPartly
Dynamic YieldPersonalisation and experimentation suiteDocumentedDocumentedNot documentedDocumentedPartly
BloomreachCommerce search, merchandising and marketing suiteDocumentedDocumentedPartlyPartlyPartly
NostoCommerce experience platformDocumentedDocumentedNot documentedDocumentedPartly

How to read this table

  • Documented - the vendor’s own public documentation describes this as a capability.
  • Partly - documented, with a material limit named in the cell.
  • Not documented - we could not find it in the public documentation. That is not the same as it not existing. Ask the vendor.
  • Out of scope - the documentation says it is not part of the product.

Compiled from public documentation on 19 September 2026. Products change; every claim links to the page it came from, so check the source before you rely on it. Nothing here is scored, ranked or totalled.

Frequently asked questions

What is a recommendation engine API?

A recommendation engine API is an HTTP interface that returns a ranked list of catalogue items for a user or context. You supply a catalogue and a stream of interaction events, and the API answers requests such as 'what should this user see on the homepage' or 'what is related to this item' with an ordered list of item identifiers, usually within tens of milliseconds.

What endpoints does a recommendation API normally have?

Three groups. Catalogue endpoints to create, update and delete items. Event endpoints to record interactions such as views, clicks, plays and purchases. Recommendation endpoints to request a ranked slate for a user, an item or a context. Mature products add search, explainability, experiment and model-management endpoints on top.

What is the NeuronSearchLab API base URL?

https://api.neuronsearchlab.com. Authentication is OAuth 2.0 client credentials against https://auth.neuronsearchlab.com/oauth2/token, returning a bearer token with the neuronsearchlab-api/read and neuronsearchlab-api/write scopes.

How fast should a recommendation API be?

A recommendation request sits in the render path of a page, so the practical budget is tens of milliseconds at p95, including your own network hop. Anything that pushes past about 100 ms starts to be felt. Ask any vendor for p95 rather than average, and ask where the service runs relative to your application.

Can I filter or override what a recommendation API returns?

On most products, yes, and the mechanism is the thing to check. Some expose a query language evaluated at request time; some expose rules configured in a console; some only support hard filters. The NeuronSearchLab rules engine supports boost, bury, pin, filter, cap, dedupe, reorder and group, scoped to a context and applied at request time without a retrain or a redeploy.

Can an AI agent call a recommendation API?

Yes. NeuronSearchLab publishes an MCP server and a ChatGPT plugin alongside the HTTP API, so an agent can request recommendations, inspect items and users, and manage contexts and rules through the same platform an application integrates against.

Related reading

Make your first request

Create a key, push a catalogue, send events, call the endpoint. The free tier includes 1,000 recommendation requests a month and needs no card.