The DOEH POS Merchant API lets a shop's own software read and drive its delivery, loyalty, marketplace, and rider operations. Integrations authenticate with a merchant API key; the shop and branches a key may act on are derived server-side from the key.
DOEH POS Merchant API သည် ဆိုင်၏ ကိုယ်ပိုင် software ကို ၎င်း၏ delivery၊ loyalty၊ marketplace နှင့် rider လုပ်ငန်းများ ဖတ်ရှု၍ မောင်းနှင်နိုင်စေသည်။ integration များသည် merchant API key ဖြင့် authenticate လုပ်သည်။ key တစ်ခု ဆောင်ရွက်နိုင်သော ဆိုင်နှင့် branch များကို key မှ server ဘက်တွင် တွက်ချက်သည်။
A shop owner signs in to the portal, creates an app
(name it, choose scopes and branch access), and copies the secret — it is shown once.
Keys are sk_live_… or sk_test_…; see Authentication.
ဆိုင် ပိုင်ရှင် က portal သို့ sign in ဝင်ပြီး app တစ်ခု ဖန်တီး
(အမည်ပေး၊ scope နှင့် branch access ရွေး) ကာ secret ကို ကူးယူသည် — ၎င်းကို တစ်ကြိမ်သာ ပြသသည်။
Key များမှာ sk_live_… သို့မဟုတ် sk_test_…။ Authentication ကို ကြည့်ပါ။
Send the key as a bearer token against the base URL https://api.doehpos.com:
key ကို base URL https://api.doehpos.com သို့ bearer token အဖြစ် ပို့ပါ —
curl https://api.doehpos.com/v1/delivery/orders \
-H "Authorization: Bearer sk_live_<keyid>_<secret>"You send only the token — never X-Shop-Id or X-Branch-Id.
The request is allowed only if the operation's required scope is within the key's scope and the target
branch is within the key's branch policy; otherwise it is refused.
သင်သည် token တစ်ခုတည်း ကိုသာ ပို့သည် — X-Shop-Id သို့မဟုတ် X-Branch-Id ကို
ဘယ်တော့မှ မပို့ပါ။ operation ၏ လိုအပ်သော scope သည် key ၏ scope အတွင်း ရှိ၍ ပစ်မှတ် branch သည် key ၏ branch policy အတွင်း
ရှိမှသာ request ကို ခွင့်ပြုသည်။ မဟုတ်လျှင် ငြင်းပယ်သည်။
Add an Idempotency-Key header to every POST. Retrying with the same key
returns the original result instead of creating a duplicate — safe to retry on a network error.
POST တိုင်းတွင် Idempotency-Key header ထည့်ပါ။ key တူဖြင့် ပြန်ကြိုးစားလျှင် ထပ်နေသော
record အသစ် မဖန်တီးဘဲ မူရင်းရလဒ်ကို ပြန်ပေးသည် — network error ဖြစ်လျှင် ပြန်ကြိုးစားရန် ဘေးကင်းသည်။
Errors return a JSON body with a stable code (e.g. API_KEY_SCOPE_DENIED).
Branch on code, not on the message. Full list in the error reference.
Error များသည် တည်ငြိမ်သော code (ဥပမာ API_KEY_SCOPE_DENIED) ပါသည့် JSON body ပြန်ပေးသည်။
message အပေါ် မဟုတ်ဘဲ code အပေါ် အခွဲလုပ်ပါ။ စာရင်းအပြည့်အစုံကို error အကိုးအကား တွင်။
Limits are enforced at two layers and a request that exceeds either returns HTTP 429:
ကန့်သတ်ချက်များကို layer နှစ်ခုတွင် အကျိုးသက်ရောက်စေပြီး တစ်ခုခုကို ကျော်လွန်သော request သည် HTTP 429 ပြန်ပေးသည် —
On a 429, back off and retry with exponential backoff (e.g. 1s, 2s, 4s) plus jitter.
Treat these numbers as the current operating envelope; design clients to react to 429 rather
than to assume a fixed ceiling.
429 ရလျှင် နားပြီး exponential backoff (ဥပမာ 1s, 2s, 4s) နှင့် jitter ဖြင့် ပြန်ကြိုးစားပါ။
ဤဂဏန်းများကို လက်ရှိ လုပ်ဆောင်နိုင်သော အတိုင်းအတာအဖြစ် သဘောထားပါ — client များကို သတ်မှတ် အမြင့်ဆုံးဟု မယူဆဘဲ
429 ကို တုံ့ပြန်အောင် ဒီဇိုင်းဆွဲပါ။
Shop owners manage keys and apps in the portal. If you are integrating on a merchant's behalf, ask them to request a delegated developer account for you — you should never need their POS password. For integration support, contact your DOEH POS account manager through your shop's usual channel.
ဆိုင်ပိုင်ရှင်များသည် key နှင့် app များကို portal တွင် စီမံသည်။ merchant ကိုယ်စား integrate လုပ်နေလျှင် သင့်အတွက် လွှဲအပ်ထားသော developer account တစ်ခု တောင်းခံပေးရန် သူတို့အား ပြောပါ — သူတို့၏ POS စကားဝှက် လုံးဝ မလိုအပ်သင့်ပါ။ integration အကူအညီအတွက် သင့်ဆိုင်၏ ပုံမှန် ဆက်သွယ်ရေးလမ်းကြောင်းမှတစ်ဆင့် သင့် DOEH POS account manager ကို ဆက်သွယ်ပါ။