Kolik stojí integrace systémů a API a co ovlivňuje odhad ceny?

Bez prověření obou stran propojení nelze poctivě určit jednu cenu integrace systémů nebo API. Náklady závisí mimo jiné na dostupné dokumentaci, směru toku dat, počtu pravidel, kvalitě identifikátorů, řešení chyb, testování a následné údržbě.

Integrace nekončí odesláním jednoho požadavku do API. Musí bezpečně reagovat také tehdy, když jsou data neúplná, stejný záznam dorazí podruhé, jeden ze systémů dočasně neodpovídá nebo poskytovatel omezuje počet požadavků.

Při porovnávání nákladů je potřeba oddělit tři oblasti:

• přípravu a realizaci, tedy poznání procesu, mapování dat, programování, testy a spuštění;
• poplatky třetích stran, pokud poskytovatel účtuje tarif, konektor, platformu nebo přístup k potřebným funkcím;
• následnou údržbu, tedy monitoring, řešení problémů a úpravy po změnách v propojených systémech.

Samotná informace „chceme propojit e-shop s ERP“ proto k odpovědnému odhadu nestačí.

Pokud je integrace součástí většího systému, širší souvislosti najdete v článku Kolik stojí webová aplikace pro firmu?.

Proč názvy dvou systémů k odhadu nestačí?

Stejné propojení může znamenat úplně jiný rozsah. Jedna firma chce pouze jednou denně předat nové objednávky. Jiná očekává okamžitou obousměrnou výměnu objednávek, skladových zásob, cen, plateb a stavů dopravy.

V prvním případě může stačit jednoduchý import. Ve druhém je nutné určit například:

• který systém uchovává správnou cenu a skladový stav;
• co se stane, když zákazník změní objednávku během synchronizace;
• jak se na obou stranách rozpozná stejný produkt nebo odběratel;
• jak zabránit dvojímu vytvoření objednávky;
• které chyby lze automaticky zopakovat a které vyžadují rozhodnutí pracovníka;
• jak ověřit, že data v obou systémech zůstávají shodná.

Odhad tedy závisí na celém toku, ne jen na počtu programů.

Čtyři způsoby propojení systémů

Ne každá integrace vyžaduje vlastní řešení vytvořené od začátku. Nejprve je vhodné ověřit, která cesta odpovídá procesu a možnostem používaných systémů.

Chybějící API automatizaci vždy nevylučuje. Někdy lze bezpečně využít soubory nebo podporované importní funkce. Je však nutné prověřit požadovanou frekvenci, úplnost a kontrolu chyb.

Z čeho se skládají náklady na realizaci integrace?

Prověření možností obou systémů

Nejprve je potřeba zjistit verze programů, dostupné moduly, dokumentaci, způsob přihlášení a možnost využít testovací prostředí. Dokumentace může popisovat mnoho funkcí, ale ne všechny musí být dostupné v tarifu klienta nebo používané verzi.

Popis procesu a směru dat

Rozsah musí určit, co výměnu spouští, která data se mají předávat, kterým směrem a jak rychle. Stejně důležité je rozhodnout, který systém představuje správný zdroj, pokud se hodnoty na obou stranách liší.

Mapování a převod dat

Název produktu, adresa, sazba daně nebo stav objednávky mohou být v každém systému zapsány jinak. Integrace musí rozdíly rozpoznat a převést data podle dohodnutých pravidel.

Přístup a bezpečnost

Propojení by mělo získat pouze oprávnění potřebná pro daný úkol. Způsob ověření, ukládání klíčů, role a možnost přístup odebrat také ovlivňují rozsah prací.

Řešení chyb a opakování

Je třeba počítat s chybějící povinnou hodnotou, výpadkem systému, překročením limitu nebo opětovným doručením stejné operace. Obecná informace „došlo k chybě“ nestačí. Musí být jasné, co neprošlo, zda lze pokus bezpečně zopakovat a kdo má reagovat.

Testy a spuštění

Netestuje se jen správný scénář. Potřebná jsou také chybná data, duplicity, částečně dokončené operace a nedostupnost jednoho systému. Rozsah testů roste, pokud integrace pracuje s objednávkami, vyúčtováním nebo daty používanými více odděleními.

Logy, upozornění a následná obsluha

Po spuštění musí být možné zjistit, co se stalo. Podle významu procesu mohou být potřeba logy, oznámení, přehled chybějících dat nebo obrazovka pro kontrolovanou ruční opravu.

Co mění odhad integrace nejvíce?

Dokumentace a testovací prostředí

Přehledná dokumentace a testovací přístup umožňují včas ověřit technické předpoklady. Chybějící dokumentace zvyšuje počet neznámých. Někdy je nutný také kontakt s poskytovatelem nebo práce na jeho straně.

Jednosměrná nebo obousměrná výměna

Předání nových objednávek z e-shopu do ERP se popisuje snáz než úplná synchronizace v obou směrech. U obousměrného toku je třeba určit pravidla konfliktů, pořadí změn a správný zdroj dat.

Množství dat a pravidel

Nerozhoduje jen počet polí. Důležité jsou i formáty, podmínky, výjimky a závislosti. Jeden stav může ve druhém systému spustit několik akcí a zdánlivě jednoduché pole může vyžadovat číselník nebo další ověření.

Kvalita identifikátorů a současných dat

Pokud má stejný produkt různé kódy, odběratelé se vyskytují vícekrát nebo chybí stálé identifikátory, je třeba dohodnout pravidla párování a kontroly. Jinak může integrace vytvářet duplicity nebo spojovat nesprávné záznamy.

Objem, frekvence a limity

Předání několika záznamů jednou denně se navrhuje jinak než časté zpracování velkého množství operací. Poskytovatel API může také omezovat počet požadavků nebo způsob načítání větších datových sad.

Historická data a jednorázová migrace

Spuštění běžné výměny automaticky nezahrnuje všechna data z minulých let. Import historie potřebuje vlastní rozsah, kontrolu kvality dat a rozhodnutí, které informace jsou ještě potřebné.

Výjimky vyžadující rozhodnutí člověka

Ne každý problém lze vyřešit automaticky. Pokud musí pracovník rozhodnout, který záznam je správný nebo jak zpracovat neobvyklou objednávku, integrace mu má poskytnout srozumitelnou informaci a bezpečnou možnost opravy.

Požadavky na bezpečnost a historii změn

Rozsah roste, pokud je nutné přesně zaznamenávat operace, oddělovat oprávnění, zvlášť chránit důležitá data nebo později vysvětlit, proč se konkrétní hodnota změnila.

Počáteční realizace není celkovou cenou integrace

Po spuštění se integrace stává součástí firemního procesu. Před výběrem nabídky je vhodné zjistit, kdo ji bude sledovat a co nastane po změně některého propojeného systému.

K následným nákladům mohou patřit:

• poplatky za tarif, konektor, platformu nebo potřebné funkce;
• server nebo jiná infrastruktura mezivrstvy;
• monitoring, uchovávání logů a upozornění;
• ruční řešení případů, které nelze rozhodnout automaticky;
• změny klíčů, oprávnění nebo způsobu přihlášení;
• přizpůsobení po změně API, datového formátu nebo procesu;
• podpora a další rozvoj.

Ne každá integrace vyžaduje předplatné ani stejnou úroveň průběžné péče. Konkrétní model je potřeba dohodnout pro daný proces a uvést v nabídce.

Širší srovnání modelů správy najdete v článku kolik stojí údržba webové aplikace.

Jak porovnat dvě nabídky integrace?

Dvě podobné částky mohou zahrnovat úplně jiný rozsah. Jedna nabídka může obsahovat testy, řešení chyb a monitoring, zatímco druhá jen základní předávání dat. Proto porovnávejte odpovědi na stejné otázky.

Pokud tyto informace nejsou zapsané, je obtížné poznat, zda nabídky skutečně popisují stejné řešení.

Kdy lze připravit odhad a kdy je potřeba analýza?

Jeden dobře popsaný tok lze odhadnout po shromáždění dostatečných informací a prověření technických možností. Potřebujeme alespoň systémy, směr dat, rozsah záznamů, frekvenci, hlavní výjimky a způsob převzetí.

Bezplatný kvalifikační rozhovor s Domin Software může trvat až 20 minut. Slouží k rozpoznání problému, cíle a materiálů potřebných pro další posouzení. Nezahrnuje bezplatnou diagnostiku systémů, návrh integrace ani zpracování zprávy.

Pokud projekt zahrnuje několik systémů, obousměrnou synchronizaci, neuspořádaná data nebo obtížně ověřitelná omezení, vhodným začátkem může být business analýza a určení první etapy. Jde o placenou a samostatně naceněnou etapu. Pokud Domin Software následně realizuje projekt vycházející z analýzy, zaplacená cena analýzy se započte do celkové ceny projektu.

Co připravit před rozhovorem o integraci?

Nemusíte sami vytvářet technickou dokumentaci. Připravte informace, které nám umožní pochopit tok a neznámé:

1. názvy a verze systémů;
2. odkazy na dokumentaci, pokud je máte;
3. informace o testovacím účtu nebo prostředí poskytovatele;
4. seznam dat, která se mají předávat v každém směru;
5. anonymizovaný příklad souboru nebo datové struktury bez údajů zákazníků, hesel a klíčů;
6. frekvenci a přibližný počet operací;
7. nejdůležitější chybové situace a výjimky;
8. způsob, kterým ověříme správnou funkci první etapy.

Začít můžete s plánovačem integrace systémů. Pomůže vytvořit pracovní mapu toku, ale nevytváří automatický odhad a nenahrazuje kontrolu dokumentace.

Pokud chcete podrobněji popsat samotný tok, přečtěte si také článek Jak naplánovat integraci dvou systémů?.

Co ukazují naše předchozí realizace?

V projektu HUB.ITM jsme zpracovávali data z různých programů a formátů a připravovali je pro import do systémů Subiekt. Takový rozsah vyžadoval přesná pravidla mapování a kontrolu správnosti dat.

HUB-2-API zahrnoval import produktů, integraci s eBay.de a API, přes které tři zákazníci z Francie kontrolovali nabídku a zadávali objednávky. Ukazuje, jak se v jednom projektu spojují různé směry dat, příjemci a procesy.

V historickém systému importu produktů jsme pro zásobování e-shopů používali CSV, XML, API a FTP. Způsob výměny se řídil možnostmi zdroje a cílového systému, ne jedním nástrojem pro každý případ.

Tyto realizace nejsou ceníkem a neurčují cenu nového projektu. Ukazují pouze, proč je před odhadem nutné poznat formáty, pravidla a způsob řešení chyb.

Časté otázky

Lze integraci odhadnout jen podle názvů systémů?

Obvykle ne. Názvy umožní zahájit prověřování, ale potřebujeme také směr výměny, rozsah dat, frekvenci, pravidla, výjimky a způsob řešení chyb.

Znamená dostupné API vždy jednoduchou a levnou integraci?

Ne. API může poskytovat jen část potřebných dat, mít limity nebo vyžadovat další tarif. Je třeba prověřit dokumentaci, testovací přístup a konkrétní operace.

Lze systémy propojit, když jeden z nich nemá API?

Někdy ano. K dispozici může být import a export souborů, podporovaný konektor nebo jiná dokumentovaná cesta. Pro konkrétní systém je třeba ověřit proveditelnost a bezpečnost.

Proč obousměrná synchronizace vyžaduje více rozhodnutí?

Je nutné určit, který systém má přednost, jak řešit konflikty a co dělat, když se stejná informace změní na obou stranách. Přibývají také další chybové a testovací scénáře.

Patří import historických dat do integrace?

Pouze tehdy, pokud je uveden v dohodnutém rozsahu. Přenos historie může vyžadovat samostatné mapování, čištění a kontrolu dat.

Vyžaduje integrace po spuštění údržbu?

Rozsah závisí na významu procesu a propojených systémech. Je vhodné dohodnout monitoring, řešení chyb, odpovědnost za změny API a způsob objednávání dalších úprav.

Lze získat odhad bez placené analýzy?

Ano, pokud je rozsah dostatečně jasný a technické možnosti lze ověřit bez samostatné etapy. Krátký kvalifikační rozhovor však nenahrazuje bezplatnou diagnostiku ani návrh řešení.

Lze integraci realizovat po etapách?

Ano. Lze začít jedním důležitým tokem, stanovit podmínky převzetí a později přidávat další data nebo systémy. Každá etapa má mít jasně popsaný rozsah.

Vyberte vhodný další krok

Pokud požadavky teprve třídíte, začněte s plánovačem integrace systémů. Připravíte pracovní popis směru dat, frekvence, výjimek a způsobu ověření výsledku.

Jestli už víte, které systémy a proces chcete propojit, podívejte se na nabídku integrací systémů a API. Pokud je rozsah větší nebo obsahuje mnoho neznámých, můžeme začít business analýzou a určením první etapy.

Zdroje

• OpenAPI Specification 3.2.1, přístup ověřen 28.10.2026.
• OAuth 2.0, RFC 6749, přístup ověřen 28.10.2026.
• OWASP API Security Top 10, přístup ověřen 28.10.2026.
• GitHub REST API - limity požadavků, přístup ověřen 28.10.2026. Dokumentace GitHubu je příkladem pravidel jednoho poskytovatele, nikoli obecným pravidlem pro každé API.