ConnectWiz + API ও Webhook

লাইভ ইন্টিগ্রেশন

যে API আমরা বিক্রি করি, নিজেরাও সেটাই ব্যবহার করি

পুরো প্ল্যাটফর্ম সংজ্ঞায়িত একটিই OpenAPI চুক্তিতে, আর আমাদের নিজেদের প্যানেল ও মোবাইল অ্যাপ তৈরি হয় সেখান থেকেই — কোনো লুকোনো endpoint নেই, ডকুমেন্টেশন আর বাস্তবের ফারাক নেই। তার ওপরে আছে: scope-সীমিত Commerce API কী, সুরক্ষিত webhook ট্রিগার, আর এমন ফ্লো, যা আপনার সিস্টেমকে কল করে।

একটিই OpenAPI চুক্তি scope-সীমিত API কী HMAC-যাচাই করা webhook
API ও Webhook × ConnectWiz
payload মানে ডেটা, কখনো নির্দেশ নয়
scope-সীমিত API কী: ক্যাটালগ পড়া · অর্ডার লেখা
Webhook → HMAC যাচাই → ফ্লো শুরু
ফ্লোর REST ধাপ আপনার API-কে কল করে
1
প্রামাণ্য OpenAPI চুক্তি — আমাদের নিজেদের প্যানেল ও মোবাইল অ্যাপ তৈরি হয় এই ফাইল থেকেই
3
Commerce scope — ক্যাটালগ পড়া, অর্ডার পড়া, অর্ডার লেখা — প্রতিটি API কী পায় আলাদাভাবে
100
প্রতিবার পড়ায় সর্বোচ্চ সারি, সার্ভারেই বেঁধে দেওয়া — limit প্যারামিটার যাচাই করা হয়, অন্ধভাবে মানা হয় না
50
API দিয়ে প্রতি অর্ডারে সর্বোচ্চ লাইন আইটেম — আগে থেকে ঘোষিত সীমা, ঠেকে শেখা নয়

ডেভেলপার

এটি ঠিক কী করে

একটিই প্রামাণ্য চুক্তি

একটিমাত্র OpenAPI 3 ডকুমেন্টে প্ল্যাটফর্মটি সংজ্ঞায়িত; আমাদের নিজেদের TypeScript ক্লায়েন্ট তৈরি হয় সেখান থেকেই — ডকুমেন্টেশন বাস্তব থেকে সরে যেতে পারে না, কারণ বাস্তবটাই গড়া হয় ডকুমেন্টেশন থেকে।

Commerce API কী

আপনার ওয়ার্কস্পেস থেকে ইস্যু করা, স্পষ্ট scope-সহ API কী — ক্যাটালগ পড়া, অর্ডার পড়া, অর্ডার লেখা — দিয়ে একই অর্ডার ইঞ্জিনের ওপর চালান আপনার নিজের স্টোরফ্রন্ট বা অ্যাপ; দাম সবসময় ঠিক হয় সার্ভারে।

ইনবাউন্ড webhook, সুরক্ষিত

প্রতিটি ফ্লোর webhook ট্রিগারের নিজস্ব URL ও secret আছে, কাঁচা body-র ওপর HMAC যাচাই আর রিপ্লে সুরক্ষা আছে। payload কোনো মানুষের নাম বলতে পারে; ফ্লোর ভেতরের কলকবজা কখনো চালাতে পারে না।

আউটবাউন্ড, ফ্লো দিয়ে

ক্যানভাসে আপনি যে মুহূর্তগুলো আঁকেন, REST ধাপ ঠিক তখনই আপনার সিস্টেমকে কল করে — অর্ডার দেওয়া হলো, সম্মতি মিলল, বুকিং হলো।

ভেতরের কলকবজা

API নকশার অবস্থান, স্পষ্ট করে বলা

দাম কখনো ক্লায়েন্ট থেকে আসে না

অর্ডারের রিকোয়েস্ট শুধু বলে কী আর কয়টি — নাম ও দাম সেই মুহূর্তে সার্ভারে ক্যাটালগ থেকে পড়া হয়, আর স্ন্যাপশট হিসেবে লাইনে লেখা হয়। কারসাজি করা রিকোয়েস্ট কোনো ছাড় বানিয়ে নিতে পারে না।

কল করার আগে সক্ষমতা

প্রতিটি ইন্টিগ্রেশনের জায়গা একটি সক্ষমতার চুক্তি প্রকাশ করে — ফোন নম্বর দিয়ে মেলাতে পারে কি? গেস্ট অর্ডারের তালিকা দিতে পারে? অর্ডার তৈরি করতে পারে? — আর ঘোষিত "না"-এর পরও কল করলে তখনই এরর আসে, ভেতরে কোথাও গিয়ে ব্যর্থ হওয়ার বদলে।

এমন এরর, যার মানে আছে

ট্রান্সপোর্ট স্তর "অনুমতি নেই" আর "সার্ভিস বন্ধ" আলাদা করে চেনে — তাই "শপের সঙ্গে যোগাযোগ করা যাচ্ছে না" কখনো "এই গ্রাহক কখনো কিছু কেনেননি" হয়ে দেখা দেয় না। নামওয়ালা এররই একটি API আর আন্দাজের খেলার মধ্যে তফাত গড়ে দেয়।

রিপ্লে-প্রতিরোধী webhook

প্রসেস হওয়ার আগে প্রতিটি ইনবাউন্ড ইভেন্ট একটি idempotency লেজারে নিজের অনন্য চাবি দাবি করে — আবার চেষ্টা করা বা রিপ্লে করা ডেলিভারি আটকে যায় ডেটাবেস স্তরেই, আপনার অটোমেশনে পৌঁছানোর আগে।

API কী হ্যাশ করা, secret-এর সীমা বাঁধা

API কী সংরক্ষিত থাকে হ্যাশ হিসেবে, আর দরজায় শুধু হ্যাশ ও scope-ই মেলানো যায় — ফাঁস হয়ে যাওয়া ডেটাবেসের কোনো সারি কোনো ওয়ার্কস্পেসের নাম বলে না, আর নিজের scope-এর বাইরে কিছুই খোলে না।

খসড়া আর নিশ্চিত অর্ডার আলাদা করে বলা

অর্ডার তৈরিতে স্পষ্ট একটি confirm প্যারামিটার লাগে — পাবলিক API-তে ডিফল্ট হলো নিশ্চিত, প্যানেলের ফ্লো খসড়া রেখে দিতে পারে — তাই "এটা কি আসল?" প্রশ্নের উত্তর একটি ফিল্ডে লেখা থাকে, রীতির ওপর নির্ভর করে না।

সেটআপ

যেভাবে যুক্ত হয়

01

একটি API কী ইস্যু করুন

প্যানেলে একটি scope-সীমিত Commerce API কী তৈরি করুন; বাতিলও করা যায় ঠিক ততটাই সহজে।

02

একটি webhook জুড়ে দিন

webhook ট্রিগারসহ একটি ফ্লো তৈরি করুন; রিকোয়েস্টগুলো সাইন করুন তার secret দিয়ে।

03

বাইরে কল পাঠান

যেখানে আপনার সিস্টেমের খবরটা জানা দরকার, সেখানে REST ধাপ যোগ করুন।

একসঙ্গে আরও ভালো

এটি কীসের সঙ্গে মিলে কাজ করে

Flows

Webhook ট্রিগার দিয়ে চালু হয় ফ্লো; আর REST ধাপ আপনার আঁকা মুহূর্তগুলোতে আপনার সিস্টেমকে কল করে — ইনবাউন্ড আর আউটবাউন্ড অটোমেশন চলে একই ক্যানভাসে।

কমার্স

আমাদের ক্যাটালগ ও অর্ডার ইঞ্জিন চলে API-র পেছনে, আর চ্যাট শপ ও AI-ও ব্যবহার করে ঠিক সেটিই — অর্ডারের সত্য একটিই, দরজা চারটি।

আপনার নিজের স্টোরফ্রন্ট

অনেক টিম আজই Commerce API দিয়ে headless স্টোরফ্রন্ট চালাচ্ছে — নেটিভ কানেক্টর তৈরি হওয়া পর্যন্ত Shopify পেজটি সৎভাবে এই পথটিরই সুপারিশ করে।

নিরাপত্তা ও নিশ্চয়তা

নীরস নিশ্চয়তাগুলো

কাঁচা body-র ওপর HMAC

Webhook যাচাইয়ে রিকোয়েস্টের কাঁচা body সাইন করা হয় প্রতিটি ট্রিগারের নিজস্ব secret দিয়ে, আর তুলনা হয় constant time-এ — পার্সিং হয় কেবল প্রমাণ মেলার পরে।

payload মানে ডেটা, কখনো নির্দেশ নয়

webhook payload কোনো মানুষের উল্লেখ করতে পারে; কিন্তু ফ্লোর ভেতরের কলকবজা চালাতে, প্রম্পট বদলে দিতে বা টুল চালু করতে কখনো পারে না। ডেটা আর নির্দেশের মধ্যের সীমারেখা স্থাপত্যে গাঁথা, আচরণের ওপর ছেড়ে দেওয়া নয়।

প্রতিটি দরজায় রেট লিমিট

পাবলিক endpoint চলে স্ট্যান্ডার্ড থ্রটলিংয়ে, আর পড়ার সীমা বেঁধে দেওয়া হয় সার্ভারেই — বেয়াড়া কোনো ক্লায়েন্ট নিজেরই গতি কমায়, প্ল্যাটফর্মের নয়।

খুঁটিনাটি, খোলাখুলি

সীমারেখা, স্পষ্ট করে বলা

সবকিছুর অবিরাম ফিড এখনো নেই

সবকিছুতে সাবস্ক্রাইব করার মতো সাধারণ কোনো webhook ফিড তৈরি হয়নি — আউটবাউন্ড ইভেন্ট আজ ঘটে ফ্লোর ধাপ দিয়ে। এখানে স্পষ্ট করে বলে রাখলাম, যাতে কোনো সেলস কলে উল্টোটা ইঙ্গিত করতে না হয়।

সীমিত পড়া, নকশা করেই

প্রতিবার পড়ায় কার্সরসহ সর্বোচ্চ 100টি সারি আসে — API বানানো হয়েছে দৈনন্দিন কাজের ইন্টিগ্রেশনের জন্য, বাল্ক এক্সপোর্টের জন্য নয়। বাল্কে দরকার হলে আমাদের সঙ্গে কথা বলুন; ফাঁকফোকর খুঁজবেন না।

API ও Webhook নিয়ে প্রশ্নোত্তর

সোজাসাপ্টা উত্তর

আরও জানতে দেখুন পুরো প্রশ্নোত্তর, অথবা সরাসরি আমাদের জিজ্ঞাসা করুন।

প্ল্যাটফর্মটি সংজ্ঞায়িত একটিই OpenAPI 3 চুক্তিতে — আমাদের ওয়েব প্যানেল আর মোবাইল অ্যাপ তাদের টাইপ তৈরি করে এই ফাইল থেকেই। আপনি যার সঙ্গে ইন্টিগ্রেট করেন, আমরা নিজেরাও চলি তার ওপরেই।

প্রতিটি ট্রিগারের আলাদা secret, কাঁচা body-র ওপর HMAC যাচাই, আর idempotency লেজারের মাধ্যমে রিপ্লে সুরক্ষা। আর নিয়ম হলো, payload মানে ডেটা: তা কোনো মানুষের উল্লেখ করতে পারে, অটোমেশনকে নির্দেশ দিতে পারে না।

পারে, ফ্লোর REST ধাপ দিয়ে — ক্যানভাসে আপনার বেছে নেওয়া মুহূর্তগুলোতে। সাধারণ একটি আউটগোয়িং webhook ফিড রোডম্যাপে আছে, আর চালু না হওয়া পর্যন্ত ইচ্ছে করেই তার প্রতিশ্রুতি দেওয়া হচ্ছে না।

হ্যাঁ — ক্যাটালগ পড়া আর অর্ডার লেখাই সমর্থিত পথ; দাম ঠিক হয় সার্ভারে, আর scope-সীমিত API কী প্রতিটি জায়গার জন্য আলাদাভাবে বাতিল করা যায়। 50 লাইন আর 100 সারির সীমা আগেই বলে রাখা, যাতে সেগুলোয় হোঁচট না খেয়ে আপনি সেই মাপেই নকশা করতে পারেন।

আমাদের দিকে ডেলিভারি idempotent — লেজার রিপ্লে চিনে ফেলে বাদ দেয়, তাই আপনার সিস্টেম নিশ্চিন্তে আবার পাঠাতে পারে। ফ্লো থেকে বাইরে যাওয়া REST ধাপের নিজস্ব রিট্রাই নীতি আছে, আর ব্যর্থতা দেখা যায় ফ্লো রানেই।

ঢাকঢোল পিটিয়ে নয়, সৎভাবে যুক্ত হওয়াই ভালো।

এখানে প্রতিটি ইন্টিগ্রেশনের বর্ণনা দেওয়া হয়েছে সেটি আসলে যা করে তা দিয়েই — ডেটা কোন দিকে যায়, মালিকানা কার আর সীমাবদ্ধতা কী, সবসহ।