ویب ہُک کیا ہے؟ ایپس ایک دوسرے کو کیسے مطلع کرتی ہیں

ویب ہُک ایک خودکار پیغام ہے جو ایک سروس کسی واقعے کے ہوتے ہی آپ کی ایپ کو بھیجتی ہے۔ جب گاہک کی ادائیگی کامیاب ہوتی ہے، تو Stripe آپ کی ایپ کے ایک پتے پر ویب ہُک بھیجتا ہے جس میں لکھا ہوتا ہے “ادائیگی ہو گئی، تفصیلات یہ ہیں”، اور آپ کی ایپ اس پر عمل کرتی ہے: آرڈر کو ادا شدہ نشان زد کرتی ہے، رسید بھیجتی ہے، اکاؤنٹ کھولتی ہے۔ مختصراً: API وہ ہے جب آپ کی ایپ دوسری سروس سے سوال کرتی ہے؛ ویب ہُک وہ ہے جب دوسری سروس آپ کی ایپ کو کال کر کے کچھ بتاتی ہے۔

AI کے ساتھ بناتے وقت یہ کیوں اہم ہے

جیسے ہی آپ کی ایپ ادائیگیاں لیتی ہے، کسی دوسرے ٹول سے فارم جمع کرتی ہے، یا GitHub، Shopify یا کیلنڈر جیسی سروسز سے جڑتی ہے، آپ کا واسطہ ویب ہُکس سے پڑے گا۔ یہ اکثر جاننے کا درست طریقہ ہوتے ہیں، لیکن یہی وہ جگہ ہے جہاں AI سے بنی ایپس اکثر باریک طور پر غلط ہوتی ہیں:

• اینڈ پوائنٹ ہر درخواست قبول کر لیتا ہے، اس لیے کوئی بھی جعلی “ادائیگی ہو گئی” واقعہ بھیج سکتا ہے۔
• ایپ چیک آؤٹ کے ری ڈائریکٹ پیج پر رسائی دیتی ہے، ویب ہُک پر نہیں، تو جو لوگ جلدی ٹیب بند کر دیں انہیں وہ نہیں ملتا جس کی انہوں نے ادائیگی کی، اور جو success URL ڈھونڈ لیں انہیں مفت مل جاتا ہے۔
• وہی واقعہ دو بار آتا ہے اور گاہک کو دو آرڈر یا دو ای میلز مل جاتی ہیں۔

ویب ہُکس کیسے کام کرتے ہیں یہ جاننا آپ کو شروع میں ہی حفاظتی انتظامات مانگنے کے قابل بناتا ہے۔

روزمرہ کی ایک مثال: ڈیلیوری کا ٹیکسٹ

آپ دو طریقوں سے جان سکتے ہیں کہ آپ کا پارسل پہنچ گیا یا نہیں۔ آپ ہر دس منٹ بعد دروازے تک جا کر دیکھ سکتے ہیں (یہ polling ہے، یعنی آپ کی ایپ بار بار API کو کال کر کے پوچھتی ہے “کچھ نیا ہے؟”)۔ یا کورئیر پہنچنے پر آپ کو ٹیکسٹ بھیج دے (یہ ویب ہُک ہے)۔

ٹیکسٹ واضح طور پر بہتر ہے، بشرطیکہ آپ اس پر بھروسہ کر سکیں۔ اگر کوئی بھی “پارسل پہنچ گیا” پیغام بھیج سکتا، تو آپ چاہتے کہ معلوم ہو کہ وہ واقعی کورئیر سے آیا ہے۔ اور اگر آپ کا فون بند ہوتا جب ٹیکسٹ آیا، تو آپ چاہتے کہ کورئیر بعد میں دوبارہ کوشش کرے۔ یہ دو معاملات، تصدیق اور دوبارہ کوشش، ویب ہُکس کو مشکل بناتے ہیں۔

ویب ہُک قدم بہ قدم کیسے کام کرتا ہے

1. آپ اپنی ایپ کے بیک اینڈ میں ایک اینڈ پوائنٹ بناتے ہیں: ایک URL جیسے https://yourapp.com/webhooks/stripe جو POST درخواستیں قبول کرے۔
2. آپ وہ URL فراہم کنندہ کے پاس رجسٹر کرتے ہیں اور وہ واقعات چنتے ہیں جو آپ چاہتے ہیں (مثلاً “checkout مکمل” اور “سبسکرپشن منسوخ”)۔
3. فراہم کنندہ آپ کو ایک signing secret دیتا ہے۔ آپ اسے اپنے سرور پر ایک secret کے طور پر محفوظ کرتے ہیں، دیکھیں environment variables اور secrets۔
4. کوئی واقعہ ہوتا ہے۔ فراہم کنندہ آپ کے URL پر ایک HTTP درخواست بھیجتا ہے جس کے باڈی میں JSON میں واقعے کی تفصیل ہوتی ہے، اور ایک دستخط والا ہیڈر۔
5. آپ کی ایپ دستخط کی تصدیق کرتی ہے، واقعے کی ID ریکارڈ کرتی ہے، فوراً کامیابی کا کوڈ (200) واپس کرتی ہے، اور پھر کام کرتی ہے۔
6. اگر آپ کی ایپ کامیابی کا جواب نہیں دیتی، تو بہت سے فراہم کنندگان بعد میں دوبارہ کوشش کرتے ہیں۔

دستخط

دستخط ثابت کرتا ہے کہ درخواست فراہم کنندہ سے آئی اور اس میں تبدیلی نہیں ہوئی۔ مثال کے طور پر Stripe باڈی اور ایک ٹائم اسٹیمپ پر، signing secret استعمال کرتے ہوئے، SHA-256 کے ساتھ HMAC (ایک قسم کا کلیدی فنگر پرنٹ) حساب کرتا ہے، اور اسے Stripe-Signature ہیڈر میں بھیجتا ہے۔ آپ کی ایپ اپنی کاپی کی secret کے ساتھ وہی حساب کرتی ہے؛ اگر نتائج مل جائیں تو درخواست اصلی ہے۔ چونکہ ٹائم اسٹیمپ بھی دستخط شدہ ہوتا ہے، آپ پرانی درخواستیں رد کر سکتے ہیں جو کسی نے ریکارڈ کر کے بعد میں دوبارہ چلائی ہوں۔ Stripe کی دستاویزات کے مطابق (ستمبر 2026 تک) اس کی لائبریریاں پانچ منٹ کی برداشت کی ڈیفالٹ حد رکھتی ہیں۔

ایک عملی تفصیل: دستخط خام درخواست باڈی پر حساب ہوتا ہے۔ اگر آپ کا فریم ورک تصدیق سے پہلے JSON کو پارس کر کے دوبارہ فارمیٹ کر دے، تو جانچ ناکام ہو جاتی ہے۔ یہ بہت عام بگ ہے۔

دوبارہ کوششیں، ڈپلیکیٹس اور ترتیب

فراہم کنندگان مختلف ہیں، اس لیے ہر ایک کی دستاویزات دیکھیں۔ ستمبر 2026 تک:

Stripe کی دستاویزات یہ بھی کہتی ہیں کہ واقعات کی یہ ضمانت نہیں کہ وہ اسی ترتیب سے پہنچیں جس ترتیب سے ہوئے، اور یہ کہ وہی واقعہ کبھی کبھار ایک سے زیادہ بار آ سکتا ہے، اس لیے وہ واقعات کی IDs ٹریک کرنے کی سفارش کرتی ہے۔

عمومی سبق ہر فراہم کنندہ کے لیے درست ہے: واقعات تاخیر سے، ایک سے زیادہ بار اور غلط ترتیب میں آ سکتے ہیں۔ آپ کا ہینڈلر idempotent ہونا چاہیے، یعنی ایک ہی واقعے کو دو بار چلانے کا نتیجہ ایک بار چلانے جیسا ہو۔

ایک عملی مثال: پیڈ کورس کھولنا

آپ ایک آن لائن کورس بیچتے ہیں۔ ایک طالب علم Buy پر کلک کرتا ہے، Stripe کے ہوسٹڈ چیک آؤٹ پیج پر ادائیگی کرتا ہے، اور آپ کی سائٹ پر واپس آ جاتا ہے۔

نازک طریقہ: “شکریہ” کا صفحہ کورس کھول دیتا ہے۔ اگر طالب علم ری ڈائریکٹ کے دوران براؤزر بند کر دے، تو اس نے ادائیگی کی مگر رسائی نہیں ملی۔ اور اگر کوئی شکریہ والا URL اندازے سے ڈھونڈ لے، تو اسے بغیر ادائیگی کے رسائی مل جاتی ہے۔

ویب ہُک کا طریقہ:

1. جب Stripe ادائیگی کی تصدیق کرتا ہے، تو وہ /webhooks/stripe پر checkout.session.completed واقعہ بھیجتا ہے۔
2. آپ کا بیک اینڈ signing secret سے دستخط کی تصدیق کرتا ہے۔ اگر ناکام ہو تو 400 واپس کرتا ہے اور کچھ نہیں کرتا۔
3. یہ چیک کرتا ہے کہ کیا اس واقعے کی ID پہلے پروسیس ہو چکی ہے۔ اگر ہاں، تو 200 واپس کر کے رک جاتا ہے۔
4. یہ واقعے کی ID محفوظ کرتا ہے، 200 واپس کرتا ہے، اور پھر طالب علم کو رسائی دیتا ہے اور خوش آمدید ای میل بھیجتا ہے۔
5. شکریہ کا صفحہ صرف کہتا ہے “ادائیگی موصول ہو گئی، آپ کا کورس چند لمحوں میں ظاہر ہوگا” اور طالب علم کی رسائی کی حالت چیک کرتا ہے۔

بعد میں، اگر کوئی سبسکرپشن منسوخ ہو یا کارڈ ناکام ہو، تو دوسرے ویب ہُک واقعات آپ کی ایپ کو رسائی ہٹانے یا روکنے کو کہتے ہیں۔ اسی طرح سبسکرپشن پروڈکٹس بلنگ کے ساتھ ہم آہنگ رہتے ہیں، دیکھیں SaaS کیا ہے اور اپنی ایپ میں ادائیگیاں کیسے شامل کریں۔

اہم اصطلاحات

• Endpoint: آپ کی ایپ میں وہ URL جو ویب ہُکس وصول کرتا ہے۔
• Event / payload: کیا ہوا، اور اسے بیان کرنے والا ڈیٹا (عموماً JSON)۔
• Signing secret: وہ مشترک راز جو دستخط کی تصدیق کے لیے استعمال ہوتا ہے۔
• Idempotent: ایک ہی نتیجے کے ساتھ ایک سے زیادہ بار چلانا محفوظ۔
• Polling: تبدیلیوں کے لیے ویب ہُک کا انتظار کرنے کی بجائے بار بار API سے پوچھنا۔
• Tunnel: ایک ٹول جو لیپ ٹاپ کو عارضی عوامی URL دیتا ہے تاکہ ڈویلپمنٹ کے دوران ویب ہُکس پہنچ سکیں۔

عام غلطیاں اور غلط فہمیاں

• دستخط کی تصدیق نہ کرنا۔ اینڈ پوائنٹ کا URL راز نہیں ہے۔ تصدیق ہی درخواست کو قابلِ اعتماد بناتی ہے۔
• جواب دینے سے پہلے سست کام کرنا۔ جواب سے پہلے ای میل بھیجنا یا PDF بنانا ٹائم آؤٹ کا سبب بن سکتا ہے، جس سے دوبارہ کوششیں ہوتی ہیں، جن سے ڈپلیکیٹس بنتے ہیں۔
• ایک بار، ترتیب سے، کا مفروضہ۔ واقعات کی IDs ریکارڈ کریں اور آنے کی ترتیب پر بھروسہ نہ کریں۔
• پریویو URL استعمال کرنا۔ ویب ہُکس کو ایک مستقل، عوامی پتے کی ضرورت ہے۔ نجی پریویوز اور localhost انٹرنیٹ سے نہیں پہنچ سکتے؛ اپنا publish کیا ہوا URL استعمال کریں (یا جانچ کے دوران tunnel)۔
• ٹیسٹ اور لائیو secrets کو ملانا۔ فراہم کنندگان اکثر ٹیسٹ اور لائیو موڈ کے لیے مختلف signing secrets دیتے ہیں۔ دونوں محفوظ کریں اور درست استعمال کریں۔
• اہم فیصلوں کے لیے پے لوڈ پر اندھا بھروسہ کرنا۔ اعلیٰ داؤ والے کاموں کے لیے، واقعہ ملنے کے بعد فراہم کنندہ کے API سے تازہ ترین حالت لانا معقول ہے۔

اپنے AI بلڈر سے کیا مانگیں

سرور پر ایک POST /webhooks/stripe اینڈ پوائنٹ شامل کریں۔ خام درخواست باڈی اور secret STRIPE_WEBHOOK_SECRET استعمال کرتے ہوئے Stripe دستخط کی تصدیق کریں۔ غلط دستخط کو 400 سے رد کریں۔ ہر واقعے کی ID محفوظ کریں اور پہلے سے پروسیس شدہ واقعات چھوڑ دیں۔ جلد 200 جواب دیں، پھر checkout.session.completed کو آرڈر کو ادا شدہ نشان زد کر کے اور رسید بھیج کر سنبھالیں۔ واقعے کی قسم لاگ کریں۔ کامیابی کے شکریہ صفحے سے رسائی نہ دیں۔

پھر اس کی جانچ کریں: فراہم کنندہ کے ڈیش بورڈ سے ایک ٹیسٹ واقعہ بھیجیں، وہی دوبارہ بھیجیں، اور ایک غلط دستخط والی درخواست بھیجیں۔ صرف پہلی کو کچھ بدلنا چاہیے۔

Mythex پر ویب ہُکس

Mythex کوئی الگ ویب ہُکس سروس نہیں چلاتا؛ آپ ایجنٹ سے اپنی ایپ کے اپنے بیک اینڈ میں ایک ویب ہُک اینڈ پوائنٹ شامل کرواتے ہیں، اور فراہم کنندہ کو اپنے publish کیے ہوئے URL کی طرف اشارہ کرتے ہیں، کیونکہ ویب ہُکس کو عوامی پتہ چاہیے۔ دستخط کی secret آپ کی پروجیکٹ secrets میں جاتی ہے، اور اگر آپ لائیو ایپ پر اسے بدلیں تو دوبارہ publish کریں۔ ویب ہُکس سنبھالنے کی docs ریسیپی میں ایک اسٹارٹر پرامپٹ ہے، اور ادائیگیاں لینے والی ایپس کے لیے اسٹور ٹیمپلیٹس اچھا نقطۂ آغاز ہیں۔

سوالات