ConnectWiz + API & Webhooks
အသုံးပြုနိုင်ပြီးသား ချိတ်ဆက်မှုကျွန်ုပ်တို့ ရောင်းသော API သည် ကျွန်ုပ်တို့ ကိုယ်တိုင်သုံးသော API ဖြစ်သည်
ပလက်ဖောင်း တစ်ခုလုံးကို OpenAPI သတ်မှတ်ချက် တစ်ခုတည်းဖြင့် ဖော်ပြထားပြီး ကျွန်ုပ်တို့၏ panel နှင့် မိုဘိုင်းအက်ပ်ကိုလည်း ၎င်းမှပင် generate လုပ်ထားသည် — လျှို့ဝှက် endpoint မရှိ၊ docs နှင့် လက်တွေ့ ကွဲလွဲမှု မရှိ။ ၎င်းအပေါ်တွင်: scope သတ်မှတ်ထားသော Commerce API key များ၊ လုံခြုံသော webhook trigger များနှင့် သင့်စနစ်များကို ခေါ်ဆိုသော flow များ။
Developer များ
လုပ်ဆောင်ပေးသည့်အရာ — အတိအကျ
တရားဝင် သတ်မှတ်ချက် တစ်ခုတည်း
OpenAPI 3 စာတမ်း တစ်ခုတည်းက ပလက်ဖောင်းကို သတ်မှတ်ပြီး ကျွန်ုပ်တို့၏ TypeScript client များကို ၎င်းမှ generate လုပ်သည် — လက်တွေ့ကို docs မှ တည်ဆောက်ထားသဖြင့် docs သည် လက်တွေ့နှင့် ကွဲလွဲ၍ မရပါ။
Commerce API key များ
Tenant က ထုတ်ပေးပြီး scope ကို တိတိကျကျ သတ်မှတ်ထားသော key များ — ကတ်တလောက် ဖတ်ခွင့်၊ အော်ဒါ ဖတ်ခွင့်၊ အော်ဒါ ရေးခွင့် — ဖြင့် သင့်ကိုယ်ပိုင် storefront သို့မဟုတ် app ကို အော်ဒါ engine တစ်ခုတည်းပေါ်တွင် လည်ပတ်စေနိုင်ပြီး ဈေးနှုန်းကို server ဘက်တွင်သာ အမြဲ တွက်ချက်သည်။
လုံခြုံသော inbound webhook များ
Flow webhook trigger တိုင်းတွင် ကိုယ်ပိုင် URL နှင့် secret၊ raw body ပေါ်တွင် HMAC စစ်ဆေးခြင်းနှင့် replay ကာကွယ်မှု ရှိသည်။ Payload တစ်ခုက လူတစ်ဦးကို ညွှန်းဆိုနိုင်သော်လည်း flow ၏ အတွင်းပိုင်းကို မည်သည့်အခါမျှ ထိန်းချုပ်၍ မရပါ။
Flow များမှတစ်ဆင့် အပြင်သို့
REST အဆင့်သည် canvas ပေါ်တွင် သင်ဆွဲထားသည့် အချိန်အခိုက်အတန့်များတွင် အတိအကျ သင့်စနစ်များကို ခေါ်သည် — အော်ဒါ တင်သည့်အခါ၊ သဘောတူခွင့်ပြုချက် ပေးသည့်အခါ၊ ရက်ချိန်း ယူသည့်အခါ။
နည်းပညာပိုင်း
API ဒီဇိုင်းဆိုင်ရာ ရပ်တည်ချက်များ — ရှင်းရှင်းလင်းလင်း
ဈေးနှုန်းကို client ထံမှ မည်သည့်အခါမျှ မယူ
အော်ဒါ တောင်းဆိုချက်တွင် ဘာကို ဘယ်နှခု ဆိုသည်ကိုသာ ဖော်ပြသည် — အမည်နှင့် ဈေးနှုန်းကို ထိုအချိန်၌ server ဘက်တွင် ကတ်တလောက်မှ ဖတ်ယူပြီး line ပေါ်တွင် snapshot အဖြစ် ရေးမှတ်သည်။ ပြင်ဆင်ထားသော တောင်းဆိုချက်က လျှော့ဈေးကို တီထွင်၍ မရပါ။
မခေါ်မီ စွမ်းဆောင်ရည်ကို ကြေညာသည်
ချိတ်ဆက်မှု မျက်နှာပြင်တိုင်းသည် စွမ်းဆောင်ရည် သတ်မှတ်ချက်ကို ထုတ်ပြန်ထားသည် — ဖုန်းနံပါတ်ဖြင့် ကိုက်ညီအောင် ရှာနိုင်သလား၊ guest အော်ဒါများကို စာရင်းပြနိုင်သလား၊ အော်ဒါ ဖန်တီးနိုင်သလား — ကြေညာထားသော "မရ" ကို ကျော်၍ ခေါ်လျှင် တစ်နေရာရာတွင် နက်နက်ရှိုင်းရှိုင်း ပျက်မည့်အစား ချက်ချင်း error ပြသည်။
အဓိပ္ပာယ်ရှိသော error များ
Transport အလွှာသည် "ခွင့်ပြုချက်မရှိ" နှင့် "ဝန်ဆောင်မှု ရပ်နေသည်" ကို ခွဲခြားသည် — ထို့ကြောင့် "ဆိုင်ကို ဆက်သွယ်၍ မရ" ကို "ဤဖောက်သည် ဘာမျှ မဝယ်ဖူး" ဟု မည်သည့်အခါမျှ မပြပါ။ အမည်တပ်ထားသော error များသည် API တစ်ခုနှင့် ခန့်မှန်းကစားရသည့် ဂိမ်းကို ခွဲခြားပေးသည်။
Replay ကို ခံနိုင်သော webhook များ
ဝင်လာသော event တိုင်းသည် မလုပ်ဆောင်မီ idempotency လယ်ဂျာတွင် တစ်မူထူးသော key တစ်ခုကို ရယူသည် — ထပ်ပို့သော သို့မဟုတ် replay လုပ်သော delivery သည် သင့် automation ထဲတွင် မဟုတ်ဘဲ database အလွှာတွင်ပင် ပျက်သွားသည်။
Key များကို hash လုပ်ထားသည်၊ secret များကို scope ဖြင့် ကန့်သတ်ထားသည်
API key များကို hash အဖြစ် သိမ်းဆည်းထားပြီး ဝင်ပေါက်တွင် hash နှင့် scope များကိုသာ ဖော်ထုတ်နိုင်သည် — ပေါက်ကြားသွားသော database row တစ်ခုသည် မည်သည့် workspace ကိုမျှ မဖော်ပြဘဲ ၎င်း၏ scope ထက်ပို၍ ဘာမျှ မဖွင့်ပေးနိုင်ပါ။
မူကြမ်းနှင့် အတည်ပြုချက်ကို ရှင်းလင်းစွာ ခွဲခြားထားသည်
အော်ဒါ ဖန်တီးရာတွင် confirm parameter ကို တိတိကျကျ ထည့်ရသည် — public API ၏ မူလတန်ဖိုးမှာ အတည်ပြုပြီး ဖြစ်ပြီး panel flow များက မူကြမ်းအဖြစ် ထားနိုင်သည် — ထို့ကြောင့် "ဤအော်ဒါ အစစ်လား" ဆိုသည်မှာ ဓလေ့ထုံးစံ မဟုတ်ဘဲ field တစ်ခု ဖြစ်သည်။
တပ်ဆင်ခြင်း
ချိတ်ဆက်ပုံ
Key တစ်ခု ထုတ်ပါ
Panel တွင် scope ပါသော Commerce API key တစ်ခု ဖန်တီးပါ။ ပြန်ရုပ်သိမ်းရန်လည်း ထိုမျှ လွယ်ကူသည်။
Webhook တစ်ခု ချိတ်ပါ
Webhook trigger ပါသော flow တစ်ခု ဖန်တီးပါ။ တောင်းဆိုချက်များကို ၎င်း၏ secret ဖြင့် လက်မှတ်ထိုးပါ။
အပြင်သို့ ပြန်ခေါ်ပါ
သင့်စနစ်များ သိရှိရန် လိုအပ်သည့် နေရာများတွင် REST အဆင့်များ ထည့်ပါ။
တွဲသုံးလျှင် ပိုကောင်း
တွဲဖက်အလုပ်လုပ်နိုင်သည့် အရာများ
Flows
Webhook trigger များက flow များကို စတင်ပေးသည်။ REST အဆင့်များက သင်ဆွဲထားသည့် အချိန်အခိုက်အတန့်များတွင် သင့်စနစ်များကို ပြန်ခေါ်သည် — အဝင်နှင့် အထွက် automation တို့ canvas တစ်ခုတည်းကို မျှသုံးသည်။
Commerce
ConnectWiz ၏ ကတ်တလောက်နှင့် အော်ဒါ စနစ် ဖြစ်သည် — API ၏ နောက်ကွယ်တွင် ရှိသော ဤစနစ်ကိုပင် chat ဆိုင်နှင့် AI တို့ကလည်း သုံးသည်။ အော်ဒါ အမှန်တရား တစ်ခု၊ တံခါး လေးပေါက်။
သင့်ကိုယ်ပိုင် storefront
အဖွဲ့များသည် ယနေ့ပင် Commerce API ပေါ်တွင် headless storefront များကို လည်ပတ်နေကြသည် — native connector ကို တည်ဆောက်နေစဉ် ဤလမ်းကြောင်းကို ရိုးသားစွာ အကြံပြုထားသည့် နေရာမှာ Shopify စာမျက်နှာ ဖြစ်သည်။
လုံခြုံရေးနှင့် အာမခံချက်များ
ပျင်းစရာကောင်းလောက်အောင် ခိုင်မာသော အာမခံချက်များ
Raw body ပေါ်တွင် HMAC
Webhook စစ်ဆေးမှုသည် raw request body ကို trigger တစ်ခုချင်း၏ secret ဖြင့် လက်မှတ်ထိုးပြီး constant time ဖြင့် နှိုင်းယှဉ်သည် — သက်သေပြပြီးမှသာ parse လုပ်သည်။
Payload များသည် ဒေတာသာ ဖြစ်သည်၊ ညွှန်ကြားချက် မည်သည့်အခါမျှ မဟုတ်
Webhook payload တစ်ခုက လူတစ်ဦးကို ရည်ညွှန်းနိုင်သော်လည်း flow ၏ အတွင်းပိုင်းကို ထိန်းချုပ်ခြင်း၊ prompt များကို ပြန်ရေးခြင်း သို့မဟုတ် tool များကို ခေါ်ခြင်း မည်သည့်အခါမျှ မပြုနိုင်ပါ။ ဒေတာနှင့် ညွှန်ကြားချက်ကြား နယ်နိမိတ်သည် အပြုအမူအပေါ် မူတည်ခြင်း မဟုတ်ဘဲ ဗိသုကာပိုင်းအရ သတ်မှတ်ထားခြင်း ဖြစ်သည်။
ဝင်ပေါက်တိုင်းတွင် rate limit
Public endpoint များတွင် ပုံမှန် throttling ရှိပြီး ဖတ်ယူမှု ကန့်သတ်ချက်များကို server ဘက်တွင် ချုပ်ထားသည် — မှားယွင်းစွာ ပြုမူသော client သည် ပလက်ဖောင်းကို မဟုတ်ဘဲ ၎င်းကိုယ်တိုင်ကိုသာ နှေးစေသည်။
မဖုံးကွယ်ထားသော အသေးစိတ်များ
ရှင်းလင်းစွာ ဖော်ပြထားသော ကန့်သတ်ချက်များ
Firehose မရှိသေး
အရာအားလုံးကို subscribe လုပ်နိုင်သော ယေဘုယျ webhook feed ကို မတည်ဆောက်ရသေးပါ — ယနေ့ အထွက် event များကို flow အဆင့်များမှတစ်ဆင့်သာ ပို့သည်။ အရောင်းဆွေးနွေးပွဲ တစ်ခုခုက တမျိုး ဆိုလိုစရာ မလိုစေရန် ဤနေရာတွင် ဖော်ပြထားသည်။
ဒီဇိုင်းအရပင် ကန့်သတ်ထားသော ဖတ်ယူမှု
ဖတ်ယူမှု တစ်ကြိမ်လျှင် cursor ဖြင့် row ၁၀၀ ခုအထိ ပြန်ပေးသည် — API ကို အစုလိုက် export အတွက် မဟုတ်ဘဲ လုပ်ငန်းလည်ပတ်မှုဆိုင်ရာ ချိတ်ဆက်မှုအတွက် တည်ဆောက်ထားသည်။ အစုလိုက် လိုအပ်ချက်ရှိလျှင် ကွက်လပ်ရှာစရာ မဟုတ်ဘဲ ဆွေးနွေးရမည့်ကိစ္စ ဖြစ်သည်။
API & Webhooks FAQ
တိုက်ရိုက်အဖြေများ
နောက်ထပ်အချက်များကို အပြည့်အစုံပါသော FAQ တွင် ဖတ်ပါ၊ သို့မဟုတ် ကျွန်ုပ်တို့ကို တိုက်ရိုက်မေးပါ။
ရိုးသားစွာ ချိတ်ဆက်ခြင်းသည် ကျယ်လောင်စွာ ကြွေးကြော်ခြင်းထက် သာသည်။
ဤနေရာရှိ ချိတ်ဆက်မှုတိုင်းကို ၎င်းတကယ်လုပ်ဆောင်သည့်အတိုင်း ဖော်ပြထားသည် — ဒေတာသွားရာ ဦးတည်ချက်၊ ပိုင်ဆိုင်မှုနှင့် ကန့်သတ်ချက်များ အပါအဝင်။