Integrace skladu, ERP nebo dopravního portálu nemá každých pár sekund zjišťovat, jestli se v Time Slot Control něco změnilo. Outbound webhooky předají událost ve chvíli, kdy vznikne, a současně uchovají jasný výsledek každého pokusu o doručení.

Od události k doručení bez pollingu

Když se změní rezervace nebo objednávka, TSC vytvoří událost a vybere aktivní webhookové odběry, které daný typ sledují. Každý odběr dostane verzovaný JSON přes HTTP POST na svou cílovou adresu.

TSC zaznamená změnu a vytvoří jedinečnou událost.
Aktivní odběry se porovnají s jejím typem.
Pro každý odpovídající odběr vznikne samostatné doručení.
Odpověď cílového systému určí výsledný stav nebo další pokus.

Zpracování je řízené událostmi a probíhá asynchronně. Napojený systém tak nemusí zatěžovat API častými polling dotazy a může reagovat krátce po skutečné změně.

Schéma doručení outbound webhooku od události v TSC přes podepsaný HTTP POST až po stav Delivered, Failed nebo DeadLetter a ruční Resend

Doručovací log nahrazuje dohady

Administrátor vidí doručení na jednom místě a může je filtrovat podle webhookového odběru i stavu. U každého záznamu je k dispozici typ události, počet pokusů, poslední HTTP stav, čas posledního pokusu a stručná informace o chybě.

Stav	Co znamená
Pending	Doručení čeká ve frontě na první nebo další pokus.
Delivered	Cílový systém vrátil úspěšnou HTTP odpověď.
Failed	Poslední pokus skončil dočasnou chybou a bude se opakovat.
DeadLetter	Automatické pokusy skončily nebo odpověď nemá být automaticky opakována.

Co se stane, když je cílový systém nedostupný

Síťové chyby, odpovědi HTTP 429 a serverové chyby 5xx se opakují s rostoucím odstupem, nejvýše v pěti pokusech. Běžné klientské chyby 4xx kromě 429 přejdou rovnou do stavu DeadLetter, protože další automatický pokus by zpravidla dopadl stejně.

Po opravě přijímajícího systému může oprávněný uživatel použít Resend. TSC vynuluje počet pokusů, odstraní poslední chybu a vrátí doručení do fronty. Není tedy nutné znovu vyvolávat původní obchodní událost.

Události, které odpovídají skutečnému provozu

Katalog nekončí u obecného vytvoření, změny a smazání. Integrace může odebírat také konkrétní okamžiky životního cyklu rezervace a objednávky, například reservation.pending, reservation.approval.approved, reservation.markedasarrival, reservation.processingstarted, reservation.vehicle.platechanged, reservation.markedasdeparted nebo order.confirmed.

Odběr si vybírá jen události, které potřebuje. Cílový systém tak nemusí z obecné změny zpětně odvozovat, co se v provozu skutečně stalo.

Podepsané zprávy a bezpečné zpracování

Webhooková adresa používá HTTPS. TSC posílá JSON obálku s poli schemaVersion, eventId, event, tenantId, occurredAt a data. Tělo požadavku je podepsané pomocí HMAC-SHA256 a příjemce dostane podpis v hlavičce X-TSC-Signature spolu s časovým razítkem X-TSC-Timestamp.

Přijímající systém by měl podpis a časové razítko ověřit, zpracovávat eventId idempotentně a vrátit úspěšný 2xx stav až poté, co zprávu bezpečně převzal. Tajný klíč lze při změně zabezpečení rotovat.

Co to přináší integračnímu provozu

méně polling dotazů a nižší zátěž na obou stranách integrace,
čitelný stav každého doručení bez hledání v několika logovacích nástrojích,
automatické zotavení z dočasných chyb,
řízené ruční opakování po opravě cílového systému,
ověřitelný původ a integrita každé zprávy.

Výsledkem není jen rychlejší přenos událostí, ale hlavně provozně předvídatelná integrace: tým vidí, co bylo doručeno, co čeká na další pokus a co vyžaduje zásah.

Chcete napojit TSC na ERP, WMS nebo vlastní integrační platformu? Projděte si možnosti integrací nebo nám popište svůj scénář.