ConnectWiz + API a webhooky

Integrace v provozu

API, které prodáváme, je API, které sami používáme

Celou platformu popisuje jedna smlouva v OpenAPI, ze které se generuje náš vlastní panel i mobilní aplikace – žádné stínové endpointy, žádný rozjezd dokumentace. Nad ní: Commerce API klíče s rozsahem, jištěné webhookové triggery a scénáře, které volají vaše systémy.

Jedna smlouva v OpenAPI API klíče s rozsahem Webhooky ověřené HMAC
API a webhooky × ConnectWiz
Payloady jsou data, nikdy příkazy
Klíč s rozsahem: čtení katalogu · zápis objednávek
Webhook → ověřeno HMAC → spustí se scénář
Krok REST ve scénáři volá vaše API
1
Závazná smlouva v OpenAPI – tentýž soubor, ze kterého se generuje náš vlastní panel i mobilní aplikace
3
Rozsahy v Commerce – čtení katalogu, čtení objednávek, zápis objednávek – vydávané ke každému klíči
100
Maximum řádků na jedno čtení, zastropované na serveru – parametr limitu se validuje, nikdy se mu nevěří
50
Položek na objednávku přes API – vyhlášená mez, ne mez objevená za provozu

Pro vývojáře

Co přesně umí

Jedna závazná smlouva

Platformu popisuje jediný dokument v OpenAPI 3; generují se z něj naši vlastní TypeScriptoví klienti – dokumentace se nemůže rozejít s realitou, protože realita se staví z dokumentace.

API klíče do Commerce

Klíče vydané v rámci tenanta s výslovnými rozsahy – čtení katalogu, čtení objednávek, zápis objednávek – pohánějí váš vlastní obchod nebo aplikaci na stejném objednávkovém jádru, s cenami vždy vyřešenými na serveru.

Příchozí webhooky, zabezpečené

Každý webhookový trigger ve scénáři má vlastní URL a tajemství, ověření HMAC nad surovým tělem požadavku a ochranu proti přehrání. Payload může někoho jmenovat; nikdy nesmí řídit vnitřek scénáře.

Odchozí přes scénáře

Krok REST volá vaše systémy přesně v momentech, které si nakreslíte na plátno – objednávka podána, souhlas udělen, rezervace vytvořena.

Technické pozadí

Postoje k návrhu API, řečené nahlas

Ceny nikdy nepřicházejí od klienta

Požadavek na objednávku říká co a kolik – název a cenu si systém v tu chvíli přečte z katalogu na serveru a zapíše je na řádek jako otisk. Zmanipulovaný požadavek si slevu nevymyslí.

Nejdřív schopnosti, pak volání

Každý integrační vstup zveřejňuje smlouvu o schopnostech – umí párovat podle telefonu, vypsat objednávky hostů, zakládat objednávky? – a volání za vyhlášené „ne“ vyhodí chybu okamžitě, místo aby spadlo někde hluboko.

Chyby, které něco znamenají

Transportní vrstva rozlišuje „neautorizováno“ od „služba neběží“ – takže z „obchod je nedostupný“ se nikdy nestane „tenhle zákazník si nikdy nic nekoupil“. Pojmenované chyby jsou rozdíl mezi API a hádankou.

Webhooky odolné proti přehrání

Každá příchozí událost si před zpracováním nárokuje unikátní klíč v evidenci idempotence – zopakované nebo přehrané doručení umře na vrstvě databáze, ne ve vaší automatizaci.

Klíče v hashi, tajemství s rozsahem

API klíče se ukládají jako hashe a ve dveřích se dá zjistit jen hash a rozsahy – uniklý řádek z databáze nepojmenuje žádný pracovní prostor a neodemkne nic nad rámec svých rozsahů.

Koncepty a potvrzení jsou výslovné

Založení objednávky bere výslovný parametr confirm – veřejné API má ve výchozím stavu potvrzeno, scénáře v panelu umějí připravit koncept – takže „je to doopravdy?“ je pole, ne domluva.

Nastavení

Jak se propojuje

01

Vydejte klíč

V panelu vytvořte API klíč do Commerce s rozsahem; stejně snadno ho zase zneplatníte.

02

Zapojte webhook

Vytvořte scénář s webhookovým triggerem; požadavky podepisujte jeho tajemstvím.

03

Zavolejte ven

Přidejte kroky REST tam, kde se to vaše systémy musejí dozvědět.

Lepší dohromady

S čím se propojuje

Flows

Webhookové triggery spouštějí scénáře; kroky REST volají vaše systémy zpátky v momentech, které si nakreslíte – příchozí i odchozí automatizace sdílejí jedno plátno.

Commerce

Náš katalog a objednávkové jádro za API je totéž, co pohání chatový obchod i AI – jedna pravda o objednávce, čtvery dveře.

Váš vlastní obchod

Týmy dnes na Commerce API provozují headless obchody – je to cesta, kterou bez příkras doporučuje stránka Shopify na dobu, než vznikne nativní konektor.

Bezpečnost a záruky

Nudné záruky

HMAC nad surovým tělem požadavku

Ověření webhooku podepíše surové tělo požadavku tajemstvím daného triggeru a porovná ho v konstantním čase – parsuje se až po důkazu.

Payloady jsou data, nikdy příkazy

Payload webhooku může odkazovat na osobu; nikdy nesmí řídit vnitřek scénáře, přepisovat prompty ani volat nástroje. Hranice mezi daty a instrukcemi je architektonická, ne behaviorální.

Limity na každých dveřích

Veřejné endpointy jedou na standardním omezování a limity čtení jsou zastropované na serveru – nevychovaný klient shodí sám sebe, ne platformu.

Drobné písmo bez příkras

Hranice řečené nahlas

Zatím žádný proud všeho

Obecný webhookový kanál, kde se přihlásíte úplně ke všemu, postavený není – odchozí události dnes chodí přes kroky ve scénáři. Píšeme to sem, aby to žádný obchodní hovor nemusel naznačovat jinak.

Omezená čtení už z návrhu

Čtení vrací až 100 řádků s kurzorem – API je postavené na provozní integraci, ne na hromadný export. Hromadné potřeby jsou téma na rozhovor, ne díra v pravidlech.

FAQ o API a webhoocích

Odpovědi na rovinu

Více v kompletním FAQ, případně napište přímo nám.

Platformu popisuje jedna smlouva v OpenAPI 3 – tentýž soubor, ze kterého si generuje typy náš webový panel i mobilní aplikace. Integrujete se proti tomu, na čem sami běžíme.

Tajemství pro každý trigger zvlášť, ověření HMAC nad surovým tělem požadavku a ochrana proti přehrání přes evidenci idempotence. A z principu jsou payloady data: mohou odkazovat na osobu, nikdy nesmějí automatizaci přikazovat.

Přes kroky REST ve scénáři, spuštěné v momentech, které si vyberete na plátně. Obecný odchozí webhookový kanál je v plánu vývoje a záměrně ho neslibujeme, dokud nevyjde.

Ano – čtení katalogu a zápis objednávek jsou podporovaná cesta, s cenami vyřešenými na serveru a s klíči s rozsahem, které můžete zneplatnit pro každý vstup zvlášť. Meze 50 položek a 100 řádků jsou vyhlášené proto, abyste na ně navrhovali, a ne o ně zakopli.

Doručení jsou na naší straně idempotentní – evidence pozná přehrání a zahodí ho, takže vaše systémy můžou bezpečně opakovat. Odchozí kroky REST ze scénářů mají vlastní politiku opakování a selhání se ukážou u daného běhu scénáře.

Poctivě propojeno je víc než hlasitě ohlášeno.

Každá integrace je tady popsaná tím, co doopravdy dělá – včetně směru, vlastnictví dat a limitů.