Webhook (အထွက်)

Webhook သည် ပေါင်းစပ်မှု၏ «တွန်းပို့» ဘက်ခြမ်းဖြစ်သည်။ သင့်စနစ်က FreeMaint ကို ထပ်ခါထပ်ခါမေးမည့်အစား၊ တစ်စုံတစ်ရာဖြစ်ပေါ်သည်နှင့် FreeMaint မှ သင့် URL သို့ POST ပို့ပေးသည်။ ကုမ္ပဏီဆက်တင်များ > Webhook (/company-settings/webhooks) တွင် ပြင်ဆင်ပါ။ Starter အစီအစဉ်မှစ၍ ရရှိနိုင်သည် (တစ်ရက်လျှင် ပို့ဆောင်မှု ၁၀၀ ကြိမ်၊ Business နှင့်အထက်တွင် အကန့်အသတ်မရှိ)။

ရရှိနိုင်သော ဖြစ်ရပ်များ

• work_order.created — လုပ်ငန်းအမိန့်တစ်ခု ဖန်တီးပြီး
• work_order.completed — လုပ်ငန်းအမိန့်တစ်ခု «ပြီးဆုံး» သို့ ပြောင်းပြီး
• work_order.status_changed — လုပ်ငန်းအမိန့်တစ်ခု အခြေအနေတစ်ခုခုသို့ ပြောင်းသွားပြီ။ payload တွင် new_status ပါဝင်သည်။ မပြောင်းလဲသော work_order.completed နှင့်အတူ တွဲ၍ ထွက်သည်
• request.created — ပြုပြင်ထိန်းသိမ်းရေး တောင်းဆိုချက်တစ်ခု တင်သွင်းပြီး
• request.status_changed — တောင်းဆိုချက်တစ်ခု အတည်ပြု၊ ငြင်းပယ် သို့မဟုတ် ပယ်ဖျက်ခံရ
• part.low_stock — အပိုပစ္စည်းတစ်ခု ပြန်လည်မှာယူမည့်အဆင့် သို့မဟုတ် အောက်သို့ ကျဆင်း
• part.out_of_stock — အပိုပစ္စည်းတစ်ခု သုည သို့ ကျဆင်း
• part.low_stock_summary — ကုမ္ပဏီတစ်ခုလျှင် တစ်ရက်တစ်ကြိမ် အကျဉ်းချုပ်။ ပြန်လည်မှာယူမည့်အဆင့် သို့မဟုတ် အောက်တွင်ရှိသော အပိုပစ္စည်းများကို — တစ်ခါမျှ မလှုပ်ရှားခဲ့သည်များပါ — စာရင်းပြုစုသည်
• part.out_of_stock_summary — သုညတွင်ရှိနေသော အပိုပစ္စည်းများအတွက် ထိုနေ့စဉ်အကျဉ်းချုပ်အတိုင်းပင်
• part.consumed — အပိုပစ္စည်းတစ်ခုကို လုပ်ငန်းအမိန့်တွင် သုံးစွဲ သို့မဟုတ် ပြန်အပ်
• compliance.chain_divergence — စာရင်းစစ် hash ကွင်းဆက် ပြတ်တောက် (Enterprise)
• asset.downtime_started — စက်ရပ်နားမှုတစ်ခု စတင်မှတ်တမ်းတင်ပြီ
• asset.downtime_ended — စက်ရပ်နားမှုတစ်ခု ပိတ်သိမ်းပြီ။ ကြာချိန်ကို ယခု တွက်ချက်နိုင်ပြီ
• report.daily_summary — ထိုနေ့၏ ပြီးစီးခဲ့သော လုပ်ငန်းများကို သင်ရွေးချယ်ထားသည့် အချိန်တွင် တစ်ရက်တစ်ကြိမ်
• purchase_order.created — ဝယ်ယူမှုအမိန့်တစ်ခု ဖန်တီးလိုက်သည်။ payload တွင် အမိန့် (reference၊ status၊ total_cost၊ currency၊ expected_date၊ erp_reference) နှင့် ၎င်း၏ ပေးသွင်းသူ ပါဝင်သည်
• purchase_order.status_changed — ဝယ်ယူမှုအမိန့်တစ်ခု၏ status ပြောင်းသွားသည် (အတည်ပြု၊ မှာယူပြီး၊ ပယ်ဖျက်…)။ payload တွင် previous_status နှင့် new_status ပါဝင်သည်
• purchase_order.received — ဝယ်ယူမှုအမိန့်တစ်ခုအတွက် ပို့ဆောင်မှုတစ်ခုကို လက်ခံရရှိပြီး (တစ်စိတ်တစ်ပိုင်းအပါအဝင် ပို့ဆောင်မှုတိုင်းတွင် ပို့သည်)။ payload တွင် စာကြောင်းတိုင်းကို quantity_ordered၊ quantity_received (ဤပို့ဆောင်မှု)၊ quantity_received_total နှင့် quantity_remaining ဖြင့် စာရင်းပြုစုထားပြီး receipt_id၊ fully_received နှင့် closed_short လည်း ပါဝင်သည်။ ကုန်ပစ္စည်း မျှော်လင့်နေဆဲ ကာလတွင် new_status သည် PARTIALLY_RECEIVED ဖြစ်ပြီး ပြည့်စုံသည် သို့မဟုတ် ပိတ်လိုက်သည့်အခါ RECEIVED ဖြစ်သည်

part.consumed — ကုန်လက်ကျန်ကို ERP သို့ ထင်ဟပ်ခြင်း

အခြားစနစ်တစ်ခု (ERP၊ ငွေတောင်းခံ၊ ကုန်လက်ကျန်၊ စာရင်းကိုင်) က ပြုပြင်ထိန်းသိမ်းရေးတွင် အမှန်တကယ်သုံးစွဲခဲ့သည်ကို ထင်ဟပ်ရန်လိုအပ်သည့်အခါ စာရင်းသွင်းရမည့် ဖြစ်ရပ်ဖြစ်သည်။ quantity တွင် အမှတ်အသားပါသည် — အပိုပစ္စည်းကို လုပ်ငန်းသို့ ထုတ်ပေးသောအခါ အနုတ်၊ လုပ်ငန်းအမိန့်မှ ဖယ်ရှား၍ ပြန်အပ်သောအခါ အပေါင်း။ သို့ဖြင့် FreeMaint တွင် ပြန်ဖျက်လျှင် တစ်ဖက်စနစ်တွင် ကိုက်ညီသော ပြန်အပ်စာရွက်စာတမ်း ဖြစ်ပေါ်လာသည်။ stock_movement_id သည် ပြန်လည်ကြိုးစားမှုနှင့် ပြန်ပို့မှုများအကြား မပြောင်းလဲပါ — ၎င်းကို idempotency သော့အဖြစ် သုံးပါက တူညီသောထုတ်ယူမှုကို နှစ်ကြိမ်မှတ်တမ်းတင်မိမည် မဟုတ်ပါ။ အချက်အလက်များ နှစ်ဖက်စလုံး စီးဆင်းသည့်အခါ သိထားရမည့်အချက်တစ်ခုမှာ — GraphQL ၏ adjustStock mutation သည် ဤဖြစ်ရပ်ကို မဖြစ်ပေါ်စေပါ။ ဤသည်မှာ ရည်ရွယ်ချက်ရှိရှိ ဖြစ်သည် — သင့်စနစ်ကိုယ်တိုင် FreeMaint သို့ ရေးသွင်းသည့် စတော့ပြင်ဆင်မှုသည် ပဲ့တင်သံအဖြစ် သင့်ထံ ပြန်ရောက်လာပြီး နှစ်ကြိမ် မှတ်တမ်းတင်ခြင်း မဖြစ်စေရန်ဖြစ်သည်။ FreeMaint အတွင်း လုပ်ငန်းအမိန့်တွင် မှတ်တမ်းတင်ထားသော သုံးစွဲမှုမှသာ part.consumed ဖြစ်ပေါ်သည်။ အပိုပစ္စည်းတွင် custom_reference လည်း ပါဝင်သည် — ၎င်းအတွက် သင့်ကိုယ်ပိုင်ကုဒ်ဖြစ်ပြီး createPart သို့မဟုတ် updatePart ဖြင့် သတ်မှတ်ထားသော customReference ဖြစ်သည်၊ ထို့ကြောင့် ကတ်တလောက်ကို စီမံသည့်စနစ်သည် FreeMaint ID ဇယားမထားဘဲ စာကြောင်းတိုင်းကို တိုက်ဆိုင်နိုင်သည်။

{ "event": "part.consumed", "timestamp": "2026-08-19T21:04:11.000Z", "data": { "part": { "id": 812, "name": "ဘယ်ရင် 6204", "part_number": "RLM-204", "reference": "PART-812", "custom_reference": "BC-10045", "unit_cost": 12.5, "unit_of_measure": "ခု" }, "quantity": -2, "previous_quantity": 48, "new_quantity": 46, "work_order": { "id": 5521, "reference": "WO-2026-0412", "title": "ဘယ်ရင် အစားထိုးခြင်း" }, "asset": { "id": 91, "name": "ခွဲထုတ်စက် ၂" }, "location": { "id": 7, "name": "စက်ရုံဂိုဒေါင်" }, "user": { "id": 5627, "name": "အေ. နည်းပညာရှင်" }, "stock_movement_id": 88213, "occurred_at": "2026-08-19T21:04:11.000Z" } }

ပို့ဆောင်ခြင်းနှင့် လက်မှတ်

ပို့ဆောင်မှုတိုင်းသည် JSON ကိုယ်ထည်ပါသော POST ဖြစ်ပြီး t=<unix စက္ကန့်>,v1=<hex> ပုံစံဖြင့် X-FreeMaint-Signature ခေါင်းစီး ပါဝင်သည်။ v1 သည် သင့် webhook လျှို့ဝှက်ချက်ကို သော့အဖြစ်သုံး၍ «<t>.<ကုန်ကြမ်းကိုယ်ထည်>» စာကြောင်း၏ HMAC-SHA256 ဖြစ်သည်။ JSON ခွဲခြမ်းခြင်း သို့မဟုတ် ပြန်လည်စီစဉ်ခြင်းမပြုမီ ကုန်ကြမ်းကိုယ်ထည်နှင့် တိုက်ဆိုင်စစ်ဆေးပါ။ X-FreeMaint-Event နှင့် X-FreeMaint-Delivery-Id ကိုလည်း ပို့ပါသည်။ 2xx ဆိုလျှင် ပို့ဆောင်အောင်မြင်သည်ဟု သတ်မှတ်သည်။ ကွန်ရက်အမှားများနှင့် 5xx ကို ထပ်ကိန်းနောက်ဆုတ်နည်းဖြင့် ၃ ကြိမ်အထိ ပြန်ကြိုးစားသည် (ခန့်မှန်း ၂ စက္ကန့်၊ ၄ စက္ကန့်၊ ၈ စက္ကန့်)။ 4xx ကို အပြီးအပိုင် ငြင်းပယ်မှုအဖြစ် သတ်မှတ်ပြီး ပြန်မကြိုးစားပါ။

ပို့ဆောင်မှုတစ်ခုကို ပြန်ပို့ခြင်း

ကြိုးစားမှုတိုင်းကို webhook ၏ ပို့ဆောင်မှုမှတ်တမ်းတွင် အခြေအနေနှင့် တုံ့ပြန်မှုကုဒ်နှင့်အတူ သိမ်းဆည်းထားသည်။ ပြီးဆုံးသွားသော ပို့ဆောင်မှုမှန်သမျှကို ထိုနေရာမှ ပြန်ပို့နိုင်သည် — သိမ်းဆည်းထားသော အချက်အလက်အတိအကျ ပြန်ထွက်သွားသဖြင့် ၎င်းအတွင်းရှိ လုပ်ငန်းသော့များ (stock_movement_id အပါအဝင်) မပြောင်းလဲဘဲ၊ မှန်ကန်စွာ ထပ်နေမှုဖယ်ရှားသည့် လက်ခံသူသည် နှစ်ကြိမ်မှတ်တမ်းတင်မည် မဟုတ်ပါ။ သင့် endpoint ရပ်နေချိန် သို့မဟုတ် မှားယွင်း၍ ငြင်းပယ်ခဲ့ချိန်တွင် ဤနည်းဖြင့် ပြန်လည်ဖြည့်ဆည်းပါ။

ဓာတ်ပုံများ (ရွေးချယ်နိုင်)

Webhook တစ်ခုတွင် "ဓာတ်ပုံများ ထည့်သွင်းရန်" ဖွင့်ထားပါက (မူလအနေဖြင့် ပိတ်ထား) "work_order" နှင့် "request" object များတွင် "photos" စာရင်း ပါဝင်ပါမည် — JPG၊ PNG၊ GIF သို့မဟုတ် WebP ပုံများသို့ HTTPS လင့်ခ် 4 ခုအထိ၊ အသစ်ဆုံးကို ဦးစွာ။ လင့်ခ်တစ်ခုစီသည် 7 ရက်ကြာ အကောင့်ဝင်ရန်မလိုဘဲ ပုံကို ဖွင့်ပေးသောကြောင့် ပိုကြာကြာ လိုအပ်ပါက ဖိုင်ကို သင့်ဘက်တွင် သိမ်းထားပါ။ ပြန်ပို့ခြင်းသည် တူညီသော လင့်ခ်များကို ပို့ပါသည်။ အခြားဖြစ်ရပ်များနှင့် အခြား Webhook များ မပြောင်းလဲပါ။ "work_order.created" နှင့် "request.created" အတွက် "ဓာတ်ပုံများ ထည့်သွင်းရန်" ဖွင့်ထားသော Webhook ကို ဖြစ်ရပ်ပြီး 90 စက္ကန့်အကြာတွင် ပို့ပါသည် ("timestamp" အကွက်တွင် ဖြစ်ရပ်အချိန်ကို ထားရှိသည်)၊ မှတ်တမ်းဖန်တီးပြီး ချက်ချင်းတင်လိုက်သော ဓာတ်ပုံများလည်း ပါဝင်စေရန်ဖြစ်သည်။

URL လိုအပ်ချက်များ

• https:// သာ — သာမန် http ကို ငြင်းပယ်သည်
• ပို့တ် 443 သို့မဟုတ် 8443 သာ
• Host သည် အများပြည်သူ ဆက်သွယ်နိုင်ရမည် — loopback၊ သီးသန့်နှင့် CGNAT အပိုင်းအခြားများကို ငြင်းပယ်သည်
• URL အတွင်း အထောက်အထားများ မထည့်ရ (https://user:pass@host ကို ငြင်းပယ်သည်)
• သင့်ကွန်ရက်အတွင်း၌သာ တည်ရှိသော စနစ်အတွက် အများပြည်သူသုံး endpoint သို့မဟုတ် ဆက်သွယ်ပေးသူ (n8n၊ Make၊ Zapier) တစ်ခု ရှေ့တွင် လိုအပ်သည်

ကန့်သတ်ချက်များ

• Starter — ကုမ္ပဏီတစ်ခုလျှင် တစ်ရက် ပို့ဆောင်မှု ၁၀၀
• Business — အကန့်အသတ်မရှိ
• Enterprise — အကန့်အသတ်မရှိ
• ရေတွက်မှုသည် ပို့ဆောင်ကြိုးစားမှုအလိုက် — ဖြစ်ရပ်တူတွင် စာရင်းသွင်းထားသော webhook သုံးခုသည် ယူနစ်သုံးခု သုံးစွဲသည်
• နေ့စဉ်ရေတွက်မှုကို 00:00 UTC တွင် ပြန်လည်သုညပြုသည်