Annotation cascade, typo tolerance, business synonyms, industry rule packs: it's all there, packaged, ready to plug into your catalog in a few API calls. Not a kit to assemble: a complete engine.
Regex rules organized in levels: level 1 recognizes raw patterns in text ("m8" → diameter, "20" after an "x" → length), level 2 composes those annotations together (diameter + length → full reference). Documents and queries go through the same cascade: matching happens in a shared space, not just on words.
"m8x20" → DIAM_M8 + LONG_20 → VIS_M8X20
"M8 x 20 — A2" (product record) → same result6205-2RS, W32L34, M8.5: normalization preserves internal separators (dots, dashes, slashes) so these references stay a single token, instead of being shattered into meaningless pieces.
Product structure →Bounded Damerau-Levenshtein distance: 1 typo tolerated from 4 characters, 2 beyond 8. On numeric references, tolerance is capped at 1 typo: a changed digit means a different product, not a typo.
See the live demo above →"Screw", "SCREW", "screw": same normalized query, same results. Normalization applies identically to indexed documents and queries, before any other step.
"stainless screw max 20 EUR" filters on price instead of searching your catalog for the words "max" and "EUR". Without that reading, those words count as terms and widen the search instead of narrowing it. The recognized fragment is stripped from the query, so it never weighs on relevance, and the constraint comes back in the response so you can show it and let the shopper clear it.
"stainless screw" 1,656 results
"stainless screw max 20" 2,095 the words count
"stainless screw max 20 EUR" 1,363 price_filter max 20.0Eleven packs ship with the engine: hardware (DIN/ISO standards, diameters, materials), fashion (compound sizes, colors, materials, seasons), industry (bearings, fittings, rated pressure), automotive (OEM references, engine type), electrical (ratings, cross-sections, designations), plumbing (threads, nominal diameters), books (genres, formats, ISBN), electronics (connectors, power, battery life), wine & spirits (vintage, format, proof), finance & accounting, sport & surf (liter volumes, standardized sizes, string patterns). For a need beyond a single Custom Rule (patterns combining two numbers, for example), a fully custom pack remains available on Scale plans.
Endpoint /v1/rulepacks →A fashion catalog left on the hardware pack never finds out on its own. The endpoint annotates a sample of your catalog with every available pack and compares the real coverage: actual content decides, not the vertical declared at signup. Never changes anything: the suggestion is shown, the decision stays yours.
A winner without its gap can't be judged: marge says by how much the leader is ahead of its best competitor, and on which criterion. When that criterion is null, both packs annotate exactly as much — the engine then recommends nothing rather than letting alphabetical order decide.
GET /v1/index/{catalog}/rulepack-suggestion
→ {"recommande": "mode", "raison": "...",
"marge": {"second": "outillage", "produits_annotes": 31.67,
"annotations_distinctes": 14.0,
"critere": "produits_annotes"}}
POST /v1/rulepacks/suggest same response, before any import"mode" is the fashion pack and "outillage" the hardware one: recommande and second carry the engine's own names, in French, whatever language you call from.
Add your own recognition rules on top of an existing pack, with no regex to write, directly from the console. A keyword that should always point to the same label ("drywall anchor", "molly bolt" → a single concept), or a prefix followed by a number (RAL codes, DIN standards, shades). Immediate effect on your search, specific to each catalog, never shared with other Heurix accounts.
POST /v1/index/{catalog}/custom-rules
{"rule_type": "keyword", "label": "Anchor",
"keywords": ["drywall anchor", "molly bolt", "toggle anchor"]}"Screw" finds "bolt", "drill" finds "driver". Synonym groups are API-managed, with automatic merging of groups that share a term, with no manual duplicate handling.
PUT /v1/index/{catalog}/synonyms
{"groups": [["screw", "bolt", "fastener"]]}Every search that returns nothing is already a signal: a customer who didn't find it. The endpoint compares that term to your catalog's real vocabulary using the same typo tolerance as search itself, never AI and never guessed. Numeric references are excluded by design: pairing two different products would be the worst possible false synonym, invisible precisely because it looks plausible. You decide; nothing is created without approval.
GET /v1/index/{catalog}/synonym-suggestions?q=washr
→ {"suggestions": [{"jeton": "washr", "candidats": [...]}]}Filter by genre, format, dimension, material... with disjunctive counting per group: selecting "Pocket" doesn't erase the other formats from the count, exactly like a standard e-commerce filter sidebar. This is what powers the prisms in the homepage demo.
{"q": "polar", "facets": ["FORMAT"], "filters": ["FORMAT_POCHE"]}
→ "facets": {"FORMAT": {"FORMAT_POCHE": 17, "FORMAT_BROCHE": 9, ...}}A multilingual site, multiple brands? Query several catalogs in one call, results merged by relevance, each result flagged with its source. Scoring weights are global to the engine: comparable across catalogs, even with different rule packs.
POST /v1/federated-search
{"catalogs": ["store-fr", "store-en"], "q": "red sweater"}You supply the point; the engine filters around it. Browser geolocation, address geocoding or a plain postcode are yours to handle: Heurix receives a lat/lon pair and a radius, and returns what falls inside. It determines no position and calls no mapping service.
"A surf school within 15 km." Give a point and a distance: the engine returns only what falls inside, and every result carries its distance in kilometres — enough to sort or display without recomputing anything. That is the brick behind a store locator or a branch network: list only the nearby ones, nearest first if you sort them yourself. Your products carry lat and lon like any other field, with no reindexing.
The radius filters; it does not enter the score. A place 3 km away does not outrank one 14 km away if it matches the query less well. That is a decision, not a limitation: blending distance into relevance would surface the wrong result because it happens to be near, and you would no longer know which of the two criteria decided.
POST /v1/index/branches/search
{"q": "surf school", "lat": 45.00, "lon": -1.20, "radius_km": 15}One account, as many catalogs as you need: per language, per brand, per site. Each catalog has its own rule pack, its own synonyms, its own index.
Indexing endpoint →No internal search on your site yet? This standalone script (zero dependencies) renders a search bar connected to your catalog in three lines of configuration: input, live results, facets, keyboard navigation. Not a requirement if you'd rather code your own interface, but an immediate starting point if you're building from scratch.
Documentation and example →Connect Heurix to Claude Desktop, Cursor, or an internal agent: three tools exposed natively (search, Browse, catalog statistics). A team member asks "do I have M8 screws in stock?" in natural language, the agent bridges to your API, without ever having to call it themselves.
Installation guide →A category or department page has no query to process, just products to rank well. An engine distinct from search, on your own categories.
Replace a static sort with a ranking that accounts for stock, price, margin, freshness, or actual popularity (clicks and purchases reported by the tracker). The category is a field you supply at indexing time — categories or category — just like the name or the stock level, not a notion Heurix guesses or imposes.
GET /v1/browse/mycatalog/drills-drivers?sort=price_ascPin a product at the top of a category for a one-off feature, or discreetly bury one at the end of the list, with no code changes and no unindexing. Natural ranking automatically resumes as soon as the priority is removed.
Weighted fields (reference > name > description), a composite score including shared annotations, then availability as a tiebreaker at equal score: an out-of-stock product never outranks an equivalent available one.
Search endpoint →When several products answer a query equally well, the one that actually sells takes the lead, not a plain text-relevance sort. Never strong enough to overturn a real gap: only to break a near-tie. A product with an exact match always stays ahead, whatever the other product's popularity. Requires the Tracker installed; without it, ranking stays unchanged.
How it works →Every result includes a matched field listing why it ranks: term found, typo corrected, shared annotation. It's your diagnostic tool when a result surprises you.
"matched": ["annotation #VIS_M8X20", "terme 'stainless'"]The terme and annotation prefixes are emitted by the engine in French, in every language.
See at a glance why a result ranks, right in your own interface: exact positions of every match, per field, to wrap the relevant fragment with a simple <mark>. Reflects what this specific search actually triggered, never every characteristic the product happens to have.
"highlights": {"name": [[0, 3], [13, 18]]}Up to 5,000 products per call, automatic upsert on the identifier, catalog created on the fly from the first send.
Indexing endpoint →Public counting rules (1 search = 1 request, indexing never counted), usage available in real time via the API. Never a surprise cutoff on overage.
How counting works →Engine designed and built in France, OVH hosting (Gravelines or Strasbourg). Your catalogs never leave the European Union.
Our story →Report your clicks and purchases from your site — Heurix Tracker (persistent visitor identifier), a Google Tag Manager tag template, or a direct JavaScript snippet — to see the click-through rate on your searches, the revenue and margin that follow, and your best-selling products — and, for each one, what actually gets bought alongside it, from real basket counting. With the tracker installed, go further than a simple correlation: revenue actually attributed, counted only when the same visitor clicked from a search before buying.
Conversion & ROI endpoint →Two visitors typing the same search don't necessarily share the same intent. A behavior signal, explainable end to end, never a black box you couldn't justify.
Combines a visitor's search precision (a precise reference rather than a generic word) with their click-through rate: the only two signals the score is made of, never collapsed into a single number you couldn't explain to a customer asking why. Average basket is provided alongside, for context, never mixed in.
Intent score endpoint →Split every active visitor into three intent tiers, compared against the previous period. Aggregated counts, never a nominal list: Heurix only knows a visitor by a pseudonymous identifier, never a name or an email.
Segmentation endpoint →Results factor in what this visitor has already bought or viewed, without becoming a black box: ranking still runs on the same annotations as the rest of the engine, never a separate opaque model. Never strong enough to overturn a real relevance gap, only to break a near-tie. Requires the Tracker installed; without it, ranking stays unchanged.
Search endpoint →14-day free trial: up to 2,000 requests and 2,000 products, no credit card.