Jak napojit aplikaci na ARES a co je jinak u datových schránek?

ARES, tedy Administrativní registr ekonomických subjektů, provozuje Ministerstvo financí. Podle informací ministerstva nabízí veřejné API pro vyhledávání subjektů a jejich veřejných údajů ze zdrojových registrů. Služby může využívat kdokoli, kdo dodrží podmínky provozu.

Pro firemní aplikaci to znamená možnost dohledat subjekt podle zadaného IČO a využít vrácené údaje ve formuláři nebo v evidenci. V zadání je vhodné odlišit dohledání firmy od rozhodnutí, zda s ní chcete obchodovat. Samotný nalezený záznam by neměl být v aplikaci prezentován jako doporučení dodavatele nebo potvrzení jeho spolehlivosti.

Slovo „ověřeno“ proto potřebuje konkrétní význam. Má znamenat, že aplikace našla odpovídající subjekt, nebo že uživatel zkontroloval údaje před uložením? Pokud mají tyto situace stejný štítek, obsluha z něj nepozná, co skutečně proběhlo.

Rozumným výchozím zadáním je dohledání údajů při registraci zákazníka či dodavatele. Až podle jejich dalšího použití má smysl rozhodnout, kdy je obnovovat a kdo může uložené hodnoty změnit. Bez tohoto rozhodnutí může správně fungující napojení vytvářet nejasnosti v samotném firemním procesu.

Než přijde na technické propojení, je potřeba popsat průchod formulářem. Uživatel zadá IČO, aplikace požádá o údaje a výsledek nabídne ke kontrole. Součástí zadání má být i chování při neúspěchu, aby chybová hláška nezůstala jedinou možnou cestou dál.

Je vhodné rozlišit nenalezený subjekt, neplatný vstup a nedostupné rozhraní. Jde o odlišné situace s odlišným dalším krokem. Při nedostupnosti služby nemá aplikace tvrdit, že firma neexistuje, protože takový závěr z neúspěšného spojení neplyne.

Pro návrh formuláře pomůže ujasnit si:

• Které údaje se mají předvyplnit a které uživatel doplní sám.
• Zda může uživatel pokračovat bez dokončeného ověření.
• Kdo později vyřeší záznamy čekající na ověření.
• Co se má stát, když se nově načtené údaje liší od uložených.

Možnost ručního pokračování není vhodná pro každý proces. Pokud další krok závisí na ověřených údajích, může být správným řešením rozpracovaný záznam a srozumitelná informace o čekání. Podstatné je, aby aplikace neskrývala nejistý výsledek za zprávu o úspěchu.

Veřejná dostupnost ARES neznamená neomezený provoz. Podle podmínek provozu ARES na webu Ministerstva financí si ministerstvo vyhrazuje právo omezit nebo znepřístupnit přístup mimo jiné při více než 500 dotazech za minutu. Důvodem mohou být také opakované shodné či chybně vyplněné dotazy nebo velké množství souběžných dotazů.

Podmínky uvádějí také obcházení limitů přes více IP adres a automatické prohledávání databáze náhodnými daty. Uvedenou hranici proto nelze chápat jako doporučené provozní tempo, pod kterým je jakékoli chování přijatelné. Návrh musí zohlednit všechny podmínky, nejen počítadlo požadavků.

Cache je dočasné uložení výsledku, aby aplikace nemusela při každém otevření stejného záznamu znovu kontaktovat ARES. Vhodná doba uchování závisí na účelu údajů. Jiný požadavek může mít předvyplnění rozpracovaného formuláře a jiný opětovná kontrola před navazujícím firemním rozhodnutím.

Součástí návrhu má být také omezení souběžných požadavků a kontrola vstupu před odesláním. Při hromadném zpracování je vhodná fronta, která práci rozloží. Podle podmínek ministerstva vyžaduje obnovení omezeného přístupu dostatečné písemné záruky dohodnuté s MF; spoléhat na následné odblokování proto není provozní plán.

Výpadek je potřeba zahrnout do zadání stejně jako úspěšné načtení. Rozpracovaný formulář by měl zachovat vstup uživatele a sdělit, zda lze pokračovat, nebo bude nutné počkat. Pokud aplikace použije uložené údaje, mělo by být zřejmé, že nejde o právě dokončené ověření.

Opakování požadavku může pomoci při dočasné nedostupnosti, potřebuje ale pravidla. Neustálé okamžité opakování stejného dotazu by odporovalo smyslu řízení provozu. Návrh má určit, kdy další pokus proběhne, kdy automatické pokusy skončí a komu se nevyřešený stav zobrazí.

Ministerstvo financí zveřejňuje changelog API ARES a rozhraní se mění, včetně zpětně nekompatibilních změn. Údržba napojení proto patří do rozhodování o projektu už před jeho spuštěním. Má mít určeného vlastníka i postup ověření po změně.

V přejímce aplikace je vhodné ověřit úspěšné dohledání, nenalezený subjekt, nedostupnost služby i neočekávanou odpověď. Kontrola má sledovat také to, co uvidí uživatel a jaký záznam zůstane uložený. Samotné úspěšné připojení jako důkaz správnosti celého procesu nestačí.

Podle dokumentace aplikačního rozhraní ISDS mohou externí aplikace využívat webové služby přes HTTPS. Aplikace se může přihlašovat certifikátem. Napojení vlastní datové schránky tak do zadání přidává přístup ke schránce a práci s komunikací, která vyžaduje jiná rozhodnutí než dohledání veřejného záznamu.

U příjmu je potřeba určit, kdo zprávu převezme do firemního procesu a jak pozná, že vyžaduje jeho pozornost. U odesílání musí být jasné, kdo schvaluje obsah, adresáta a samotné odeslání. Tyto role je vhodné popsat dříve než obrazovky aplikace.

Zadání by mělo rozlišovat přípravu zprávy, pokus o odeslání a potvrzený výsledek komunikace. Pokud výsledek požadavku není jasný, automatické opakování nesmí být bezmyšlenkovitou reakcí. Potřebný postup je nutné navrhnout pro konkrétní operaci a její možné následky.

Technický stav přenosu zároveň nenahrazuje právní posouzení doručení. Právní účinky a rozdělení odpovědnosti doporučujeme projít s právníkem podle vašeho použití. Tento článek popisuje otázky pro návrh aplikace, nikoli právní pravidla doručování.

ARES používáme v našem vlastním produktu Innea Pro k ověřování firem podle IČO při registraci. Innea Pro je provozní systém pro české terapeuty. Je to náš vlastní produkt a ukázka integrace v provozu.

Datové schránky, registr smluv a NEN stavíme na zakázku podle zadání. Napojení těchto systémů zatím nemáme v provozovaném produktu a běžící produkt k nim přiložit nemůžeme. Zkušenost s ARES za takový důkaz nevydáváme.

Pro poptávku pomůže popsat, odkud přichází IČO, co má následovat po ověření a co se smí stát při nedostupnosti. U datové schránky přidejte očekávaný příjem a odesílání zpráv a osoby odpovědné za jednotlivé kroky. Takové zadání umožní oddělit samotné propojení od změn ve firemním procesu.

Pracujeme AI-native: vývoj akcelerujeme nástroji Claude Code a Codex, kvalitu jistíme automatizovanými testy, nezávislým code review a specialisty na vyžádání.

1. Musíme si pro ARES založit účet?

   Pro veřejné API ARES není potřeba přihlašování. Podle Ministerstva financí může služby využívat kdokoli při dodržení podmínek provozu. Přístup k vlastní datové schránce má odlišný režim a vyžaduje přihlášení.

2. Může zákazník dokončit registraci, když ARES neodpovídá?

   To má určit zadání vaší aplikace podle toho, k čemu ověření slouží. Možností je rozpracovaná registrace nebo pokračování se zřetelným stavem čekajícího ověření. Nedostupnost služby se nesmí zaměnit za potvrzení správnosti údajů.

3. Máme při každém přihlášení zákazníka znovu ověřovat jeho firmu?

   Četnost kontroly je vhodné odvodit od použití údajů, nikoli automaticky od přihlášení. Opakované načítání stejného záznamu může být zbytečné a podmínky ARES výslovně zmiňují opakované shodné dotazy. Do návrhu proto patří pravidla obnovování uložených výsledků.

4. Dodáte hotový modul pro příjem i odesílání datových zpráv?

   Obousměrné napojení nabízíme jako zakázkový vývoj. Hotový modul ověřený v našem vlastním produktu zatím nemáme. Rozsah musí zahrnout také oprávnění, schvalování a řešení nejasného výsledku komunikace.