Většina firem dnes nepoužívá jeden systém, ale celou sbírku. CRM, ve kterém obchodníci řeší poptávky a schůzky. Účetní nebo ERP systém, kde žijí faktury, sklad a objednávky. E-shop, který generuje objednávky a platby. K tomu e-mailing, helpdesk, tabulky a pár dalších nástrojů. Každý z nich funguje sám o sobě dobře — problém vzniká mezi nimi. Data se přepisují ručně, nová objednávka z e-shopu se znovu zadává do účetnictví, kontakt z webu putuje do CRM přes kopírování a vkládání. To stojí čas, plodí chyby a nikdo nemá jistotu, kde jsou data aktuální.
API integrace systémů řeší přesně tohle. Cílem je propojit jednotlivé aplikace tak, aby si data předávaly samy — bez ručního přepisování, ideálně v reálném čase. V tomto článku si prakticky vysvětlíme, co API a webhook vlastně jsou, čím se liší REST od GraphQL, jak vypadají typické integrace mezi CRM, ERP a e-shopem, jak se hlídá bezpečnost a co dělat ve chvíli, kdy některý systém žádné API nemá.
Co je API a webhook (bez zbytečné teorie)
API (application programming interface) je dohodnuté rozhraní, přes které spolu programy komunikují. Můžete si ho představit jako přepážku: pošlete dotaz v domluveném formátu („dej mi všechny objednávky od pondělí“) a systém vám vrátí odpověď ve struktuře, které rozumí druhá aplikace. Díky tomu spolu mohou komunikovat dva nástroje, které o sobě původně nic nevěděly — třeba e-shop a účetní systém.
Klasické API funguje tak, že se jeden systém ptá druhého: aplikace A se pravidelně dotazuje, jestli nejsou nová data. Webhook obrací směr. Místo abyste se neustále ptali „už je to?“, systém vám sám zavolá ve chvíli, kdy se něco stane. Vznikne nová objednávka — e-shop okamžitě pošle zprávu do navazujícího systému. Webhooky jsou proto základem integrací, které mají běžet v reálném čase a šetřit zbytečné dotazy.
Jednoduché pravidlo: API se ptá, webhook oznamuje. Pro většinu firemních integrací dává smysl kombinace obojího — webhook spustí akci hned, API pravidelně dorovná to, co by se mohlo ztratit.
REST vs. GraphQL: stručně a prakticky
Když narazíte na pojmy REST a GraphQL, jde o dva přístupy, jak API postavit. Nepotřebujete je znát do detailu, ale je užitečné rozumět rozdílu, protože ovlivňuje, jak rychle a efektivně data tečou.
REST
REST je dnes nejrozšířenější standard. Funguje nad běžným protokolem HTTP a pracuje s jasně danými adresami (endpointy) — jedna pro objednávky, jiná pro zákazníky, další pro produkty. Je jednoduchý, dobře zdokumentovaný a podporuje ho prakticky každý moderní systém. Pro většinu integrací mezi CRM, ERP a e-shopem je REST naprosto dostačující a bývá první volbou.
GraphQL
GraphQL umožňuje vyžádat si přesně ta data, která potřebujete, jedním dotazem — ani víc, ani míň. To se hodí tam, kde by se přes REST muselo volat několik endpointů za sebou nebo kde se přenášejí velké objemy dat a záleží na efektivitě. GraphQL je mocný nástroj, ale ne každý systém ho nabízí. V praxi proto často vidíme kombinaci: tam, kde to dává smysl, GraphQL, jinde osvědčený REST.
Typické integrace, které firmy nejčastěji řeší
Teorie stranou — podívejme se, jak propojení systémů vypadá v běžné firemní praxi. Tohle jsou scénáře, se kterými se setkáváme nejčastěji.
- CRM ↔ účetnictví / ERP: Když obchodník v CRM (například Raynet) uzavře obchod, vznikne v účetním systému zálohová faktura nebo objednávka — bez ručního přepisování. Naopak stav úhrady z účetnictví se promítne zpět do CRM, takže obchodník vidí, jestli klient zaplatil.
- E-shop ↔ ERP / sklad: Nová objednávka z e-shopu okamžitě zakládá doklad a odepisuje zboží ze skladu. Změna ceny nebo skladové dostupnosti v ERP se naopak propíše na web, takže zákazník nikdy nevidí neaktuální údaj.
- Web / poptávkový formulář ↔ CRM: Kontakt z formuláře na webu se sám založí jako nová poptávka v CRM, přiřadí se obchodníkovi a spustí navazující krok. Žádné lístečky a žádné zapomenuté leady.
- E-shop ↔ platební brána: Platba přes bránu (Comgate, GoPay, Stripe a další) automaticky mění stav objednávky a může spustit expedici. Informace o úhradě tečou dál do účetnictví.
- Více systémů ↔ jeden přehled: Data z několika nástrojů se sbíhají do jednoho reportu nebo dashboardu, takže vedení vidí čísla z prodeje, skladu i účetnictví na jednom místě a v reálném čase.
Společný jmenovatel všech těchto scénářů je stejný: data, která dnes někdo přepisuje ručně, putují automaticky. Pokud chcete jít o krok dál a propojit nejen data, ale i celé pracovní postupy, navazuje na integrace automatizace procesů — například automatické schvalování, notifikace nebo generování dokumentů.
Bezpečnost: jak zařídit, aby data tekla bezpečně
Jakmile spolu systémy začnou sdílet data automaticky, je bezpečnost zásadní téma. Integrace totiž pracuje s citlivými informacemi — objednávkami, kontakty, fakturami. Dobrá zpráva je, že moderní standardy tohle řeší spolehlivě.
Klíčovým prvkem je autentizace — ověření, že se k API hlásí opravdu oprávněná aplikace. Dnešním standardem je OAuth 2.0, který umožňuje propojit systémy bez sdílení hesel: každá integrace dostane vlastní token s přesně vymezenými oprávněními, který lze kdykoli zneplatnit. K tomu patří šifrovaný přenos (HTTPS), princip nejmenších nutných oprávnění a u webhooků ověřování podpisu, aby nešlo podstrčit falešnou zprávu.
Bezpečnost není jednorázové nastavení. Patří k ní i logování, monitoring a testování — aby bylo vidět, že data tečou správně, a aby se případný problém odhalil dřív, než napáchá škodu.
Co když systém žádné API nemá?
Ne každá aplikace nabízí pěkné moderní API — zvlášť starší firemní software nebo specializované oborové nástroje. To ale neznamená konec. V praxi se dá řešení skoro vždy najít, jen vede jinou cestou.
- Import a export souborů: Pokud systém umí exportovat data (CSV, XML, Excel) nebo je naopak importovat, dá se přenos zautomatizovat nad těmito soubory — pravidelně, bez ručního klikání.
- Přímý přístup do databáze: Tam, kde to dává smysl a je to bezpečné, lze data číst nebo zapisovat přímo do databáze systému (SQL Server, PostgreSQL).
- Mezivrstva a automatizační nástroje: Platformy jako Make, n8n nebo Power Automate dokážou propojit i nástroje, které spolu jinak nekomunikují, a poskládat z dílčích kroků funkční tok.
- OCR a zpracování dokumentů: Pokud data přicházejí jen jako PDF nebo naskenovaný doklad, dají se přečíst pomocí OCR a poslat dál do systému.
Jinými slovy: absence API není automaticky překážka, jen otázka zvolené metody. Dílčí ruční krok se často dá nahradit poloautomatickým řešením, které ušetří většinu práce. Návrh takových obchvatů a stavbu API na míru řešíme v rámci API řešení a integrací.
Jak k integraci přistoupit
Úspěšná integrace nezačíná u kódu, ale u pochopení procesu. Než cokoli propojíme, je potřeba vědět, jaká data kam mají téct, jak často a co se má stát, když něco selže. Osvědčený postup vypadá zhruba takto:
- Zmapování: Které systémy, jaká data a které kroky se dnes dělají ručně.
- Návrh toků: Co se má dít automaticky, jakým směrem a jak se ošetří výjimky a chyby.
- Vývoj a mapování dat: Napojení přes API nebo webhooky a sladění toho, aby pole z jednoho systému odpovídala polím v druhém.
- Testování: Ověření funkčnosti, bezpečnosti i chování v hraničních situacích.
- Nasazení a monitoring: Spuštění naostro a hlídání, že data tečou tak, jak mají.
Tahle disciplína se vyplatí. Dobře navržená integrace tiše běží na pozadí a firma si jí po čase skoro nevšimne — což je přesně cíl. Špatně navržená naopak chrlí chyby a člověk u ní stráví víc času než u původního ručního přepisování.
Pokud ve vaší firmě data putují mezi CRM, ERP a e-shopem přes ruční přepisování, kopírování a exporty do tabulek, většinu té práce za vás může převzít dobře navržená integrace. Rádi se podíváme na vaše konkrétní systémy, navrhneme, co a jak propojit, a poradíme i tam, kde nějaký nástroj nemá API. Ozvěte se nám přes nezávaznou konzultaci a probereme, jak rozhýbat vaše data, aby tekla sama.
