ConnectWiz + API და webhook-ები
მოქმედი ინტეგრაციაAPI, რომელსაც ვყიდით, იგივეა, რასაც თავად ვიყენებთ
მთელი პლატფორმა ერთ OpenAPI კონტრაქტშია აღწერილი, რომლიდანაც ჩვენი საკუთარი პანელი და მობილური აპი გენერირდება — არანაირი ფარული ენდპოინტები, არანაირი აცდენა დოკუმენტაციასა და რეალობას შორის. ამის თავზე: Commerce-ის API-გასაღებები შეზღუდული უფლებებით, დაცული webhook-ტრიგერები და სცენარები, რომლებიც თქვენს სისტემებს მიმართავს.
დეველოპერები
რას აკეთებს — ზუსტად
ერთი ოფიციალური კონტრაქტი
პლატფორმას ერთი OpenAPI 3 დოკუმენტი აღწერს; ჩვენი საკუთარი TypeScript-კლიენტები მისგან გენერირდება — დოკუმენტაცია რეალობას ვერ დაშორდება, რადგან რეალობა თავად დოკუმენტაციიდან იქმნება.
Commerce-ის API-გასაღებები
ტენანტის მიერ გაცემული გასაღებები მკაფიო უფლებებით — კატალოგის წაკითხვა, შეკვეთების წაკითხვა, შეკვეთების ჩაწერა — თქვენს საკუთარ ონლაინ მაღაზიას ან აპს იმავე შეკვეთების ძრავაზე ამუშავებს, ფასები კი ყოველთვის სერვერის მხარეს განისაზღვრება.
შემომავალი webhook-ები, დაცული
სცენარის ყველა webhook-ტრიგერს საკუთარი URL და საიდუმლო გასაღები აქვს, HMAC-შემოწმება ნედლ სხეულზე და განმეორებითი გაგზავნისგან დაცვა. მონაცემებში შეიძლება ადამიანი იყოს მოხსენიებული; სცენარის შიდა ლოგიკას ისინი ვერასდროს მართავს.
გამავალი კავშირი სცენარებით
REST-ნაბიჯი თქვენს სისტემებს ზუსტად იმ მომენტებში მიმართავს, რომლებსაც ტილოზე ხატავთ — შეკვეთა გაფორმდა, თანხმობა მიღებულია, ჯავშანი შედგა.
ტექნიკური მხარე
API-ის დიზაინი: ჩვენი პოზიცია, პირდაპირ ნათქვამი
ფასი კლიენტიდან არასდროს მოდის
შეკვეთის მოთხოვნაში მხოლოდ ისაა მითითებული, რა და რამდენი — სახელი და ფასი იმ მომენტში სერვერის მხარეს იკითხება კატალოგიდან და პოზიციაზე სნეპშოტის სახით იწერება. გაყალბებული მოთხოვნა ფასდაკლებას ვერ მოიგონებს.
ჯერ შესაძლებლობები, მერე გამოძახებები
ინტეგრაციის თითოეული ინტერფეისი აქვეყნებს შესაძლებლობების კონტრაქტს — შეუძლია თუ არა ტელეფონით დამთხვევა, სტუმრის შეკვეთების ჩამოთვლა, შეკვეთების შექმნა? — და გამოცხადებული „არას“ გვერდის ავლით გამოძახება მაშინვე შეცდომას აგდებს, ნაცვლად იმისა, რომ სადღაც სიღრმეში ჩავარდეს.
შეცდომები, რომლებსაც აზრი აქვს
სატრანსპორტო ფენა ორ შემთხვევას ასხვავებს — „არაავტორიზებული“ და „სერვისი მიუწვდომელია“ — ამიტომ „მაღაზია მიუწვდომელია“ არასდროს გამოჩნდება როგორც „ამ მომხმარებელს არასდროს არაფერი უყიდია“. დასახელებული შეცდომები განასხვავებს API-ს გამოცნობანას თამაშისგან.
განმეორებისგან დაცული webhook-ები
ყოველი შემომავალი მოვლენა დამუშავებამდე იდემპოტენტურობის ჟურნალში უნიკალურ გასაღებს იკავებს — ხელახლა ან განმეორებით გამოგზავნილი მოვლენა მონაცემთა ბაზის დონეზე ჩერდება და არა თქვენს ავტომატიზაციაში.
გასაღებები ჰეშირებულია, საიდუმლოებები — შეზღუდული
API-გასაღებები ჰეშების სახით ინახება და შესასვლელთან მხოლოდ ჰეში და უფლებები იკითხება — მონაცემთა ბაზიდან გაჟონილი სტრიქონი არც სამუშაო სივრცეს ასახელებს და არც თავისი უფლებების მიღმა რამეს ხსნის.
მონახაზი და დადასტურება — მკაფიოდ
შეკვეთის შექმნას მკაფიო confirm პარამეტრი სჭირდება — საჯარო API ნაგულისხმევად ადასტურებს, პანელის სცენარებს კი მონახაზების მომზადება შეუძლია — ასე რომ, კითხვა „ეს ნამდვილია?“ ველით წყდება და არა შეთანხმებით.
დაყენება
როგორ უკავშირდება
გასცით გასაღები
პანელში შექმენით Commerce-ის API-გასაღები შეზღუდული უფლებებით; გაუქმებაც ასევე მარტივია.
დააკავშირეთ webhook
შექმენით სცენარი webhook-ტრიგერით; მოთხოვნები მისი საიდუმლო გასაღებით მოაწერეთ.
მიმართეთ გარე სისტემებს
დაამატეთ REST-ნაბიჯები იქ, სადაც თქვენმა სისტემებმა ამის შესახებ უნდა შეიტყოს.
ერთად უკეთესია
რასთან ერთად მუშაობს
Flows
Webhook-ტრიგერები უშვებს სცენარებს; REST-ნაბიჯები კი თქვენს სისტემებს ზუსტად იმ მომენტებში მიმართავს, რომლებსაც ტილოზე ხატავთ — შემომავალი და გამავალი ავტომატიზაცია ერთ ტილოს იზიარებს.
Commerce
ჩვენი კატალოგისა და შეკვეთების ძრავა ერთი და იგივეა API-სთვისაც, ჩატ-მაღაზიისთვისაც და AI-სთვისაც — შეკვეთების ერთი ჭეშმარიტება, ოთხი კარი.
საკუთარი ონლაინ მაღაზია
გუნდები უკვე დღეს აწყობენ headless მაღაზიებს Commerce API-ზე — სწორედ ამ გზას Shopify-ის გვერდი გულწრფელად გირჩევთ, სანამ ნატიური კონექტორი მზადდება.
უსაფრთხოება და გარანტიები
მოსაწყენი გარანტიები
HMAC ნედლ სხეულზე
Webhook-ის შემოწმება მოთხოვნის ნედლ სხეულს ტრიგერის საკუთარი საიდუმლო გასაღებით აწერს ხელს და მუდმივ დროში ადარებს — პარსინგი მხოლოდ მტკიცებულების შემდეგ იწყება.
მონაცემი და არასდროს ბრძანება
Webhook-ის მონაცემებში შეიძლება ადამიანი იყოს მოხსენიებული; სცენარის შიდა ლოგიკას, პრომპტებს ან ინსტრუმენტებს ისინი ვერასდროს მართავს. ზღვარი მონაცემებსა და ინსტრუქციებს შორის არქიტექტურულია და არა ქცევითი.
სიჩქარის ლიმიტი ყველა კარზე
საჯარო ენდპოინტებზე სტანდარტული შეზღუდვები მოქმედებს, წაკითხვის ლიმიტები კი სერვერის მხარეს იზღუდება — ცუდად მოქცეული კლიენტი საკუთარ თავს აზიანებს და არა პლატფორმას.
წვრილი შრიფტი, დამალვის გარეშე
საზღვრები, პირდაპირ ნათქვამი
მოვლენების სრული ნაკადი ჯერ არ არის
ზოგადი webhook-ნაკადი, რომელიც ყველა მოვლენას გამოგიწერთ, აწყობილი არ არის — გამავალი მოვლენები დღეს სცენარის ნაბიჯებით ხორციელდება. აქ პირდაპირ ვწერთ, რომ არცერთ გაყიდვების ზარზე სხვა რამის მინიშნება არ მოგიწიოთ.
შეზღუდული წაკითხვა — განზრახ
წაკითხვა 100 სტრიქონამდე აბრუნებს კურსორით — API ოპერაციული ინტეგრაციისთვისაა შექმნილი და არა მასობრივი ექსპორტისთვის. მასობრივი საჭიროება საუბრის თემაა და არა ხვრელი წესებში.
API და webhook-ები — ხშირად დასმული კითხვები
პირდაპირი პასუხები
მეტი პასუხისთვის იხილეთ ხშირად დასმული კითხვები, ან გვკითხეთ პირდაპირ.
გულწრფელი ინტეგრაცია ხმაურიანს ჯობია.
აქ თითოეული ინტეგრაცია აღწერილია იმით, რასაც რეალურად აკეთებს — მიმართულებით, მფლობელობითა და შეზღუდვებით.