Recommend related content
Every catalogue, blog and knowledge base eventually needs a 'you might also like' row, and building that in-house means embeddings, vector indexes and a team to babysit them. This endpoint takes a source item plus your candidate pool and hands back the closest matches, ranked, so the recommendation logic stops being a project and becomes a line of code.
Run it online
Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.
Who actually needs this
Teams that own a product catalogue, an article archive or a support library run into the same wall: they know which items are related, intuitively, but have no systematic way to surface that at scale. A single editor can hand-pick 'related posts' for fifty articles; nobody can do it for fifty thousand. This is built for that gap — engineering teams at online stores, media sites, course platforms and internal tools who need relatedness without hiring a data scientist to maintain it.
What happens when you call it
You send the item you want recommendations for, along with the pool it should be compared against (or a reference to a dataset you have indexed), and the task runs asynchronously: it returns a task_id immediately and delivers the ranked list of related items through your signed webhook, or through a link valid for 24 hours if you prefer to poll. There is no synchronous request holding a connection open while similarity math happens in the background.
The idea behind semantic relatedness
Classic recommendation systems leaned on co-purchase history or collaborative filtering — useful, but blind to brand-new items with no interaction history yet, the so-called cold-start problem. Content-based recommendation sidesteps that by reading the item itself: its title, description, tags, category, whatever text represents it, and comparing that meaning against every candidate. A product launched an hour ago can be recommended correctly on day one, because the system never needed anyone to buy it first.
Where it sits in your pipeline
Most teams call this endpoint on a schedule — nightly for a full catalogue refresh, or on-demand right after a new item is published — and cache the result behind their storefront or CMS. Because pricing is per request plus per query, a batch job that refreshes recommendations for ten thousand products has a cost you can compute in advance, not a mystery invoice. Failed tasks are retried automatically and never billed, so a transient hiccup does not turn into wasted spend.
What it will not do
This is not a black-box 'AI that reads your mind' system: it will not incorporate purchase history, click-through rates or user sessions unless you feed that context in as part of the item description. It is a precise, honest tool for content and semantic relatedness — pair it with your own behavioral signals if you want a hybrid recommender.
What you can do with it
E-commerce cross-sell
An online store sends each product page to the endpoint and displays the top five related SKUs as 'customers also viewed', refreshed automatically whenever the catalogue changes.
New product launch
A newly added item with zero sales history still gets accurate 'related products' the moment it goes live, because matching is based on description and attributes, not purchase data.
Editorial 'related articles'
A news site runs this nightly against its last two years of published articles so every story automatically links to genuinely relevant past coverage instead of just recent posts.
Internal knowledge base
A support team surfaces related help-center articles at the bottom of every ticket reply, cutting repeat questions by pointing users to documentation that actually matches their issue.
FAQ
How does the recommendation API decide what's related?
It compares the meaning of the source item's text against every candidate in your pool and ranks by semantic closeness, not by keyword overlap or purchase history.
Is there a free tier for search.recommend?
There's no free tier — free tiers get abused and slow everyone down. Access runs on a prepaid ForHosting KIT balance: top up from $10.00 (it never expires) and each request is charged at its published price, so a call with no balance returns HTTP 402. No subscription, no tokens, no invented credits, and a failed task is never charged.
What does it cost to run recommendations for a full catalogue?
Pricing is $0.002 per request plus $0.002 per query, so the total for a batch job is predictable before you run it.
Can it recommend items with no sales history?
Yes. Recommendations are content-based, comparing item text and attributes, so brand-new items work correctly from the first call with no cold-start delay.
How do I get the results back?
Each call returns a task_id immediately; the ranked recommendations are delivered via signed webhook or through a signed link valid for 24 hours.
What happens if a recommendation task fails?
It is retried automatically up to three times, and you are never charged for a task that ultimately fails.
Can I combine this with my own click or purchase data?
Yes — feed relevant behavioral context into the item text you send, or blend the output with your own ranking signals downstream; the endpoint itself works purely from content.
Is this suitable for large catalogues?
Yes, it's designed for bulk use: batch a full catalogue overnight and cache the results, since pricing scales linearly with the number of queries you run.
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, and soon from our app, email and Telegram.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/search/recommend \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"input":"…"}'const res = await fetch("https://api.kit.forhosting.com/search/recommend", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"input": "…"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/search/recommend",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"input": "…"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/search/recommend", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"input":"…"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"input":"…"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/search/recommend", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"input": "…"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "search.recommend",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_chunks | 10000 |
max_tokens | 20000 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |