ConnectWiz + API и уебхукове

Работеща интеграция

API-то, което продаваме, е API-то, което ползваме

Цялата платформа е описана в една OpenAPI спецификация, от която се генерират собственият ни панел и мобилното приложение – без скрити крайни точки и без документация, която изостава. Върху нея: Commerce API ключове с обхват, защитени тригери от уебхук и потоци, които извикват вашите системи.

Една OpenAPI спецификация API ключове с обхват Уебхукове с HMAC проверка
API и уебхукове × ConnectWiz
Съдържанието на заявката е данни, а не команди
Ключ с обхват: четене на каталога · запис на поръчки
Уебхук → HMAC проверката минава → потокът стартира
REST стъпка в потока извиква вашето API
1
Меродавна OpenAPI спецификация – същият файл, от който се генерират панелът и мобилните ни приложения
3
Обхвата в Commerce – четене на каталога, четене на поръчки, запис на поръчки – задавани за всеки ключ
100
Реда най-много на едно четене, с ограничение на сървъра – параметърът limit се проверява, не му се вярва на доверие
50
Реда в една поръчка през API-то – обявена граница, а не открита по трудния начин

За разработчици

Какво точно прави

Една меродавна спецификация

Един документ OpenAPI 3 описва платформата; собствените ни TypeScript клиенти се генерират от него – документацията не може да се разминава с реалността, защото реалността се изгражда от документацията.

Commerce API ключове

Ключове, които издавате сами в акаунта си, с изрични обхвати – четене на каталога, четене на поръчки, запис на поръчки – задвижват вашата собствена витрина или приложение върху същия механизъм за поръчки, а цените винаги се определят на сървъра.

Защитени входящи уебхукове

Всеки тригер от уебхук в поток има собствен URL адрес и собствена тайна, HMAC проверка върху суровото тяло на заявката и защита от повторно изпращане. Съдържанието може да посочи човек, но никога не може да управлява вътрешността на потока.

Изходящо – чрез потоци

Стъпката REST извиква системите ви точно в моментите, които начертаете на платното – направена поръчка, дадено съгласие, запазен час.

Техническата страна

Позициите ни в дизайна на API, казани ясно

Цените никога не идват от клиента

Заявката за поръчка казва какво и колко – името и цената се четат от каталога в този момент, на сървъра, и се записват в реда като моментна снимка. Подправена заявка не може да си измисли отстъпка.

Първо възможностите, после извикванията

Всяка интеграция публикува описание на възможностите си – може ли да разпознава клиента по телефон, да показва поръчки на гости, да създава поръчки? – и извикване въпреки обявено „не“ хвърля грешка веднага, вместо да се провали някъде дълбоко.

Грешки, които означават нещо

Транспортният слой различава „няма оторизация“ от „услугата не работи“ – затова „магазинът е недостъпен“ никога не се показва като „този клиент никога не е купувал нищо“. Именуваните грешки са разликата между API и игра на отгатване.

Уебхукове, защитени от повторение

Всяко входящо събитие заема уникален ключ в регистъра за идемпотентност, преди да бъде обработено – повторена или възпроизведена доставка спира на ниво база данни, а не във вашата автоматизация.

Ключовете – хеширани, тайните – с обхват

API ключовете се пазят като хешове и на входа се разпознават само хешът и обхватите – изтекъл ред от базата данни не посочва никое работно пространство и не отключва нищо извън обхватите си.

Черновите и потвържденията са изрични

Създаването на поръчка приема изричен параметър confirm – публичното API по подразбиране потвърждава, а потоците в панела могат да подготвят чернови – така „истинска ли е?“ е поле, а не уговорка.

Настройка

Как се свързва

01

Издайте ключ

Създайте Commerce API ключ с обхват в панела; оттеглете го също толкова лесно.

02

Свържете уебхук

Създайте поток с тригер от уебхук; подписвайте заявките с неговата тайна.

03

Извикайте обратно

Добавете REST стъпки там, където системите ви трябва да научат за случилото се.

Заедно е по-добре

С какво се съчетава

Flows

Тригерите от уебхук стартират потоци; стъпките REST извикват обратно системите ви в моментите, които начертаете – входящата и изходящата автоматизация делят едно платно.

Commerce

Нашият каталог и система за поръчки зад API-то са същите, които ползват магазинът в чата и AI – една истина за поръчките, четири врати.

Вашата собствена витрина

Още днес екипи изграждат headless витрини върху Commerce API – пътят, който страницата за Shopify честно препоръчва, докато се изгражда нативният конектор.

Сигурност и гаранции

Скучните гаранции

HMAC върху суровото тяло

Проверката на уебхука подписва суровото тяло на заявката с тайна, отделна за всеки тригер, и сравнява за постоянно време – разборът започва едва след доказателството.

Съдържанието на заявката е данни, а не команди

Съдържанието на уебхук може да посочи човек, но никога не може да управлява вътрешността на поток, да пренаписва промптове или да извиква инструменти. Границата между данни и инструкции е в архитектурата, а не в поведението.

Ограничение на честотата на всяка врата

Публичните крайни точки минават през стандартно ограничаване на честотата, а лимитите за четене се налагат на сървъра – клиент, който се държи зле, забавя себе си, а не платформата.

Дребният шрифт, без украса

Границите, казани ясно

Все още няма поток с всичко

Общ уебхук канал, през който да се абонирате за всичко, не е изграден – днес изходящите събития минават през стъпки в потоците. Казваме го тук, за да не се налага никой търговски разговор да загатва обратното.

Ограничено четене – нарочно

Четенето връща до 100 реда с курсор – API-то е създадено за оперативна интеграция, а не за масов експорт. Масовите нужди са тема за разговор, а не вратичка.

FAQ за API и уебхукове

Отговори без заобикалки

Още въпроси има в пълния раздел FAQ, а ако вашия го няма, пишете ни директно.

Платформата е описана в една OpenAPI 3 спецификация – същият файл, от който уеб панелът и мобилното ни приложение генерират типовете си. Това, с което се интегрирате, е това, на което работим самите ние.

Отделна тайна за всеки тригер, HMAC проверка върху суровото тяло и защита от повторно изпращане чрез регистър за идемпотентност. И по правило съдържанието е данни: може да посочи човек, но никога не командва автоматизацията.

Чрез REST стъпки в потоците, които се задействат в моментите, избрани от вас на платното. Общ изходящ уебхук канал има в пътната карта и нарочно не го обещаваме, докато не излезе.

Да – четенето на каталога и записът на поръчки са поддържаният път, като цените се определят на сървъра, а ключовете с обхват можете да оттегляте поотделно за всяка витрина. Границите от 50 реда в поръчка и 100 реда при четене са обявени, за да проектирате съобразно тях, вместо да се спъвате в тях.

Доставките са идемпотентни от наша страна – регистърът разпознава повторението и го отхвърля, така че системите ви могат спокойно да опитват отново. Изходящите REST стъпки от потоците имат собствена политика за повторни опити, а неуспехите се виждат в изпълнението на потока.

По-добре честно свързано, отколкото шумно рекламирано.

Всяка интеграция тук е описана с това, което наистина прави – включително посоката, собствеността върху данните и ограниченията.