Prodejce náhradních dílů na zahradní techniku má e-shop na Shoptet Premium a vedle něj samostatný katalog rozkresů na WordPressu. Zákazník si v katalogu najde díl ve výkresu výrobce a chce vědět, jestli ho e-shop má a za kolik. Místo druhého vyhledávání a druhého feedu jsme do katalogu napojili stejné API, které pohání našeptávač v e-shopu. Od zadání po nasazení to trvalo jeden den.
- 1 083 rozkresů v katalogu
- 21 000+ katalogových čísel dílů, 3 značky
- ≈ 0,2 s odezva API na dotaz podle kódu
- 1 zdroj pravdy o skladu a cenách
Výchozí stav
Katalog rozkresů je samostatný web mimo Shoptet. Každý rozkres má tabulku dílů s katalogovým číslem výrobce a odkazem do e-shopu. Odkaz vedl do vyhledávání e-shopu, jenže to tato čísla nenacházelo, takže zákazník skončil na prázdné výsledkové stránce a katalog o tom nevěděl. Obchod tak přicházel jak o objednávky, tak o informaci, které díly lidé vlastně chtějí.
Co zákazník vidí teď
- Najde díl ve výkresu. Otevře PDF rozkresu, v tabulce pod ním díl vyhledá podle názvu nebo čísla.
- Klikne na Ověřit dostupnost. U každého dílu je jedno tlačítko. Žádný odchod z katalogu, žádné přepisování kódu.
- Dostane kartu produktu. Obrázek, kód, název, dostupnost, cena s DPH i bez, tlačítko Koupit vedoucí přímo na produkt v e-shopu.
- …nebo poptávku. Když díl v e-shopu není, otevře se formulář s předvyplněným dílem, kódem, názvem rozkresu a odkazem. Zbývá jméno a e-mail.
Když díl v e-shopu je:
- až 3 odpovídající produkty, včetně neoriginálních náhrad
- stav skladu a cena přesně jako v e-shopu, bez zpoždění feedu
- kliknutí na Koupit se loguje jako proklik
Když díl v e-shopu není:
- žádný „podobný" produkt, jen jasná odpověď
- poptávkový formulář rovnou v řádku dílu
- záznam do přehledu chybějících dílů pro nákup
Jak je to napojené
Revelor má veřejné rozhraní, které používá i našeptávač v e-shopu. Dotaz je jedno volání s identifikátorem projektu a limity pro jednotlivé sekce. Katalog potřebuje jen produkty:
GET https://<projekt>.revelor.cz/api/public/suggestions
?q=4174278R
&projectId=<id>
&products_limit=12
&categories_limit=0&articles_limit=0&brands_limit=0
Odpověď nese všechno, co karta produktu potřebuje. Z položky produktu katalog čte:
| Pole | Co se z něj čte |
|---|---|
code_match.exact | zda dotaz přesně sedí na kód produktu; jen tehdy se díl označí jako dostupný |
title, code, ean | název a identifikace produktu |
url | kanonická adresa produktu v e-shopu, z ní vede tlačítko Koupit |
img | obrázek z CDN e-shopu |
prices.CZK.formatted, formatted_excl_vat | cena s DPH a bez DPH, už naformátovaná v měně obchodu |
availability_text, availability_analytics, availability_quantity | text dostupnosti pro zákazníka, strojový stav (in_stock) a počet kusů |
variants_with_availability | varianty s vlastními kódy a dostupností |
Proč volá API server katalogu, a ne prohlížeč
Rozhraní by šlo volat i přímo ze stránky, přístup je povolený podle domény. Katalog má ale mezi zákazníkem a Revelorem vlastní malý endpoint, protože tím získá tři věci najednou:
- Cache. Výsledek pro jeden kód se drží 30 minut, takže stovky lidí na stejném rozkresu znamenají jedno volání.
- Pojistku proti zneužití. 120 ověření za 10 minut na návštěvníka, bez uložení IP adresy.
- Log. Každé ověření se zapíše: díl, rozkres, značka, nalezeno / nenalezeno, který produkt. Z toho je přehled v administraci a CSV pro nákup.
Co jsme k napojení potřebovali: identifikátor projektu, tři parametry v URL a jeden soubor na straně katalogu. Žádný druhý produktový feed, žádná synchronizace skladu, žádný import cen. Když se v e-shopu změní cena nebo dostupnost, katalog to ukáže při dalším ověření.
Na čem záleželo
Katalogová čísla nejsou slova. Fuzzy hledání, které skvěle zvládá překlepy v „křovinořez", na dotaz 503 28 32-08 vracelo tisíc podobných produktů. Pro zákazníka hledajícího konkrétní díl je „podobný" díl špatný díl. Proto API dostalo pole code_match: když dotaz vypadá jako kód, výsledky se ořežou na produkty, které to číslo skutečně nesou, a příznak exact říká, jestli vůbec nějaký je. Katalog díl označí jako dostupný jen při exact: true. Jak jsme to měřili a ladili, popisuje samostatný článek o hledání podle kódů.
Co z toho má obchod
| Před | Po |
|---|---|
| Odkaz do vyhledávání e-shopu, prázdná výsledková stránka | Karta produktu s cenou a tlačítkem Koupit přímo v katalogu |
| Zákazník s chybějícím dílem odchází beze stopy | Předvyplněná poptávka a záznam, který díl chyběl |
| Dva weby, dvě představy o skladu | Jeden index, jedna pravda o dostupnosti a ceně |
| Žádná data o poptávce z katalogu | Přehled ověření: nejčastěji hledané díly, které e-shop nemá |
Kam to jde dál
Stejný postup funguje všude, kde zákazník nebo obchodník potřebuje odpověď z e-shopu, ale nestojí zrovna v něm: v katalogu, v B2B portálu, v mobilní aplikaci, v interním nástroji nákupu, v chatu. Jedno volání, stejná data jako v našeptávači, a vlastní vrstva pro cache a logování podle toho, co dává smysl.
- Napojte se na index, ne na feed. Feed stárne od chvíle, kdy ho vygenerujete. Index odpovídá tím, co e-shop ukazuje právě teď.
- Dejte si mezi sebe a API vlastní endpoint. Cache, limit a log jsou tři řádky navíc a vrátí se hned první den.
- Nenalezeno je taky data. Seznam dílů, které lidé chtěli a e-shop je nemá, je nejlevnější průzkum sortimentu, jaký seženete.
Nasazeno v září 2026 pro prodejce náhradních dílů na zahradní techniku (e-shop na Shoptet Premium, katalog na WordPressu). Odezva API měřena jako medián 8 dotazů podle kódu z běžného připojení. Napojení jsme postavili my ve Webotvůrcích, tvůrci Reveloru.
Máte vedle e-shopu na Shoptet Premium ještě katalog, B2B portál nebo interní nástroj, který by měl odpovídat stejnými daty? Ozvěte se nám — nad vaším sortimentem vám ukážeme, co API vrací, ještě než se do napojení pustíte.