ConnectWiz + API un webhook
Integrācija darbojasAPI, ko pārdodam, ir API, ko lietojam paši
Visa platforma ir aprakstīta vienā OpenAPI līgumā, no kura tiek ģenerēts mūsu pašu panelis un mobilā lietotne – bez slēptiem galapunktiem un bez dokumentācijas, kas atpaliek no koda. Papildus tam: Commerce API atslēgas ar ierobežotām tiesībām, aizsargāti webhook trigeri un plūsmas, kas izsauc jūsu sistēmas.
Izstrādātājiem
Ko tieši tas dara
Viens galvenais līgums
Platformu apraksta viens OpenAPI 3 dokuments, un no tā tiek ģenerēti mūsu pašu TypeScript klienti. Dokumentācija nevar atpalikt no realitātes, jo realitāte tiek būvēta no dokumentācijas.
Commerce API atslēgas
Jūsu konta izsniegtās atslēgas ar skaidri noteiktām tiesībām (kataloga lasīšana, pasūtījumu lasīšana, pasūtījumu rakstīšana) darbina jūsu pašu veikalu vai lietotni uz tā paša pasūtījumu dzinēja, un cenas vienmēr tiek noteiktas servera pusē.
Ienākošie webhook izsaukumi – aizsargāti
Katram plūsmas webhook trigerim ir savs URL un noslēpums, HMAC pārbaude pār neapstrādāto pieprasījuma saturu un aizsardzība pret atkārtojumiem. Saturs var nosaukt personu, bet nekad nevar vadīt plūsmas iekšējo darbību.
Izejošie notikumi caur plūsmām
REST solis izsauc jūsu sistēmas tieši tajos brīžos, kurus uzzīmējat uz audekla: pasūtījums veikts, piekrišana dota, rezervācija izdarīta.
Tehniskā puse
API dizaina principi – skaidri pateikti
Cenas nekad nenāk no klienta
Pasūtījuma pieprasījums norāda tikai, ko un cik. Nosaukums un cena tiek nolasīti no kataloga tajā brīdī servera pusē un ierakstīti pozīcijā kā momentuzņēmums. Viltots pieprasījums nevar izdomāt atlaidi.
Vispirms iespējas, tad izsaukumi
Katra integrācijas saskarne publicē iespēju līgumu: vai tā var atrast klientu pēc tālruņa, parādīt viesu pasūtījumus, izveidot pasūtījumus? Izsaukums, kas ignorē paziņotu “nē”, izraisa kļūdu uzreiz, nevis kaut kur dziļi sistēmā.
Kļūdas, kurām ir nozīme
Transporta slānis atšķir “nav autorizēts” no “pakalpojums nedarbojas”, tāpēc “veikals nav sasniedzams” nekad netiek parādīts kā “šis klients nekad neko nav pircis”. Nosauktas kļūdas ir tas, kas atšķir API no minēšanas spēles.
Pret atkārtojumiem drošs webhook
Katrs ienākošais notikums pirms apstrādes rezervē unikālu atslēgu idempotences uzskaitē. Atkārtota vai atskaņota piegāde tiek apturēta datubāzes līmenī, nevis jūsu automatizācijā.
Atslēgas jauktas, noslēpumi ierobežoti
API atslēgas tiek glabātas kā jaucējvērtības, un pie ieejas var nolasīt tikai jaucējvērtību un tiesības. Noplūdusi datubāzes rinda nenosauc nevienu kontu un neatslēdz neko ārpus savām tiesībām.
Melnraksti un apstiprinājumi ir skaidri nošķirti
Pasūtījuma izveidei ir skaidrs confirm parametrs: publiskajā API pēc noklusējuma pasūtījums ir apstiprināts, bet paneļa plūsmas var sagatavot melnrakstus. Tāpēc jautājums “vai tas ir īsts?” ir lauks, nevis vienošanās.
Iestatīšana
Kā tas tiek pieslēgts
Izsniedziet atslēgu
Izveidojiet panelī Commerce API atslēgu ar ierobežotām tiesībām – atsaukt to var tikpat viegli.
Pieslēdziet webhook
Izveidojiet plūsmu ar webhook trigeri un parakstiet pieprasījumus ar tā noslēpumu.
Izsauciet atpakaļ
Pievienojiet REST soļus tur, kur jūsu sistēmām par to jāuzzina.
Kopā labāk
Ar ko tas sadarbojas
Flows
Webhook trigeri palaiž plūsmas, bet REST soļi izsauc jūsu sistēmas jūsu uzzīmētajos brīžos – ienākošā un izejošā automatizācija atrodas uz viena audekla.
Commerce
Mūsu kataloga un pasūtījumu dzinējs darbina arī API – tas pats, ko izmanto tērzēšanas veikals un MI: viena patiesība par pasūtījumiem, četras durvis.
Jūsu pašu veikals
Komandas jau šodien darbina headless veikalus uz Commerce API. Tas ir ceļš, ko Shopify lapa godīgi iesaka, kamēr tiek izstrādāts natīvais savienotājs.
Drošība un garantijas
Garlaicīgās garantijas
HMAC pār neapstrādāto saturu
Webhook pārbaude paraksta neapstrādāto pieprasījuma saturu ar katra trigera noslēpumu un salīdzina konstantā laikā. Parsēšana notiek tikai pēc pierādījuma.
Saturs ir dati, nekad ne komandas
Webhook saturs var atsaukties uz personu, bet nekad nevar vadīt plūsmas iekšējo darbību, pārrakstīt uzvednes vai izsaukt rīkus. Robeža starp datiem un instrukcijām ir arhitektūras, nevis uzvedības jautājums.
Pieprasījumu limiti pie katrām durvīm
Publiskajiem galapunktiem ir standarta pieprasījumu ierobežošana, un lasīšanas limiti tiek piespiedu kārtā ierobežoti servera pusē. Nekorekts klients bremzē pats sevi, nevis platformu.
Sīkais druks bez izskaistināšanas
Skaidri novilktas robežas
Vispārīga webhook abonementa vēl nav
Vispārīgs webhook abonements uz visiem notikumiem nav izstrādāts – izejošie notikumi šodien notiek caur plūsmu soļiem. To sakām šeit, lai nevienā pārdošanas sarunā nebūtu jāliek noprast ko citu.
Ierobežota lasīšana – apzināti
Lasīšana atgriež līdz 100 rindām ar kursoru. API ir veidota operatīvai integrācijai, nevis masveida eksportam. Masveida vajadzības ir sarunas temats, nevis apiešanas ceļš.
API un webhook BUJ
Atbildes bez aplinkiem
Vairāk atbilžu atradīsiet sadaļā BUJ, vai arī jautājiet mums tieši.
Godīgi savienots ir labāk nekā skaļi izreklamēts.
Katra integrācija šeit aprakstīta pēc tās reālās darbības – ar virzienu, datu piederību un ierobežojumiem.