--- title: "ویب ہکس کا جائزہ" description: "ThunderPhone ریئل ٹائم ایونٹس کیسے پہنچاتا ہے، دستخطوں کی تصدیق کیسے کی جاتی ہے، اور پرانے اور اینڈ پوائنٹ پر مبنی ڈیلیوری ماڈلز کا تقابل کیسے ہوتا ہے۔" --- ThunderPhone آپ کے سرور کو HTTP `POST` درخواستیں بھیجتا ہے جب کال کے دوران کچھ واقعات پیش آتے ہیں — ایک آنے والی کال شروع ہوتی ہے، کال ختم ہوتی ہے، گریڈنگ رن مکمل ہوتا ہے، الرٹ فعال ہوتا ہے، وغیرہ۔ **ڈیلیوری کے دو ماڈلز** ہیں: متعدد URLs، ہر اینڈ پوائنٹ کے لیے الگ راز، ہر اینڈ پوائنٹ کے لیے ایونٹ فلٹرز، اور خودکار دوبارہ کوششیں۔ `GET/POST/PATCH/DELETE /v1/developer/webhook-endpoints` کے ذریعے منظم کریں۔ ہر تنظیم کے لیے ایک URL۔ اس میں کال لائف سائیکل ایونٹس شامل ہوتے ہیں، بشمول **بلاکنگ** کنفیگریشن ایکسچینجز۔ `GET/PUT /v1/webhook` پر منظم کیا جاتا ہے۔ [ایونٹس کیٹلاگ](/ur/webhooks/events) میں موجود تمام دس ایونٹ اقسام ویب ہک اینڈ پوائنٹس کے ذریعے ڈیلیور کی جاتی ہیں۔ کال لائف سائیکل کے چھ ایونٹس (`telephony.incoming`, `telephony.complete`, `telephony.tool`, `web.incoming`, `web.complete`, `web.tool`) **بھی** لیگیسی سنگل-URL ویب ہک کو بھیجے جاتے ہیں — اگر آپ کے پاس لیگیسی URL اور مماثل اینڈ پوائنٹ دونوں موجود ہوں، تو آپ کو ایونٹ **دونوں** راستوں پر موصول ہوتا ہے۔ بلاکنگ رویہ ([`telephony.incoming` / `web.incoming` کنفیگریشن ایکسچینج](/ur/webhooks/call-incoming) اور ویب ہک موڈ [ٹول ڈسپیچ](/ur/tools/overview)) صرف لیگیسی راستے پر موجود ہے؛ ہر اینڈ پوائنٹ ڈیلیوری فائر اینڈ فارگیٹ اطلاع ہوتی ہے۔ ## پے لوڈ فارمیٹ اینڈ پوائنٹ ڈیلیوریز `data`، `event_id`، اور `type` کے ساتھ ایک JSON آبجیکٹ ہوتی ہیں: ```json { "data": { "call_id": 987654321, "from_number": "+14155550199", "to_number": "+15551234567" }, "event_id": "3f6b2ad0-1c9e-4a57-9f2b-8f6f0f9d2f11", "type": "telephony.incoming" } ``` `event_id` ہر جاری کردہ ایونٹ کے لیے منفرد ہوتا ہے۔ یہ دوبارہ کوششوں کے دوران **اور** ایونٹ وصول کرنے والے ہر اینڈ پوائنٹ پر یکساں رہتا ہے — اسی کی بنیاد پر ڈی ڈپلیکیٹ کریں۔ لیگیسی سنگل-URL ویب ہک وہی `type` اور `data` بھیجتا ہے، لیکن `event_id` کے **بغیر**: ```json { "type": "telephony.incoming", "data": { "call_id": 987654321, "from_number": "+14155550199", "to_number": "+15551234567" } } ``` نیٹ ورک پر، ہر باڈی کینونیکل طور پر سیریلائز ہوتی ہے — کیز حروف تہجی کے مطابق ترتیب دی جاتی ہیں، کوئی وائٹ اسپیس نہیں ہوتی، اور UTF-8 استعمال ہوتا ہے۔ ان دستاویزات میں خوب صورت انداز سے فارمیٹ کی گئی مثالیں صرف پڑھنے میں آسانی کے لیے ہیں۔ ایونٹ اقسام اور پے لوڈ فیلڈز کی مکمل فہرست کے لیے [ایونٹس کیٹلاگ](/ur/webhooks/events) دیکھیں۔ ## دستخط کی توثیق ہر درخواست میں `X-ThunderPhone-Signature` ہیڈر میں **خام درخواست باڈی** پر HMAC-SHA256 دستخط شامل ہوتا ہے۔ دستخطی کلید اینڈپوائنٹ کا `secret` ہے (یا پرانی ڈیلیوریز کے لیے آپ کے تنظیمی سطح کے ویب ہک کا `secret`)۔ ### مراحل 1. کسی بھی پارسنگ سے **پہلے** خام درخواست باڈی پڑھیں۔ 2. `hmac_sha256(secret, body).hexdigest()` کا حساب لگائیں۔ 3. `X-ThunderPhone-Signature` ہیڈر سے مستقل وقت میں موازنہ کریں۔ ہم بالکل وہی بائٹس دستخط کرتے ہیں جو ہم منتقل کرتے ہیں، اور یہ بائٹس کینونیکل JSON سیریلائزیشن ہیں (ترتیب شدہ کیز، مختصر جدا کار)۔ اس لیے خام باڈی کے خلاف توثیق ہمیشہ کام کرتی ہے — اور اگر آپ کا فریم ورک آپ کو صرف پارس شدہ JSON دیتا ہے، تو اسے ترتیب شدہ کیز اور مختصر جدا کار کے ساتھ دوبارہ سیریلائز کرنے سے یکساں بائٹس تیار ہوتے ہیں۔ دونوں طریقے [توثیق گائیڈ](/ur/guides/verify-webhook-signatures) میں شامل ہیں۔ ```python Python import hmac import hashlib def verify_signature(body: bytes, signature: str, secret: str) -> bool: expected = hmac.new( secret.encode("utf-8"), body, hashlib.sha256, ).hexdigest() return hmac.compare_digest(expected, signature or "") # Example Flask handler from flask import Flask, request, abort app = Flask(__name__) @app.post("/thunderphone-webhook") def handle(): body = request.get_data() sig = request.headers.get("X-ThunderPhone-Signature", "") if not verify_signature(body, sig, WEBHOOK_SECRET): abort(401) event = request.get_json() # dispatch on event["type"] … return "", 204 ``` ```javascript Node.js (Express) import crypto from "node:crypto"; import express from "express"; function verifySignature(body, signature, secret) { const expected = crypto .createHmac("sha256", secret) .update(body) .digest("hex"); if (!signature || expected.length !== signature.length) return false; return crypto.timingSafeEqual( Buffer.from(expected), Buffer.from(signature), ); } const app = express(); app.post( "/thunderphone-webhook", express.raw({ type: "application/json" }), (req, res) => { const sig = req.header("X-ThunderPhone-Signature") || ""; if (!verifySignature(req.body, sig, process.env.WEBHOOK_SECRET)) { return res.sendStatus(401); } const event = JSON.parse(req.body.toString("utf8")); // dispatch on event.type … res.sendStatus(204); }, ); ``` ## ترسیل کی معنویت یہ معنویتیں **اینڈ پوائنٹ** ترسیلات پر لاگو ہوتی ہیں۔ لیگیسی واحد-URL webhook ایک ہی ہم وقت کوشش ہے، جس میں دوبارہ کوششیں نہیں ہوتیں۔ ہر ایونٹ کی فوری طور پر ایک بار کوشش کی جاتی ہے۔ کوئی بھی `2xx` جواب ترسیل کی تصدیق کرتا ہے۔ کسی بھی دوسرے نتیجے کی صورت میں (غیر-2xx، کنکشن کی خرابی، ٹائم آؤٹ) ہم **پہلی کوشش کے بعد 1 منٹ، 5 منٹ، 30 منٹ، 2 گھنٹے، 6 گھنٹے، 12 گھنٹے، اور 24 گھنٹے** پر دوبارہ کوشش کرتے ہیں — 24 گھنٹوں پر محیط 8 کوششیں۔ اگر ہر کوشش ناکام ہو جائے تو ترسیل رک جاتی ہے اور اینڈ پوائنٹ کو [webhook اینڈ پوائنٹس](/ur/webhooks/endpoints) میں `status="failing"` کے طور پر نشان زد کیا جاتا ہے۔ payload مستقل طور پر قبول ہوتے ہی `2xx` واپس کریں؛ اسے غیر ہم وقت انداز میں پروسیس کریں۔ ترسیل کی ترتیب بہترین کوشش کی بنیاد پر ہوتی ہے۔ عملی طور پر ہم ایونٹس کو ان کے بھیجے جانے کی ترتیب میں پہنچاتے ہیں، لیکن ناکامی کی صورت میں دوبارہ کوششیں ترتیب بدل سکتی ہیں۔ ہمیشہ `call_id` / آبجیکٹ id کے ذریعے نقلیں ہٹائیں اور مطابقت پیدا کریں۔ ترسیل **کم از کم ایک بار** ہوتی ہے: ایسے جواب کے بعد دوبارہ کوشش جسے ہم نے کبھی نہیں دیکھا، کسی ایونٹ کی نقل بنا سکتی ہے۔ ہر دوبارہ کوشش میں وہی `event_id` ہوتا ہے، اس لیے پروسیس شدہ ids محفوظ کریں اور تکرار کو چھوڑ دیں۔ `event_id` اینڈ پوائنٹس کے درمیان بھی مشترک ہوتا ہے — ایک ہی ایونٹ کو سبسکرائب کیے گئے دو اینڈ پوائنٹس کو ایک ہی `event_id` ملتا ہے۔ اینڈ پوائنٹ ترسیلات میں ہر کوشش کے لیے **30 سیکنڈ** کا ٹائم آؤٹ ہوتا ہے۔ لیگیسی راستے پر، لائیو کال کے رویے کو کنٹرول کرنے والی بلاکنگ درخواستیں — [`telephony.incoming` / `web.incoming`](/ur/webhooks/call-incoming) کنفیگریشن ایکسچینج — **10 سیکنڈ** بعد ٹائم آؤٹ ہو جاتی ہیں، لیکن سست جواب کال پک اپ میں تاخیر کرتا ہے، اس لیے چند سیکنڈ کے اندر جواب دینے کی کوشش کریں۔ webhook موڈ [ٹول ڈسپیچ](/ur/tools/overview) میں بطور ڈیفالٹ 20 سیکنڈ کی اجازت ہے، اور ٹول اعلانات اعلیٰ سطح کا `timeout` مقرر کر سکتے ہیں۔ آؤٹ باؤنڈ webhooks ThunderPhone کی کلاؤڈ IP رینج سے آتے ہیں۔ اگر آپ کے فائر وال کو اجازت فہرست درکار ہے تو سپورٹ سے رابطہ کریں، ہم موجودہ رینجز فراہم کر دیں گے۔ ## لیگیسی اور اینڈ پوائنٹ پر مبنی webhooks کے درمیان انتخاب | خصوصیت | لیگیسی (`/v1/webhook`) | اینڈ پوائنٹس (`/v1/developer/webhook-endpoints`) | |---------|------------------------|----------------------------------------------| | URLs کی تعداد | ہر تنظیم کے لیے 1 | ہر تنظیم کے لیے متعدد | | ایونٹ کوریج | صرف `telephony.*` / `web.*` | تمام 10 ایونٹ اقسام | | ایونٹ فلٹر | — | فی اینڈ پوائنٹ | | دوبارہ کوششیں | کوئی نہیں | 24 گھنٹوں میں 8 کوششیں | | لفافہ | `type` + `data` | `type` + `data` + `event_id` | | سیکرٹ روٹیشن | واحد سیکرٹ تبدیل کرتا ہے | فی اینڈ پوائنٹ سیکرٹ | | حذف کیے بغیر غیر فعال کریں | `PUT /v1/webhook` کے ساتھ `{"url": ""}` | `status=disabled` | | اسٹیٹس کی مرئیت | — | `active` / `disabled` / `failing` | | بلاکنگ کنفیگ ایکسچینج | ہاں ([`telephony.incoming` / `web.incoming`](/ur/webhooks/call-incoming)) | کبھی نہیں — صرف اطلاعات | | بہترین استعمال | متحرک کال کنفیگریشن | پروڈکشن میں ایونٹ استعمال | نئی انٹیگریشنز کو اینڈ پوائنٹ پر مبنی webhooks کے ذریعے ایونٹس استعمال کرنے چاہئیں۔ لیگیسی URL صرف اسی صورت برقرار رکھیں (یا شامل کریں) جب آپ کال پک اپ کے وقت کالز کو متحرک طور پر کنفیگر کرتے ہوں یا webhook موڈ ٹول ڈسپیچ استعمال کرتے ہوں — یہ درخواست/جواب ایکسچینجز صرف لیگیسی راستے پر چلتے ہیں۔ --- ## متعلقہ تمام ایونٹ اقسام اور ان کے payloads۔ متعدد اینڈ پوائنٹس، ایونٹ فلٹرز، اور سیکرٹس کا انتظام کریں۔ کالز کنفیگر کرنے کے لیے وہ بلاکنگ درخواست جس کا جواب آپ کے سرور کو دینا ضروری ہے۔ ٹرانسکرپٹ، ریکارڈنگ، اور میٹرکس کے ساتھ کال کے بعد کا payload۔