Dobrá API integrace musí zvládnout i výpadek, opakovanou objednávku a neúplná data. Při správě e-shopu proto sledujte výsledky přenosů a způsob obnovy, nejen to, zda rozhraní odpovídá. Níže je kontrolní postup pro majitele e-shopu a jeho technického správce, s konkrétními odkazy pro Shoptet.
Pokud teprve vybíráte způsob propojení, začněte článkem Shoptet API a napojení na ERP. Tento text řeší provoz už navržené integrace. Dokumentaci Shoptetu jsme ověřili k 5. listopadu 2026.
Jak poznat, že se přenášejí správná data?
Porovnejte konkrétní záznam na obou stranách a sledujte jeho průchod. Úspěšné přijetí požadavku ještě nemusí znamenat dokončení následné úlohy. Objednávka také může existovat, ale mít nesprávnou měnu, variantu nebo stav platby.
Pro kontrolu vyberte běžnou objednávku, objednávku se slevou, storno a produkt s variantami. U každého záznamu porovnejte identifikátor, relevantní částky a stav. U skladu rozlišujte fyzický stav a množství dostupné po rezervacích. Čas posledního přenosu vztáhněte ke konkrétnímu datovému toku: synchronizace cen může fungovat, zatímco přenos objednávek stojí.
Tento přehled je návrh provozních kontrol, nikoli naměřený výsledek klienta:
| Signál | Co může znamenat | Co ověřit |
|---|---|---|
| Stará poslední úspěšná objednávka | Přenos stojí, nebo nepřicházejí objednávky | Skutečné nové objednávky a čekající úlohy |
| Rostoucí fronta přenosů | Pomalé zpracování nebo nedostupný příjemce | Nejstarší úlohu, chyby a kapacitu příjemce |
| Rozdílný sklad | Chybné párování nebo pravidla rezervace | Stejnou variantu a stejný význam množství |
| Opakovaná objednávka | Opakované zpracování téže operace | Identifikátor, historii pokusů a cílový doklad |
| Mnoho chyb oprávnění | Neplatný přístup nebo chybějící právo | Konkrétní token a povolenou operaci |
Prahy upozornění nastavte podle provozu. Bez znalosti objemu objednávek a dohodnuté aktuálnosti nelze stanovit jednu správnou hodnotu pro všechny e-shopy.
Jak zabránit duplicitám při opakování přenosu?
Každá obchodní operace musí mít rozpoznatelnou identitu a uložený výsledek zpracování. Opakované doručení stejné události pak nemá znovu založit objednávku, vystavit doklad nebo poslat potvrzení.
Příklad je modelový: ERP objednávku uloží, ale spojení se přeruší před doručením odpovědi. E-shop neví, zda zápis proběhl. Slepé opakování vytvoření může založit druhou objednávku. Integrace proto potřebuje bezpečně zjistit, zda odpovídající záznam už existuje, a navázat na něj. Konkrétní způsob závisí na funkcích cílového systému; nelze předpokládat, že každé API nabízí stejnou ochranu proti duplicitám.
Stejný princip platí pro webhooky, tedy oznámení o změně. Shoptet může při nepotvrzeném doručení oznámení opakovat. Doporučuje oddělit rychlé přijetí od dalšího zpracování. Technický správce by měl událost bezpečně uložit, potvrdit přijetí a následnou práci zpracovat samostatně. Viz dokumentace webhooků.
Co dělat při výpadku nebo dosažení limitu API?
Rozlište dočasnou chybu od chyby dat či oprávnění a podle toho zvolte další pokus. Nedostupnost služby může umožnit pozdější opakování. Neznámý produkt nebo chybějící oprávnění obvykle vyžadují opravu příčiny.
Shoptet při překročení příslušných limitů vrací stav 429 a používá také hlavičky pro informaci o vytížení a odkladu dalšího pokusu. Integrace má respektovat aktuální pravidla, řídit souběh přenosů a nestahovat celý katalog při každé změně. Viz správné používání Shoptet API.
Pro vlastní integraci si dohodněte:
- uložení nedokončených úloh a jejich dohledatelnost;
- omezené opakování s prodlevou pro vhodné dočasné chyby;
- upozornění při dlouhém čekání nebo opakovaném selhání;
- postup pro ruční opravu a bezpečné opětovné zpracování;
- následné porovnání dat po obnovení provozu.
U zápisu s nejasným výsledkem nejdřív zjistěte stav cílového systému. Samotný timeout neříká, zda se operace provedla.
Jaká oprávnění a záznamy integrace potřebuje?
Přístup má pokrývat potřebné operace a záznamy mají umožnit dohledat chybu bez odhalení tajných údajů. API token nepatří do veřejného kódu stránky, snímku obrazovky ani běžného provozního logu. Po ukončení spolupráce odeberte nepotřebné přístupy.
Pro diagnostiku je užitečný čas, identifikátor požadavku, typ operace, stav, počet pokusů a vazba na záznam v cílovém systému. Osobní údaje omezte na nezbytný rozsah; u detailních diagnostických záznamů určete přístup a dobu uchování. U příchozích webhooků ověřujte původ a integritu podle dokumentace poskytovatele, včetně dostupného podpisu zprávy.
API ani oddělený frontend nejsou samy o sobě zárukou bezpečnosti. Bezpečnost závisí na návrhu oprávnění, validaci vstupů, aktualizacích a provozních kontrolách. Automatické sliby „bezpečnějšího e-shopu díky API“ proto nejsou dostatečným podkladem pro rozhodnutí.
Co předat správci a jak integraci dále rozvíjet?
Předejte mapu datových toků, odpovědnosti a ověřený postup obnovy. Správce má vědět, kdo rozhoduje o ceně či zásobě, kde najde chyby a jak zasáhne bez ztráty nebo zdvojení dat. Součástí předání mají být i testovací scénáře a záznam poslední ověřené verze napojení.
Při změně platformy nebo API znovu otestujte důležité operace. U Shoptetu například webhooky s plnými daty mohou změnit způsob získávání detailu. Ověřte podporované události a záložní postup, když data v oznámení chybějí.
Rozsah průběžné péče, reakční doby a rozdělení odpovědnosti je potřeba sjednat. Více uvádíme u servisu a podpory e-shopu. Technická podpora integrace se nemá zaměňovat za garanci dostupnosti celé platformy.
Časté otázky
Jak poznám, že synchronizace e-shopu funguje?
Porovnávejte konkrétní objednávky, částky a zásoby mezi systémy. Sledujte čas posledního úspěšného přenosu, čekající úlohy a chyby. Samotná odpověď HTTP 200 nepotvrzuje správnost výsledných dat.
Proč může objednávka přes API vzniknout dvakrát?
Příčinou může být opakovaná událost, opakování požadavku po výpadku nebo dvě souběžné integrace. Zpracování má rozpoznat již provedenou operaci podle stabilního identifikátoru a před dalším zápisem ověřit stav cílového systému.
Je e-shop s API automaticky bezpečnější?
Ne. Bezpečnost závisí na oprávněních, uložení přístupových údajů, ověřování příchozích událostí a údržbě integrace. Rozdělení systému na frontend a backend samo o sobě bezpečnost nezaručuje.
Potřebujete prověřit současné propojení? U napojení ERP a e-shopu popište používané systémy a konkrétní problém. Přiložte anonymizovaný příklad; přístupové klíče do poptávky neposílejte.
