ওয়েবহুক কী? অ্যাপ একে অপরকে কীভাবে জানায়

ওয়েবহুক হলো একটি স্বয়ংক্রিয় বার্তা, যা একটি সেবা কিছু ঘটার মুহূর্তেই আপনার অ্যাপে পাঠায়। যখন কোনো গ্রাহকের পেমেন্ট সফল হয়, Stripe আপনার অ্যাপের একটি ঠিকানায় ওয়েবহুক পাঠায় যে বলছে “পেমেন্ট সফল হয়েছে, বিবরণ এই”, এবং আপনার অ্যাপ সাড়া দেয় — অর্ডার পেইড চিহ্নিত করে, রসিদ পাঠায়, অ্যাকাউন্ট খুলে দেয়। সংক্ষেপে: API হলো আপনার অ্যাপের অন্য সেবাকে প্রশ্ন করা; ওয়েবহুক হলো অন্য সেবার আপনার অ্যাপকে কিছু জানাতে কল করা।

AI দিয়ে তৈরির সময় কেন এটি গুরুত্বপূর্ণ

আপনার অ্যাপ পেমেন্ট নিলে, অন্য টুল থেকে ফর্ম জমা নিলে, বা GitHub, Shopify বা ক্যালেন্ডারের মতো সেবার সঙ্গে সংযুক্ত হলেই আপনি ওয়েবহুকের মুখোমুখি হবেন। কিছু ঘটেছে তা জানার এগুলো সাধারণত সঠিক উপায় — কিন্তু AI দিয়ে বানানো অ্যাপে এখানেই প্রায়ই সূক্ষ্ম ভুল থাকে:

• এন্ডপয়েন্ট যেকোনো অনুরোধ গ্রহণ করে, তাই কেউ নকল “পেমেন্ট সফল” ইভেন্ট পাঠাতে পারে।
• অ্যাপ ওয়েবহুকের বদলে চেকআউটের রিডাইরেক্ট পেজে অ্যাক্সেস দেয়, ফলে যারা আগে ট্যাব বন্ধ করে তারা যা কিনেছে তা পায় না, আর যারা সাফল্যের URL খুঁজে পায় তারা বিনামূল্যে পায়।
• একই ইভেন্ট দুবার আসে এবং গ্রাহক দুটি অর্ডার বা দুটি ইমেইল পায়।

ওয়েবহুক কীভাবে কাজ করে জানলে আপনি আগেভাগেই এই সুরক্ষাগুলো চাইতে পারেন।

একটি দৈনন্দিন উদাহরণ: ডেলিভারি বার্তা

আপনার পার্সেল পৌঁছেছে কি না জানার দুটি উপায় আছে। আপনি প্রতি দশ মিনিটে দরজা পর্যন্ত হেঁটে গিয়ে দেখতে পারেন (এটি পোলিং — আপনার অ্যাপ বারবার একটি API-কে জিজ্ঞেস করে “নতুন কিছু আছে?”)। অথবা কুরিয়ার পৌঁছানোর পর আপনাকে বার্তা পাঠাতে পারে (এটি একটি ওয়েবহুক)।

বার্তাটি স্পষ্টতই ভালো — যতক্ষণ আপনি এতে ভরসা রাখতে পারেন। যদি যে কেউ “পার্সেল পৌঁছেছে” বার্তা পাঠাতে পারত, তবে আপনি জানতে চাইতেন এটি সত্যিই কুরিয়ারের কাছ থেকে এসেছে কি না। আর বার্তা আসার সময় ফোন বন্ধ থাকলে চাইতেন কুরিয়ার পরে আবার চেষ্টা করুক। এই দুটি বিষয় — যাচাই ও পুনরায় চেষ্টা — ওয়েবহুককে জটিল করার বেশিরভাগ কারণ।

ওয়েবহুক ধাপে ধাপে কীভাবে কাজ করে

1. আপনি একটি এন্ডপয়েন্ট তৈরি করেন আপনার অ্যাপের ব্যাকএন্ডে: একটি URL, যেমন https://yourapp.com/webhooks/stripe, যা POST অনুরোধ গ্রহণ করে।
2. আপনি প্রোভাইডারের কাছে সেই URL নিবন্ধন করেন এবং কোন ইভেন্টগুলো চান তা বেছে নেন (যেমন “checkout completed” ও “subscription cancelled”)।
3. প্রোভাইডার একটি সাইনিং সিক্রেট দেয়। এটি আপনার সার্ভারে একটি সিক্রেট হিসেবে সংরক্ষণ করেন — দেখুন এনভায়রনমেন্ট ভেরিয়েবল ও সিক্রেট।
4. একটি ইভেন্ট ঘটে। প্রোভাইডার আপনার URL-এ একটি HTTP অনুরোধ পাঠায়, যার JSON বডিতে ঘটনার বিবরণ এবং একটি স্বাক্ষর হেডার থাকে।
5. আপনার অ্যাপ স্বাক্ষর যাচাই করে, ইভেন্ট ID রেকর্ড করে, দ্রুত সফল কোড (200) ফেরত দেয়, এবং তারপর কাজ করে।
6. যদি আপনার অ্যাপ সফল উত্তর না দেয়, অনেক প্রোভাইডার পরে আবার চেষ্টা করে।

স্বাক্ষর

স্বাক্ষর প্রমাণ করে অনুরোধটি প্রোভাইডার থেকে এসেছে এবং বদলানো হয়নি। উদাহরণস্বরূপ Stripe সিক্রেট ব্যবহার করে অনুরোধের বডি ও একটি টাইমস্ট্যাম্পের ওপর একটি HMAC (কী-ভিত্তিক ফিঙ্গারপ্রিন্টের একটি ধরন), SHA-256 দিয়ে গণনা করে, এবং তা একটি Stripe-Signature হেডারে পাঠায়। আপনার অ্যাপ তার নিজের সিক্রেটের কপি দিয়ে একই গণনা করে; ফলাফল মিললে অনুরোধটি খাঁটি। টাইমস্ট্যাম্পও স্বাক্ষরিত থাকায় কেউ আগে রেকর্ড করে পরে পুনরায় পাঠানো পুরোনো অনুরোধও আপনি বাতিল করতে পারেন — Stripe-এর লাইব্রেরি ডিফল্টভাবে পাঁচ মিনিটের সহনশীলতা ধরে, তার ডকুমেন্টেশন অনুযায়ী যা সেপ্টেম্বর ২০২৬ পর্যন্ত প্রযোজ্য।

একটি ব্যবহারিক বিষয়: স্বাক্ষর গণনা করা হয় কাঁচা অনুরোধ বডির ওপর। আপনার ফ্রেমওয়ার্ক যাচাইয়ের আগে JSON পার্স ও পুনরায় ফর্ম্যাট করলে পরীক্ষা ব্যর্থ হয়। এটি অত্যন্ত সাধারণ একটি বাগ।

পুনরায় চেষ্টা, নকল ও ক্রম

প্রোভাইডাররা আলাদা, তাই প্রতিটির ডকুমেন্টেশন দেখুন। সেপ্টেম্বর ২০২৬ পর্যন্ত:

Stripe-এর ডকুমেন্টেশন আরও বলে, ইভেন্টগুলো ঘটার ক্রমে পৌঁছানোর গ্যারান্টি নেই, এবং একই ইভেন্ট মাঝেমধ্যে একাধিকবার আসতে পারে; তাই এটি ইভেন্ট ID ট্র্যাক করার পরামর্শ দেয়।

সাধারণ শিক্ষাটি যেকোনো প্রোভাইডারের ক্ষেত্রেই খাটে: ইভেন্ট দেরিতে, একাধিকবার ও ক্রমহীনভাবে আসতে পারে। আপনার হ্যান্ডলার হওয়া উচিত idempotent — একই ইভেন্ট দুবার প্রক্রিয়া করলেও ফল একবার প্রক্রিয়া করার মতোই হয়।

একটি বাস্তব উদাহরণ: একটি পেইড কোর্স খুলে দেওয়া

আপনি একটি অনলাইন কোর্স বিক্রি করেন। একজন শিক্ষার্থী কিনুন চাপে, Stripe-এর হোস্টেড চেকআউট পেজে পেমেন্ট করে, এবং আপনার সাইটে ফিরে আসে।

ভঙ্গুর উপায়: “ধন্যবাদ” পেজ কোর্স খুলে দেয়। রিডাইরেক্টের সময় শিক্ষার্থী ব্রাউজার বন্ধ করলে সে পেমেন্ট করেছে কিন্তু অ্যাক্সেস পায়নি। আর কেউ ধন্যবাদ পেজের URL অনুমান করলে পেমেন্ট ছাড়াই অ্যাক্সেস পায়।

ওয়েবহুক উপায়:

1. Stripe পেমেন্ট নিশ্চিত করলে /webhooks/stripe-এ একটি checkout.session.completed ইভেন্ট পাঠায়।
2. আপনার ব্যাকএন্ড সিক্রেট দিয়ে স্বাক্ষর যাচাই করে। ব্যর্থ হলে 400 ফেরত দেয় এবং কিছু করে না।
3. এই ইভেন্ট ID আগে প্রক্রিয়া হয়েছে কি না দেখে। হ্যাঁ হলে 200 ফেরত দিয়ে থামে।
4. ইভেন্ট ID সংরক্ষণ করে, 200 ফেরত দেয়, এবং তারপর শিক্ষার্থীকে অ্যাক্সেস দেয় ও স্বাগত ইমেইল পাঠায়।
5. ধন্যবাদ পেজ শুধু বলে “পেমেন্ট পেয়েছি — আপনার কোর্স একটু পরেই দেখা যাবে” এবং শিক্ষার্থীর অ্যাক্সেস স্ট্যাটাস পরীক্ষা করে।

পরে কোনো সাবস্ক্রিপশন বাতিল হলে বা কার্ড ব্যর্থ হলে অন্য ওয়েবহুক ইভেন্ট আপনার অ্যাপকে অ্যাক্সেস সরাতে বা স্থগিত করতে বলে। সাবস্ক্রিপশন পণ্য এভাবেই বিলিংয়ের সঙ্গে সমন্বয়ে থাকে — দেখুন SaaS কী এবং আপনার অ্যাপে পেমেন্ট কীভাবে যোগ করবেন।

মূল শব্দ

• Endpoint: আপনার অ্যাপের সেই URL যা ওয়েবহুক গ্রহণ করে।
• Event / payload: কী ঘটেছে, এবং সেটির বিবরণ দেওয়া ডেটা (সাধারণত JSON)।
• Signing secret: স্বাক্ষর যাচাইয়ের জন্য ব্যবহৃত ভাগ করা সিক্রেট।
• Idempotent: একই ফলাফলসহ একাধিকবার চালানো নিরাপদ।
• Polling: ওয়েবহুকের অপেক্ষা না করে বারবার একটি API-কে পরিবর্তনের জন্য জিজ্ঞেস করা।
• Tunnel: এমন একটি টুল, যা উন্নয়নের সময় ল্যাপটপকে সাময়িক পাবলিক URL দেয়, যাতে ওয়েবহুক পৌঁছাতে পারে।

সাধারণ ভুল ও ভুল ধারণা

• স্বাক্ষর যাচাই না করা। এন্ডপয়েন্ট URL গোপন নয়। যাচাইই অনুরোধকে বিশ্বাসযোগ্য করে।
• উত্তর দেওয়ার আগে ধীর কাজ করা। সাড়া দেওয়ার আগে ইমেইল পাঠানো বা PDF তৈরি করলে টাইমআউট হতে পারে, যা পুনরায় চেষ্টা ট্রিগার করে, যা নকল তৈরি করে।
• একবার, ক্রমে পৌঁছানো ধরে নেওয়া। ইভেন্ট ID রেকর্ড করুন এবং আসার ক্রমের ওপর নির্ভর করবেন না।
• প্রিভিউ URL ব্যবহার। ওয়েবহুকের একটি স্থির, পাবলিক ঠিকানা লাগে। ব্যক্তিগত প্রিভিউ ও localhost ইন্টারনেট থেকে পৌঁছায় না; আপনার প্রকাশিত URL ব্যবহার করুন (বা পরীক্ষার সময় একটি tunnel)।
• টেস্ট ও লাইভ সিক্রেট মেশানো। প্রোভাইডাররা প্রায়ই টেস্ট ও লাইভ মোডের জন্য আলাদা সাইনিং সিক্রেট দেয়। দুটিই সংরক্ষণ করুন এবং সঠিকটি ব্যবহার করুন।
• গুরুত্বপূর্ণ সিদ্ধান্তে পেলোড অন্ধভাবে বিশ্বাস করা। উচ্চ-ঝুঁকির কাজের আগে ইভেন্ট পাওয়ার পর প্রোভাইডারের API থেকে সর্বশেষ অবস্থা আনা যুক্তিসঙ্গত।

আপনার AI builder-কে কী চাইবেন

সার্ভারে একটি POST /webhooks/stripe এন্ডপয়েন্ট যোগ করো। কাঁচা অনুরোধ বডি ও STRIPE_WEBHOOK_SECRET সিক্রেট ব্যবহার করে Stripe স্বাক্ষর যাচাই করো। অবৈধ স্বাক্ষর 400 দিয়ে প্রত্যাখ্যান করো। প্রতিটি ইভেন্ট ID সংরক্ষণ করো এবং আগে প্রক্রিয়া হওয়া ইভেন্ট এড়িয়ে যাও। দ্রুত 200 উত্তর দাও, তারপর checkout.session.completed হ্যান্ডল করো: অর্ডার পেইড চিহ্নিত করো এবং রসিদ পাঠাও। ইভেন্টের ধরন লগ করো। Checkout সফল পেজ থেকে অ্যাক্সেস দিও না।

এরপর পরীক্ষা করুন: প্রোভাইডারের ড্যাশবোর্ড থেকে একটি টেস্ট ইভেন্ট পাঠান, একই ইভেন্টটি আবার পাঠান, এবং একটি ভুল স্বাক্ষরসহ অনুরোধ পাঠান। শুধু প্রথমটিই কিছু বদলানো উচিত।

Mythex-এ ওয়েবহুক

Mythex আলাদা কোনো ওয়েবহুক সেবা চালায় না; আপনি এজেন্টকে আপনার অ্যাপের নিজস্ব ব্যাকএন্ডে একটি ওয়েবহুক এন্ডপয়েন্ট যোগ করতে বলেন, এবং প্রোভাইডারকে আপনার প্রকাশিত URL-এর দিকে নির্দেশ করেন, কারণ ওয়েবহুকের একটি পাবলিক ঠিকানা লাগে। স্বাক্ষর সিক্রেট প্রকল্পের সিক্রেটে যায়, এবং লাইভ অ্যাপে এটি বদলালে আবার প্রকাশ করতে হয়। ডকুমেন্টেশনের ওয়েবহুক হ্যান্ডল করা রেসিপিতে একটি স্টার্টার প্রম্পট আছে, এবং পেমেন্ট নেওয়া অ্যাপের জন্য স্টোর টেমপ্লেট ভালো শুরুর জায়গা।

প্রশ্নোত্তর