ConnectWiz + API at Webhook

Live na integrasyon

Ang API na ibinebenta namin, siya ring gamit namin

Iisang OpenAPI contract ang naglalarawan sa buong platform, at mula rito binubuo ang sarili naming panel at mobile app — walang nakatagong endpoint, walang docs na napag-iiwanan. Sa ibabaw nito: mga Commerce API key na may scope, mga secured na webhook trigger, at mga flow na tumatawag sa mga sistema mo.

Magsimula nang libre Lahat ng integrasyon
Iisang OpenAPI contract Mga API key na may scope Mga webhook na na-verify sa HMAC
API at Webhook × ConnectWiz
Data ang payload, hindi kailanman utos
Key na may scope: pagbasa ng katalogo · pagsulat ng order
Webhook → na-verify ang HMAC → nagsisimula ang flow
Tinatawag ng REST step ng flow ang API mo
1
Ang opisyal na OpenAPI contract — ang parehong file na pinagmumulan ng sarili naming panel at mga mobile app
3
Mga scope ng Commerce — pagbasa ng katalogo, pagbasa ng order, pagsulat ng order — ibinibigay kada key
100
Pinakamaraming row kada pagbasa, nililimitahan sa server — vina-validate ang limit parameter, hindi basta pinagkakatiwalaan
50
Line item kada order sa API — hangganang nakasaad, hindi hangganang matutuklasan mo na lang

Mga developer

Ano ang ginagawa nito — eksakto

Iisang opisyal na contract

Iisang OpenAPI 3 document ang naglalarawan sa platform; mula rito binubuo ang sarili naming mga TypeScript client — hindi mapag-iiwanan ng realidad ang docs dahil mula sa docs binubuo ang realidad.

Mga Commerce API key

Mga key na inilalabas ng tenant, may tahasang scope — pagbasa ng katalogo, pagbasa ng order, pagsulat ng order — na nagpapatakbo sa sarili mong storefront o app gamit ang parehong order engine, at palaging sa server kinakalkula ang presyo.

Mga papasok na webhook, protektado

May sariling URL at secret ang bawat webhook trigger ng flow, HMAC verification sa raw body, at proteksyon laban sa replay. Puwedeng magbanggit ng tao ang payload; hindi nito kailanman makokontrol ang loob ng flow.

Palabas, sa pamamagitan ng mga flow

Tinatawagan ng REST step ang mga sistema mo sa eksaktong mga sandaling iginuhit mo sa canvas — may nag-order, may nagbigay ng pahintulot, may nag-book.

Teknikal na detalye

Mga posisyon sa disenyo ng API, tahasang sinabi

Hindi kailanman galing sa client ang presyo

Ano at ilan lang ang sinasabi ng order request — binabasa ang pangalan at presyo mula sa katalogo sa sandaling iyon, sa server, at isinusulat sa line bilang snapshot. Hindi makakaimbento ng discount ang binagong request.

Kakayahan muna bago tumawag

Naglalathala ang bawat integration surface ng capability contract — kaya ba nitong mag-match gamit ang telepono, maglista ng order ng guest, gumawa ng order? — at kapag tumawag lampas sa idineklarang "hindi", agad itong nagbabato ng error sa halip na pumalya sa kung saang kalaliman.

Mga error na may kahulugan

Pinaghihiwalay ng transport ang "unauthorized" at ang "service down" — kaya hindi kailanman lumalabas ang "hindi maabot ang shop" bilang "hindi pa kailanman bumili ang customer na ito". Ang mga error na may pangalan ang pinagkaiba ng API sa hulaan.

Mga webhook na hindi malulusutan ng replay

Kumukuha ng natatanging key sa idempotency ledger ang bawat papasok na event bago ito iproseso — sa database layer namamatay ang inulit o ni-replay na delivery, hindi sa automation mo.

Naka-hash ang mga key, may scope ang mga secret

Hash lang ang iniimbak para sa mga API key, at ang hash at mga scope lang ang nababasa sa pinto — walang workspace na pinapangalanan ang na-leak na database row, at wala itong nabubuksan lampas sa mga scope nito.

Tahasan ang draft at ang kumpirmasyon

May tahasang confirm parameter ang paggawa ng order — confirmed ang default ng public API, at puwedeng maghanda ng draft ang mga flow sa panel — kaya field ang "totoo ba ito?", hindi kasunduan lang.

Pag-set up

Paano ito kumokonekta

01

Maglabas ng key

Gumawa ng Commerce API key na may scope sa panel; kasingdali ring bawiin.

02

Ikabit ang webhook

Gumawa ng flow na may webhook trigger; i-sign ang mga request gamit ang secret nito.

03

Tumawag palabas

Magdagdag ng mga REST step kung saan kailangang malaman ito ng mga sistema mo.

Mas mahusay kapag magkasama

Ano ang puwedeng ipares dito

Flows

Sinisimulan ng mga webhook trigger ang mga flow; tinatawagan pabalik ng mga REST step ang mga sistema mo sa mga sandaling iginuhit mo — iisang canvas ang pinaghahatian ng papasok at palabas na automation.

Commerce

Ang katalogo at order engine sa likod ng API ay siya ring ginagamit ng chat shop at ng AI — iisang katotohanan ng order, apat na pinto.

Sarili mong storefront

Nagpapatakbo na ngayon ang mga team ng headless storefront sa Commerce API — ito ang paraang tapat na inirerekomenda ng Shopify page habang binubuo pa ang native connector.

Seguridad at mga garantiya

Ang mga boring na garantiya

HMAC sa raw body

Sa webhook verification, sine-sign ang raw request body gamit ang secret ng bawat trigger at ikinukumpara sa constant time — pagkatapos lang ng patunay nangyayari ang pag-parse.

Data ang payload, hindi kailanman utos

Puwedeng tumukoy ng tao ang webhook payload; hindi nito kailanman makokontrol ang loob ng flow, maisusulat muli ang mga prompt, o matatawag ang mga tool. Nasa arkitektura ang hangganan sa pagitan ng data at ng instruksyon, hindi sa pag-uugali.

Rate limit sa bawat pinto

Dumadaan sa standard na throttling ang mga public endpoint, at nililimitahan sa server ang read limit — ang client na nagkakamali ay sarili lang ang pinababagal, hindi ang platform.

Ang fine print, walang paligoy-ligoy

Mga hangganan, tahasang sinabi

Wala pang firehose

Hindi pa binuo ang generic na webhook feed na nagsu-subscribe sa lahat — sa pamamagitan ng mga step ng flow nangyayari ngayon ang mga palabas na event. Nakasaad ito rito, para walang sales call na kailangang magpahiwatig ng iba.

May hangganan ang pagbasa, sadya

Hanggang 100 row lang ang ibinabalik ng bawat pagbasa, may cursor — para sa operational na integrasyon ang API, hindi para sa maramihang export. Pinag-uusapan ang pangangailangan sa bulk, hindi nilulusutan.

FAQ sa API at Webhook

Diretsahang sagot

Marami pang sagot sa buong FAQ, o kaya magtanong nang direkta sa amin.

Iisang OpenAPI 3 contract ang naglalarawan sa platform — ang parehong file na pinagkukunan ng mga type ng web panel at mobile app namin. Kung ano ang ini-integrate mo, iyon mismo ang pinapatakbo namin.

Secret para sa bawat trigger, HMAC verification sa raw body, at proteksyon laban sa replay sa pamamagitan ng idempotency ledger. At bilang patakaran, data ang mga payload: puwede silang tumukoy ng tao, pero hindi kailanman mag-utos sa automation.

Sa pamamagitan ng mga REST step ng flow, na tumatakbo sa mga sandaling pinili mo sa canvas. Nasa roadmap ang generic na palabas na webhook feed, at sadyang hindi ipinapangako hangga’t hindi pa ito lumalabas.

Oo — pagbasa ng katalogo at pagsulat ng order ang sinusuportahang paraan, na sa server kinakalkula ang presyo at may mga key na may scope na puwede mong bawiin kada surface. Nakasaad ang hangganang 50 line at 100 row para idisenyo mo ang sistema ayon dito sa halip na matisod dito.

Idempotent ang mga delivery sa panig namin — nakikilala ng ledger ang replay at itinatapon ito, kaya ligtas na mag-retry ang mga sistema mo. May sariling retry policy ang mga palabas na REST step mula sa mga flow, at lumalabas ang mga pagkabigo sa flow run.

Mas mahalaga ang tapat na koneksyon kaysa sa maingay.

Inilalarawan namin ang bawat integrasyon dito ayon sa talagang ginagawa nito — kasama ang direksyon, pagmamay-ari, at mga limitasyon.

Magsimula nang libre Lahat ng integrasyon