Pavel Szabo — 17. 9. 2026 · aktualizováno 22. 9. 2026

API integrace mezi firemními systémy: kdy stačí konektor a kdy potřebujete vlastní vrstvu

Objednávka, sklad, faktura a platba už běží v různých systémech. Jak poznat, kdy stačí hotový konektor, kdy vlastní napojení a kdy potřebujete vrstvu, která uhlídá celý proces včetně chyb?
API integrace mezi firemními systémy: kdy stačí konektor a kdy potřebujete vlastní vrstvu

Objednávka přijde do e-shopu, zaměstnanec ji přepíše do skladu, vystaví fakturu a po platbě znovu upraví stav objednávky. Každý krok už přitom probíhá v nějakém systému, jen si mezi sebou nepředávají data sama. Výsledkem je ruční přepisování, občasná chyba v čísle nebo ceně, zpožděné vyřízení objednávky a firma, která je při každém kroku závislá na tom, že si to zaměstnanec pohlídá a nic nezapomene.

Řešením je propojení systémů. Nejjednodušší varianta je konektor: hotové propojení dvou programů, které jednou nastavíte a dál se o něj nestaráte. Když má firma víc systémů a víc vlastních pravidel, hodí se integrační vrstva, tedy malá vlastní aplikace, která komunikaci mezi systémy řídí a hlídá, že všechno proběhlo správně. Mezi těmito dvěma krajnostmi stojí vlastní přímé propojení dvou konkrétních systémů. Který typ řešení firma potřebuje, nerozhoduje jen počet aplikací, ale hlavně data, výjimky a následky případné chyby.

Jedna objednávka, čtyři systémy

Problém většinou není v tom, že firmě chybí software. Nástrojů má dost. Objednávky eviduje e-shop, zásoby skladový systém, faktury účetní program a platby banka nebo platební brána. Problém vzniká mezi nimi.

Typická objednávka může projít touto cestou:

  1. Zákazník odešle objednávku v e-shopu.
  2. Sklad rezervuje nebo odepíše dostupné zboží.
  3. Fakturační systém vystaví doklad.
  4. Platební brána nebo banka potvrdí úhradu.
  5. Stav platby a expedice se vrátí do e-shopu.

Pokud každý krok vyžaduje zásah zaměstnance, lidé kopírují čísla objednávek, jména, adresy, ceny a variabilní symboly. Kromě času vzniká druhý problém: nikdo si nemůže být jistý, zda se všechny čtyři systémy shodují.

Kontrola obchodních dat v počítači při propojení firemních systémů

U každého údaje proto musí být jasné, kde vzniká a který systém za něj odpovídá. Objednávku může řídit e-shop, skutečný stav zásob sklad, daňový doklad fakturační systém a stav úhrady platební služba. Jde o modelový příklad, ne univerzální pravidlo. V některých firmách ceny určuje účetní nebo ERP systém a e-shop je pouze zobrazuje.

Stejně důležité je vědět, kterým směrem data putují, tedy kdo je komu posílá jako první. Nestačí říct, že se propojí sklad s e-shopem. Potřebuji vědět, zda e-shop posílá objednávky do skladu, sklad posílá dostupnost zboží do e-shopu, nebo si oba systémy mění stejný údaj nezávisle na sobě. Ve třetím případě se dřív nebo později rozejdou.

Propojení systémů technicky nejčastěji stojí na API, tedy rozhraní pro komunikaci mezi aplikacemi. Jak API obecně funguje, píšu samostatně v článku Co je API a jak vám zjednoduší procesy. Tady je podstatné něco jiného: kdo řídí celý obchodní případ od objednávky po zaplacení.

Počet propojených systémů sám o sobě nerozhoduje. Rozsah integrace určují hlavně pravidla, výjimky a následky chyby.

Kdy stačí konektor a kdy vlastní řešení

Nejlevnější rozumná varianta bývá hotové propojení. Pokud podporuje vaše data, správný směr přenosu a běžné výjimky, nemá smysl programovat totéž znovu. Vlastní řešení přichází na řadu až ve chvíli, kdy standardní konektor nestačí provozu firmy.

Hotový konektor

Co to je: hotové propojení dvou programů, které si firma nastaví a dál ho jen používá, bez vlastního vývoje.

Jak to funguje v praxi: konektor přenáší předem daná pole (objednávku, produkty, adresy) mezi dvěma systémy podle pravidel, která už má nastavená výrobce.

Kdy to firma potřebuje: proces je standardní. Objednávka má běžná pole, produkty mají shodné kódy, faktura vzniká vždy ve stejném okamžiku a případná chyba neohrozí navazující provoz.

Co tím firma získá: nejrychlejší a nejlevnější rozumnou variantu. Před nasazením je potřeba ověřit:

  • která pole konektor přenáší,
  • jak často se data mezi systémy aktualizují,
  • co udělá při chybě,
  • zda podporuje storna, dobropisy a částečné platby,
  • kdo propojení aktualizuje po změně API.

U e-shopů často propojuji hotové fakturační nebo účetní služby, například Fakturoid či Pohodu. Firma získá prověřený systém pro fakturaci a vlastní vývoj řeší jen to, co je specifické pro její objednávky. Podobný princip popisuji v článku Fakturoid API: jak automatizovat fakturaci.

Používáte více systémů, mezi kterými stále ručně přepisujete data? Propojím vaše stávající nástroje tak, aby si potřebné informace předávaly automaticky. Společně ověříme, zda stačí hotové řešení, nebo se vyplatí vlastní napojení. Probrat možnosti propojení

Vlastní přímé propojení

Co to je: napojení dvou konkrétních systémů na míru, postavené přesně na pravidlech dané firmy.

Jak to funguje v praxi: vlastní kód řeší to, co hotový konektor neumí, například vlastní identifikaci zákazníků, převod číselníků (sladění vlastních kódů produktů, poboček nebo slevových skupin mezi systémy), odlišné okamžiky fakturace nebo pravidla pro konkrétní skupiny odběratelů.

Kdy to firma potřebuje: když se dva konkrétní systémy musí domluvit podle pravidel, která hotový konektor neumí. I propojení dvou aplikací může být náročné, pokud zpracovává velký objem dat, musí reagovat okamžitě nebo chyba zastaví expedici.

Co tím firma získá: řešení šité na míru dvěma systémům bez zbytečné centrální aplikace navíc. Naopak několik jednoduchých nástrojů může fungovat přes hotové konektory bez vlastní centrální aplikace.

Vlastní integrační vrstva

Co to je: malá vlastní aplikace mezi ostatními systémy. Nepřebírá jejich práci, jen hlídá, v jakém stavu je celý proces, co už proběhlo, co selhalo a co potřebuje zásah člověka.

Jak to funguje v praxi: vrstva sleduje jednu objednávku napříč všemi systémy a v případě problému ji nenechá zmizet. Když například dočasně nefunguje účetní systém, objednávka se neztratí. Vrstva ji podrží a po obnovení spojení bezpečně pokračuje tam, kde se přenos zastavil.

Kdy to firma potřebuje:

  • na jednu objednávku navazuje více systémů,
  • data se musí převádět podle vlastních pravidel,
  • výpadek jednoho systému nesmí ztratit objednávku,
  • potřebujete dohledat historii každého kroku,
  • zaměstnanci potřebují přehled nevyřízených výjimek,
  • přibývají další napojení a přímé vazby začínají být nepřehledné.

Co tím firma získá: jistotu, že žádná objednávka nezůstane viset kvůli výpadku jednoho systému, a přehled o tom, co se ve firmě právě děje napříč nástroji. Vrstva se ale nevyplatí jen proto, že zní robustněji. Pokud pouze přeposílá stejná data z bodu A do bodu B, přidává další místo k provozu a údržbě bez skutečné hodnoty.

Širší firemní systém

Někdy firma nepotřebuje jen přesouvat data. Potřebuje také řídit schvalování, práci zaměstnanců, reklamace, ruční opravy nebo vlastní agendu, kterou žádný ze stávajících nástrojů nepokrývá. Pak může dávat smysl informační systém na míru.

Ani tady není vlastní systém automatická odpověď. Schvalování nebo chybovou frontu může někdy převzít stávající firemní nástroj. Rozhoduje konkrétní proces a celkové náklady na provoz, ne název technologie.

Nejdřív hledám nejmenší řešení, které zvládne skutečný provoz, ne to nejdražší nebo technicky nejzajímavější. Nechodím po firmách s hotovou odpovědí „potřebujete integrační vrstvu“. Někdy stačí konektor, jindy jedno vlastní napojení. Vlastní integrační vrstvu navrhuji jen tam, kde musí opravdu někdo spolehlivě hlídat celý obchodní případ a jeho výjimky, ne proto, že zní jako pokročilejší řešení.

Pokud nevíte, do které varianty vaše situace patří, můžeme během úvodní konzultace projít jeden skutečný proces a oddělit nutné propojení od zbytečného vývoje. Domluvte si konzultaci.

Dobrá integrace se pozná podle výjimek

Běžný průchod objednávky bývá jednoduchý. Skutečný rozsah projektu ukážou až situace, kdy se něco změní nebo pokazí.

Co se stane, když:

  • zákazník po objednání změní počet kusů,
  • část zboží není skladem,
  • objednávka se odešle na dvakrát,
  • faktura už vznikla, ale objednávka se stornuje,
  • zákazník zaplatí jen část částky,
  • platba přijde bez správného identifikátoru,
  • stejná informace dorazí do systému dvakrát,
  • účetní program nebo skladové API několik hodin nefunguje,
  • zaměstnanec opraví údaj přímo v jednom systému?

Spolehlivé propojení nesmí takový případ schovat. Musí ho buď bezpečně vyřešit, nebo zastavit na místě, kde ho převezme konkrétní člověk.

Kontrola chybové fronty při propojení objednávek, skladu a fakturace

Zkušenost z přípravy propojení Septimu a Money S3

U jednoho klienta jsme řešili automatizaci fakturace mezi systémy Septim a Money S3, aby se faktury nemusely mezi nimi přepisovat ručně. Prvním krokem bylo ověřit přístup do API obou systémů, ten fungoval bez problémů. To ale ještě neznamenalo, že bylo možné rovnou začít přenášet faktury.

Ukázalo se, že dostupná data neobsahovala všechny údaje potřebné pro jednoznačné spárování odběratele a objednávky. Testovací prostředí navíc obsahovalo obecná ukázková data, ne skutečné varianty z provozu klienta. Před vývojem proto bylo nutné vyjasnit číselníky (tedy sladit vlastní kódy produktů a skupin odběratelů mezi oběma systémy), pravidla pro různé skupiny odběratelů, povinné číslo objednávky a okamžik, kdy má faktura vzniknout.

Projekt zde uvádím jako zkušenost z návrhu a ověřování integrace, ne jako tvrzení o dokončeném výsledku nebo dosažené úspoře. Dobře ale ukazuje, proč nelze propojení poctivě nacenit jen podle názvů dvou systémů.

Co se stane, když přenos dat selže?

Dobrý systém uživatele na problém upozorní, ukáže mu konkrétní objednávku, které se to týká, a umožní chybu vyřešit, aniž by se cokoliv ztratilo. Žádné tiché selhání, po kterém si o pár dní později někdo všimne, že objednávka nikde neexistuje.

Pokud cílový systém krátce neodpovídá, může se přenos později bezpečně zopakovat. Pokud ale objednávce chybí zákazník, produkt nemá odpovídající skladovou kartu nebo stav nedává smysl, další pokusy nic neopraví.

Takový případ má skončit v přehledu pro ruční kontrolu. Uživatel musí vidět:

  • které objednávky se problém týká,
  • ve kterém kroku se zastavila,
  • proč ji systém odmítl,
  • jaká data přišla ze zdroje,
  • co je potřeba opravit,
  • zda lze proces po opravě znovu spustit.

Obnova po výpadku závisí na možnostech konkrétního API. Někde lze bezpečně zopakovat původní událost. Jinde je správnější načíst aktuální stav objednávky a porovnat ho s ostatními systémy. Důležité je, aby opakování nevytvořilo druhou fakturu nebo znovu neodepsalo sklad.

Při popisu integrace nezačínejte seznamem funkcí. Vezměte jednu skutečnou objednávku, projděte její cestu firmou a přidejte dvě nebo tři výjimky, které zaměstnanci řeší jinak než obvykle.

Kde může pomoct AI

Pro běžný přenos objednávek mezi systémy není AI potřeba. Jde o běžné API, kontrolu dat a jasná pravidla.

AI může pomoct ve chvíli, kdy objednávka přijde volným e-mailem, jako PDF nebo v pokaždé trochu jiném dokumentu. Dokáže navrhnout, kdo objednává, jaké položky chce a kam je dodat. Než však vznikne skladový nebo finanční zápis, pevná pravidla ověří povinná pole, zákazníka, položky, jednotky a duplicity. Nejasný případ dostane člověk ke kontrole.

Takové rozdělení používám i u širší automatizace firemních procesů: běžný přenos dat drží předvídatelný kód, AI pomáhá tam, kde je vstup nejasný nebo nestrukturovaný.

Co potřebuji vědět, abych mohl propojení nacenit

Poptávka „propojte nám e-shop se skladem a účetnictvím“ nestačí pro pevný odhad. Nejdřív potřebuji vědět, co přesně se má stát s jednou běžnou objednávkou a s každou důležitou výjimkou.

Připravte si tyto podklady:

  1. Seznam systémů a jejich role. Kde vzniká objednávka, sklad, faktura a informace o platbě?
  2. API dokumentaci a přístupy. Existuje veřejné API, testovací účet a prostředí podobné skutečnému provozu?
  3. Seznam přenášených údajů. Nestačí objednávka. Potřebuji znát zákazníka, adresy, položky, ceny, měny, daně, slevy, dopravu, identifikátory a stavy.
  4. Směr a okamžik přenosu. Co se posílá kam a kdy má další krok začít?
  5. Objem a špičky. Kolik záznamů běžně vzniká a jak vypadá nejsilnější období?
  6. Shodné identifikátory a číselníky. Jak se pozná stejný zákazník, produkt, pobočka nebo objednávka v různých systémech, když každý z nich může mít vlastní kódy a čísla?
  7. Běžné výjimky. Storna, změny, částečné dodání, dobropisy, chybějící zboží nebo opožděné platby.
  8. Pravidla ruční kontroly. Co se smí opravit automaticky a co musí schválit člověk?
  9. Historická data. Má se propojit jen nový provoz, nebo také převést staré objednávky, faktury a skladové pohyby?
  10. Požadavky na dohled a podporu. Kdo dostane upozornění, jak rychle se musí chyba řešit a kdo odpovídá za změny cizího API?

Ne všechny podklady musí být hotové před prvním hovorem. Bez nich ale lze dát jen orientační rozsah. Přesnější nabídka vznikne až po kontrole dokumentace, vzorků dat a výjimek.

Co si z článku odnést?

  • Hotový konektor stačí, pokud podporuje potřebná data, směr přenosu i běžné výjimky.
  • Vlastní napojení řeší konkrétní pravidla, která standardní konektor neumí.
  • Integrační vrstva má smysl, když musí hlídat stav celého procesu, historii a chyby napříč více systémy.
  • AI patří ke čtení nejasných e-mailů a dokumentů. Běžný přenos dat má zůstat předvídatelný.
  • Pro nacenění jsou důležitější reálná data a výjimky než pouhý seznam aplikací.

Časté otázky

Kolik stojí API integrace mezi firemními systémy?

Bez kontroly procesu, dokumentace a vzorků dat lze dát jen orientační rozsah. Cenu ovlivňuje počet směrů přenosu, převod číselníků, výjimky, požadovaná rychlost, chybová fronta, historie a následná podpora. Dva stejné názvy systémů proto neznamenají stejnou cenu projektu.

Jak dlouho propojení systémů trvá?

Záleží na připravenosti API, kvalitě testovacích dat a počtu výjimek. Jednoduché napojení dvou standardních služeb má jiný rozsah než proces objednávka, sklad, faktura a platba s několika větvemi. Reálný harmonogram lze určit až po technickém ověření.

Co se stane, když API jednoho systému vypadne?

Dobré propojení požadavek nezahodí. Podle situace přenos bezpečně zopakuje, načte aktuální stav nebo případ přesune do přehledu pro ruční kontrolu. Součástí návrhu musí být ochrana před duplicitní fakturou, opakovaným odpisem skladu a dalšími následky opakování.

Lze firemní systémy propojit bez AI?

Ano. Data v pevném formátu, jako jsou objednávky, faktury nebo skladové pohyby, se mezi e-shopem, skladem, účetnictvím a platební službou běžně přenášejí přes API a pevná pravidla. AI má přínos hlavně u e-mailů, PDF a dalších vstupů, které nemají stálou podobu.

Co když jeden ze systémů nemá API?

Nejdřív je potřeba ověřit jiné bezpečné možnosti, například pravidelný import a export nebo podporované datové rozhraní. Pokud systém neumí spolehlivě data přijímat ani vydávat, může být rozumnější změnit danou část procesu než stavět křehké obcházení.

Trápí vás ruční přepisování dat mezi systémy, které ve firmě už používáte, a nevíte, jestli stačí hotový konektor, nebo je potřeba vlastní řešení? Napište mi. Projdeme konkrétní proces a místa, kde dnes vzniká ruční práce. Pak navrhnu nejmenší řešení, které zvládne i reálné výjimky.

AI řešení pro firmy

Stavím firmám AI agenty a automatizace na míru

AI pomocník napojený na vaše data a systémy
Automatizace rutiny: odpovědi zákazníkům, zpracování poptávek, třídění dokumentů
Na míru vašim procesům, postavené na Claude
Od návrhu přes nasazení po údržbu

Pavel Szabo

Programátor webů, eshopů a informačních systémů s více než 23 lety praxe. Pomáhám firmám i jednotlivcům s online podnikáním, automatizacemi a využitím AI v praxi.

Znáte někoho komu by článek mohl pomoct? Budu rád za sdílení!

Nabídka služeb

Vyberte si z nabídky níže, co zrovna potřebujete nebo mi rovnou zavolejte a probereme Vaše potřeby.

Weby a portály

Kódování a programování

Marketing a obsah

AI školení a konzultace

Praha, Brno, Ostrava či zahraničí? Na tom nezáleží

Osobní schůzky jsou možné, ale většinu záležitostí — od tvorby webů po AI automatizace — lze vyřešit pohodlně přes videohovor. Působím po celé ČR, s klienty z mnoha měst: Praha, Brno, Ostrava, Jičín, Liberec, Olomouc, Hradec Králové, České Budějovice, Karviná, Frýdek-Místek, Opava, Třinec, Orlová, Český Těšín, Nový Jičín, Krnov, Bohumín, Kopřivnice, Bruntál...
Pro lepší porozumění vašim potřebám je ideální online hovor. Rezervujte si schůzku přes můj formulář nebo mě kontaktujte telefonicky. Můžeme se taky domluvit na výjezdu a osobní schůzce.
Praha, Brno, Ostrava či zahraničí? Na tom nezáleží