Skip to main content
POST
Match
The value moment. Given a user_id and a domain, the platform runs the pipeline against the most specific model available for your tenant (general → domain → tenant-tuned):
Each stage hands a smaller candidate set to the next so the expensive stages only see candidates worth their time. You can toggle or tune any stage per request.

Tuning the pipeline

The stages object accepts a boolean shortcut or a per-stage config. Mix freely.
Set "explain": true to get per-candidate stage_scores and human-readable reasons in the response.

Example response

pipeline_stats lets you see, per request, how the candidate pool narrowed. Useful when tuning: if after_light_ml is too small, your min_score is too aggressive. If after_sql_filter is huge, your hard filters aren’t pulling their weight.
Latency budget: with llm_judge off, p99 is typically under 200ms on a 10M-user index. Turning the judge on adds 1-3 seconds per request. Reserve it for the final-decision call, not exploratory queries.

Authorizations

Authorization
string
header
required

API key issued by Jean Technologies. Contact the team for access.

Body

application/json
user_id
string
required
Example:

"u_alice"

domain
string
required
Example:

"dating"

limit
integer
default:10
Required range: 1 <= x <= 100
Example:

10

filters
object

Hard constraints applied before ranking.

Example:
stages
object

Per-stage controls. Each stage can be toggled on or off, or passed a config object for finer control. Omit the whole object to accept sensible defaults for the domain.

Example:
explain
boolean
default:false

If true, response includes per-stage stage_scores and human-readable reasons for each candidate.

Response

Ranked candidates

matches
object[]
pipeline_stats
object
models_used
object

Which model tier and version served each stage. Log alongside outcomes to attribute lift to a specific deploy.

Example: