ConnectWiz + API și webhookuri
Integrare activăAPI-ul pe care îl vindem e API-ul pe care îl folosim
Întreaga platformă e specificată într-un singur contract OpenAPI din care se generează chiar panoul și aplicația noastră mobilă – fără endpointuri ascunse, fără documentație rămasă în urmă. Peste el: chei API Commerce cu permisiuni restrânse, declanșatoare webhook securizate și fluxuri care vă apelează sistemele.
Dezvoltatori
Ce face, mai exact
Un singur contract de referință
Un singur document OpenAPI 3 specifică platforma, iar clienții noștri TypeScript se generează din el – documentația nu se poate îndepărta de realitate, fiindcă realitatea e construită din documentație.
Chei API Commerce
Chei emise per tenant, cu permisiuni explicite – citire catalog, citire comenzi, scriere comenzi – alimentează propriul magazin sau propria aplicație pe același motor de comenzi, cu prețurile rezolvate mereu pe server.
Webhookuri de intrare, securizate
Fiecare declanșator webhook de flux are URL și secret proprii, verificare HMAC peste corpul brut al cererii și protecție împotriva reluării. Un payload poate numi o persoană; nu poate niciodată să dirijeze interiorul fluxului.
Ieșire prin fluxuri
Pasul REST vă apelează sistemele exact în momentele pe care le desenați pe pânză – comandă plasată, consimțământ acordat, rezervare făcută.
Partea tehnică
Poziții asumate în designul API-ului
Prețurile nu vin niciodată de la client
O cerere de comandă spune ce și cât anume – numele și prețul se citesc din catalog chiar în acel moment, pe server, și se scriu pe linie ca instantaneu. O cerere măsluită nu poate inventa o reducere.
Capabilitățile înaintea apelurilor
Fiecare punct de integrare publică un contract de capabilități – poate potrivi după telefon, poate lista comenzile de oaspete, poate crea comenzi? – iar un apel care trece peste un „nu” declarat eșuează imediat, nu undeva în adânc.
Erori care înseamnă ceva
Transportul deosebește „neautorizat” de „serviciu picat” – așa că „magazinul e inaccesibil” nu se afișează niciodată ca „acest client n-a cumpărat nimic niciodată”. Erorile cu nume sunt diferența dintre un API și un joc de ghicit.
Webhookuri imune la reluare
Fiecare eveniment de intrare își revendică o cheie unică într-un registru de idempotență înainte de procesare – o livrare reîncercată sau reluată moare la nivelul bazei de date, nu în automatizarea dumneavoastră.
Chei păstrate ca hash, secrete cu permisiuni restrânse
Cheile API se păstrează ca hash, iar la ușă se pot rezolva doar hashul și permisiunile – un rând de bază de date scurs nu numește niciun spațiu de lucru și nu deschide nimic dincolo de permisiunile lui.
Ciornele și confirmările sunt explicite
Crearea unei comenzi primește un parametru explicit de confirmare – API-ul public e implicit pe „confirmat”, iar fluxurile din panou pot pregăti ciorne – așa că „e reală?” e un câmp, nu o convenție.
Configurare
Cum se conectează
Emiteți o cheie
Creați în panou o cheie API Commerce cu permisiuni restrânse; o revocați la fel de ușor.
Legați un webhook
Creați un flux cu declanșator webhook; semnați cererile cu secretul lui.
Apelați în exterior
Adăugați pași REST acolo unde sistemele dumneavoastră trebuie să afle.
Mai bine împreună
Cu ce se combină
Flows
Declanșatoarele webhook pornesc fluxuri; pașii REST vă apelează înapoi sistemele în momentele pe care le desenați – automatizarea de intrare și cea de ieșire împart aceeași pânză.
Commerce
Aici, motorul de catalog și comenzi din spatele API-ului e același pe care îl folosesc și magazinul din chat, și AI – un singur adevăr despre comenzi, patru uși.
Propriul magazin online
Echipele rulează azi magazine headless pe API-ul Commerce – calea pe care pagina Shopify o recomandă onest cât timp se construiește conectorul nativ.
Securitate și garanții
Garanțiile plictisitoare
HMAC peste corpul brut
Verificarea webhookului semnează corpul brut al cererii cu un secret propriu fiecărui declanșator și compară în timp constant – parsarea începe abia după dovadă.
Payloadurile sunt date, niciodată comenzi
Un payload de webhook poate face referire la o persoană; nu poate niciodată să dirijeze interiorul unui flux, să rescrie prompturi sau să invoce unelte. Granița dintre date și instrucțiuni e arhitecturală, nu comportamentală.
Limite de rată la fiecare ușă
Endpointurile publice trec prin limitarea standard, iar limitele de citire sunt plafonate pe server – un client care se poartă urât se degradează pe sine, nu platforma.
Scrisul mărunt, fără ocolișuri
Limitele, scrise negru pe alb
Încă nu există un flux global
Un flux de webhookuri generic, la care să vă abonați pentru absolut tot, nu e construit – deocamdată evenimentele de ieșire trec prin pașii de flux. O scriem aici, ca niciun apel de vânzări să nu sugereze altceva.
Citiri mărginite, prin construcție
O citire întoarce cel mult 100 de rânduri, cu cursor – API-ul e construit pentru integrare operațională, nu pentru export în masă. Nevoile de export în masă se discută, nu se strecoară printr-o portiță.
Întrebări frecvente despre API și webhookuri
Răspunsuri directe
Mai multe răspunsuri sunt în secțiunea Întrebări frecvente, iar pentru rest, scrieți-ne direct.
Conectat onest bate conectat zgomotos.
Fiecare integrare de aici e descrisă prin ceea ce face cu adevărat: direcția, proprietatea datelor și limitele, toate incluse.