Webhook چیست؟ تفاوت وب‌هوک و API + آموزش راه‌اندازی

فروشگاه‌های آنلاین باید مرتب وضعیت سفارش‌ها، پرداخت‌ها و موجودی را بین چند سیستم مختلف به‌روزرسانی کنند. اگر این کار با درخواست‌های دوره‌ای انجام شود، سیستم حتی زمانی که هیچ اتفاقی نیفتاده هم باید مدام بپرسد «تغییر جدیدی رخ داده است؟» و منابع سرور و شبکه را درگیر کند.

برای همین، سیستم‌های مدرن از Webhook استفاده می‌کنند؛ روشی که به‌محض وقوع یک رویداد، مثل ثبت سفارش یا موفق‌شدن پرداخت، اطلاعات آن را به‌صورت خودکار به یک URL مشخص ارسال می‌کند.

در ادامه می‌بینیم Webhook چیست، چه تفاوتی با API دارد، چه کاربردهایی دارد و چطور می‌توان آن را راه‌اندازی کرد.

Webhook چیست؟

وب‌هوک (Webhook) روشی برای ارسال خودکار اطلاعات یک رویداد از یک سرویس به یک URL مشخص است.

برای مثال، زمانی که یک پرداخت با موفقیت انجام می‌شود، سرویس پرداخت یک درخواست HTTP به URL مشخص‌شده ارسال می‌کند تا سیستم شما از این اتفاق مطلع شود.

برای درک بهتر، Webhook را می‌توان به پیامک بانک تشبیه کرد. شما شماره تلفن خود را در اختیار بانک قرار داده‌اید و بانک هر زمان تراکنشی در حساب شما اتفاق بیفتد، بدون اینکه از آن درخواست کرده باشید، پیامکی برایتان ارسال می‌کند.

در Webhook هم شما یک URL در اختیار سرویس مبدأ قرار می‌دهید. هر زمان رویداد موردنظر اتفاق بیفتد، سرویس اطلاعات مربوط به آن رویداد را به همان URL ارسال می‌کند.

اجزای تشکیل‌دهنده Webhook

سیستم Webhook از چهار بخش اصلی تشکیل شده است که در کنار هم مشخص می‌کنند چه رویدادی رخ داده، چه اطلاعاتی باید ارسال شود و این اطلاعات به کجا و با چه روشی منتقل شوند.

در ادامه این چهار بخش را معرفی کرده‌ایم:

1. Event: رویدادی که اتفاق افتاده؛ مثل ثبت سفارش یا موفق‌شدن پرداخت.
2. Payload: داده‌های مربوط به رویداد، معمولاً در قالب JSON.
3. Webhook URL: آدرس Endpoint مقصد که Payload به آن ارسال می‌شود.
4. HTTP Request: درخواست، از نوع POST، که داده را به URL مقصد منتقل می‌کند.

ارتباط Webhook با API چیست؟

Webhook و API هر دو برای ارتباط میان نرم‌افزارها استفاده می‌شوند، اما روش کارشان متفاوت است.

در API معمولی، برنامه شما درخواست را شروع می‌کند. مثلاً اگر بخواهید وضعیت یک سفارش را بدانید، از API فروشگاه درخواست می‌کنید:

• «وضعیت سفارش ۱۰۲۴ چیست؟»

سرویس مقصد پاسخ می‌دهد:

• «پرداخت شده است.»

در Webhook، جریان ارتباط برعکس می‌شود. شما به سرویس می‌گویید:

• «اگر وضعیت سفارش تغییر کرد، خودت به این URL اطلاع بده.»

بعد از تغییر وضعیت، سرویس بدون اینکه درخواست جدیدی از سمت شما دریافت کرده باشد، اطلاعات رویداد را به Endpoint شما ارسال می‌کند.

بنابراین بهتر است Webhook و API را مکمل یکدیگر بدانیم، نه جایگزین هم.

API می‌تواند برای خواندن، ایجاد، ویرایش یا حذف داده استفاده شود؛ Webhook بیشتر برای اطلاع‌رسانی خودکار درباره وقوع یک رویداد کاربرد دارد.

نگاهی به تفاوت Webhook و API

تفاوت اصلی Webhook و API در این است که در API کلاینت اطلاعات را درخواست می‌کند، اما در Webhook سرویس مبدأ اطلاعات را Push می‌کند.

ویژگی	API / Polling	Webhook
جهت ارتباط	کلاینت درخواست می‌دهد و سرور پاسخ می‌دهد	سرور پس از رویداد داده را ارسال می‌کند
مدل ارتباط	Pull	Push
زمان دریافت اطلاعات	بر اساس فاصله Polling	بلافاصله پس از وقوع رویداد
درخواست‌های بدون نتیجه	ممکن است زیاد باشند	وجود ندارند یا بسیار کمترند
تأخیر	وابسته به فاصله Polling	معمولاً بسیار کم
مصرف منابع	ممکن است با درخواست‌های تکراری افزایش پیدا کند	عمدتاً هنگام وقوع رویداد مصرف می‌شود
کاربرد اصلی	دریافت و مدیریت داده	اطلاع‌رسانی درباره رویداد
نیاز سمت مقصد	API Client	Endpoint عمومی برای دریافت درخواست

مزایا و معایب استفاده از Webhook

Webhookها ارتباط بین سرویس‌ها را سریع‌تر می‌کنند، اما استفاده از آن‌ها بدون درنظرگرفتن محدودیت‌ها می‌تواند مشکلاتی در معماری نرم‌افزار ایجاد کند.

مزایا	چالش‌ها
✓ دریافت اطلاعات تقریباً بلادرنگ	✕ وابستگی به در دسترس بودن Endpoint
✓ حذف بسیاری از درخواست‌های Polling	✕ نیاز به Endpoint عمومی
✓ خودکارسازی فرایندها	✕ چالش‌های امنیتی
✓ کاهش تأخیر	✕ احتمال دریافت مجدد رویداد
✓ مصرف بهینه‌تر منابع در بسیاری از سناریوها	✕ احتمال تحویل نامرتب رویدادها
✓ اتصال ساده‌تر سرویس‌ها	✕ دشواری عیب‌یابی در پیاده‌سازی‌های پیچیده
✓ پشتیبانی از Payloadهای مختلف	✕ وابستگی به قابلیت‌های سرویس مبدأ
✓ مناسب برای معماری‌های Event-Driven	✕ نیاز به مدیریت بارهای ناگهانی

• اگر در کنار Webhook به دنبال افزایش دسترس‌پذیری سرویس‌ها و مدیریت ترافیک میان موقعیت‌های جغرافیایی مختلف هستید، مطلب «نقش GeoDNS در قطعی اینترنت؛ راهکار افزایش دسترس‌پذیری سایت» را بخوانید.

کاربردهای Webhook چیست؟ از پرداخت تا پیام‌رسانی

Webhook تقریباً هر جا که یک سیستم باید از وقوع رویداد در سیستم دیگری مطلع شود، کاربرد دارد.

۱. پرداخت و صورتحساب

سرویس‌های پرداخت مانند Stripe و PayPal از Webhook برای اطلاع‌رسانی درباره رویدادهای مختلف استفاده می‌کنند. این سرویس‌ها برای اطلاع‌رسانی درباره پرداخت موفق یا ناموفق، بازپرداخت وجه، تغییر وضعیت تراکنش و تمدید اشتراک از Webhook استفاده می‌کنند تا سیستم شما بدون نیاز به بررسی مداوم، از وضعیت جدید مطلع شود.

برای مثال، پس از موفق‌شدن پرداخت، سرویس پرداخت می‌تواند Webhook را به Backend فروشگاه ارسال کند تا سفارش از وضعیت «در انتظار پرداخت» به «پرداخت‌شده» تغییر کند.

۲. تجارت الکترونیک

پلتفرم‌هایی مانند Shopify و WooCommerce می‌توانند برای رویدادهایی مانند موارد زیر Webhook ارسال کنند:

• ثبت سفارش
• تغییر وضعیت سفارش
• تغییر موجودی
• تغییر محصول
• رویدادهای ارسال سفارش

۳. توسعه نرم‌افزار و CI/CD

یکی از کاربردهای مهم Webhook در اکوسیستم توسعه نرم‌افزار است. سرویس‌هایی مانند GitHub، GitLab و Bitbucket که برای مدیریت مخزن کد و توسعه نرم‌افزار استفاده می‌شوند، می‌توانند از Webhook برای اعلام رویدادهایی مانند Push شدن کد، ایجاد Pull Request، ثبت Issue و انتشار نسخه جدید استفاده کنند.

برای مثال، می‌توانید Webhook را طوری تنظیم کنید که با هر Push شدن کد، یک درخواست به سرور CI/CD ارسال شود و فرایند Build، Test و Deploy را آغاز کند:

Developer

↓

git push

↓

GitHub

↓

Webhook

↓

CI/CD Server

↓

Build → Test → Deploy

به این ترتیب Push شدن کد می‌تواند آغازگر فرایند Build و Deploy باشد.

۴. پیام‌رسانی و ارتباطات

سرویس‌هایی مانند Slack، Discord و Microsoft Teams در سناریوهای مختلف برای ارسال یا دریافت رویدادها از Webhook استفاده می‌کنند. مثلاً می‌توان سیستم CI/CD را طوری تنظیم کرد که پس از پایان Deploy، یک پیام خودکار در کانال تیم ارسال شود.

۵. CRM و بازاریابی

Webhook را می‌توان در سیستم‌های CRM و بازاریابی هم استفاده کرد. یکی از موقعیت‌هایی که این قابلیت می‌تواند کاربردی باشد، ثبت یک سرنخ یا مشتری جدید است؛ در این حالت، سیستم CRM می‌تواند اطلاعات فرد را به‌صورت خودکار به سرویس دیگری ارسال کند تا فرایندهایی مانند ثبت اطلاعات، ارسال ایمیل، تخصیص سرنخ به کارشناس فروش یا به‌روزرسانی اطلاعات مشتری انجام شود.

۶. زیرساخت و مانیتورینگ

در سیستم‌های مانیتورینگ، نیاز است که به‌محض شناسایی یک مشکل یا ایجاد Alert، این رویداد سریعاً به تیم یا سیستم مسئول رسیدگی منتقل شود. Webhook می‌تواند این فرایند را خودکار کند و اطلاعات Alert را به سرویس دیگری ارسال کند.

برای مثال، زمانی که CPU سرور برای مدتی بالاتر از ۹۰ درصد قرار می‌گیرد، سیستم مانیتورینگ می‌تواند یک Webhook به سرویس مدیریت Incident یا کانال اطلاع‌رسانی تیم ارسال کند تا تیم فنی سریع‌تر از مشکل مطلع شود و برای بررسی آن اقدام کند.

۷. Infrastructure as Code و GitOps

در معماری‌های GitOps، تغییرات زیرساخت و تنظیمات سیستم از طریق مخزن Git مدیریت می‌شوند. زمانی که یک تغییر جدید در Repository ثبت یا Push شود، Webhook می‌تواند سیستم اتوماسیون را مطلع کند تا فرایندهایی مانند بررسی تغییرات، Build، تست و اعمال خودکار تغییرات روی زیرساخت اجرا شوند.

این مدل برای سرویس‌های ابری و زیرساخت‌هایی که نیاز به Deploy و به‌روزرسانی مداوم دارند گزینه مناسبی است؛ چون تغییرات ثبت‌شده در Git می‌توانند بدون دخالت دستی، فرایند اعمال تغییرات را آغاز کنند.

• اگر می‌خواهید بیشتر با مفهوم GitOps، نحوه کار آن و نقش Git در مدیریت و استقرار زیرساخت آشنا شوید، پیشنهاد می‌کنیم مطلب «GitOps چیست؟ راهنمای جامع مفهوم، نحوه کار و کاربردها» را بخوانید.

۸. هویت و دسترسی

رویدادهایی مانند ورود کاربر، تغییر رمز عبور، تغییر وضعیت حساب یا رویدادهای احراز هویت نیز می‌توانند به سیستم‌های دیگر ارسال شوند تا اقدامات لازم به‌صورت خودکار انجام شود.

آموزش راه‌اندازی وب‌هوک قدم به قدم

فرایند راه‌اندازی Webhook بسته به سرویس متفاوت است اما به طور کلی باید مراحل زیر را طی کنید:

مرحله ۱: اپلیکیشن مقصد را مشخص کنید

ابتدا مشخص کنید اطلاعات باید به کدام سیستم ارسال شود. این مقصد می‌تواند Backend اختصاصی شما، سیستم مدیریت ارتباط با مشتریان (CRM)، سیستم حسابداری، سامانه مانیتورینگ یا هر سرویس دیگری باشد که قرار است اطلاعات رویداد را دریافت و پردازش کند.

مرحله ۲: یک Endpoint ایجاد کنید

در سیستم مقصد باید یک URL برای دریافت Webhook داشته باشید.

برای مثال:

• https://example.com/webhooks/orders

این Endpoint باید بتواند درخواست HTTP ورودی را دریافت و پردازش کند.

اگر برنامه شما روی یک سرور توسعه‌ای و فقط روی localhost اجرا می‌شود، سرویس مبدأ معمولاً نمی‌تواند مستقیماً به آن دسترسی داشته باشد. برای تست می‌توانید از ابزارهایی مانند ngrok استفاده کنید تا یک URL عمومی موقت در اختیار شما قرار بگیرد.

مرحله ۳: URL را در سرویس مبدأ ثبت کنید

در سومین مرحله باید URL را در تنظیمات سرویسی که قرار است Webhook را ارسال کند ثبت کنید. در تنظیمات این سرویس گزینه‌هایی مانند Webhooks، Integrations یا Developer Settings را پیدا می‌کنید؛ برای مثال، در سرویس‌هایی مانند GitHub یا GitLab باید به بخش Webhooks بروید و URL مربوط به Endpoint خود را در آنجا وارد کنید.

سپس URL Endpoint خود را ثبت کنید تا سرویس مبدأ بتواند هنگام وقوع رویداد، اطلاعات را به آدرس شما ارسال کند.

مرحله ۴: رویدادها را انتخاب کنید

مشخص کنید Webhook برای چه اتفاق‌هایی فعال شود. این رویدادها می‌توانند بسته به نوع سرویس شامل ثبت سفارش جدید، موفق‌شدن پرداخت، Push شدن کد، ایجاد Pull Request یا تغییر وضعیت یک رکورد باشند.

برای مثال، اگر می‌خواهید پس از هر Push شدن کد، فرایند CI/CD اجرا شود، باید رویداد Push را در تنظیمات Webhook سرویس‌هایی مانند GitHub یا GitLab انتخاب کنید.

مرحله ۵: امنیت را تنظیم کنید

اگر سرویس مبدأ قابلیت Signature یا Secret دارد، حتماً آن را فعال کنید تا در سمت مقصد بتوانید بررسی کنید درخواست واقعاً از سرویس مبدأ ارسال شده و داده‌ها در مسیر دستکاری نشده‌اند.

یکی از رایج‌ترین روش‌ها برای اعتبارسنجی Webhook، استفاده از HMAC است که با استفاده از یک Secret مشترک، امضای درخواست را تولید می‌کند. سرور مقصد با بررسی این امضا می‌تواند معتبر بودن درخواست را تأیید کند.

مرحله ۶: Webhook را تست کنید

برای اینکه مطمئن شوید Webhook به‌درستی راه‌اندازی شده است، ابتدا یک رویداد آزمایشی ایجاد کنید تا بررسی کنید درخواست از سرویس مبدأ به Endpoint شما می‌رسد و در مقصد به‌درستی پردازش می‌شود. پیشنهاد می‌کنیم هنگام آزمایش، موارد زیر را بررسی کنید:

• آیا درخواست به Endpoint رسیده است؟
• Payload صحیح است؟
• Signature معتبر است؟
• سرور چه Status Codeای برگردانده؟
• پردازش رویداد با موفقیت انجام شده است؟

اگر همه این موارد درست باشند، Webhook شما آماده استفاده در محیط واقعی است.

بهترین ابزارها برای تست و عیب‌یابی Webhook

برای تست و عیب‌یابی Webhook، می‌توانید بسته به نیاز خود از ابزارهای زیر استفاده کنید:

ابزار	کاربرد اصلی	چه زمانی استفاده کنیم؟
Webhook.site	ساخت URL موقت و مشاهده درخواست‌ها و Payloadها	وقتی می‌خواهید سریع ببینید چه داده‌ای از سرویس مبدأ ارسال می‌شود
RequestBin	دریافت و بررسی درخواست‌های HTTP	برای بررسی ساختار درخواست و Payload بدون راه‌اندازی سرور
Pipedream	دریافت Webhook و بررسی یا پردازش داده‌ها	وقتی علاوه بر مشاهده Payload، به تست یک فرایند ساده نیاز دارید
Postman	شبیه‌سازی درخواست‌های HTTP و تست Endpoint	وقتی می‌خواهید Endpoint خود را با درخواست‌های مختلف آزمایش کنید
Ngrok	ایجاد یک URL عمومی برای localhost	وقتی Webhook را در محیط توسعه و روی سیستم شخصی تست می‌کنید

یک مثال از راه‌اندازی وب‌هوک

فرض کنید یک فرم آنلاین دارید و می‌خواهید بعد از هر ارسال، اطلاعات آن برای تولید یک سند یا فاکتور به سرویس دیگری منتقل شود.

جریان کار به این شکل است:

User

↓

Online Form

↓

New Submission

↓

Webhook

↓

Document Service

↓

Generated Invoice

در این فرایند، ابتدا سرویس تولید فاکتور یک URL در اختیار شما قرار می‌دهد و شما آن را در تنظیمات Webhook فرم ثبت می‌کنید. سپس رویداد ارسال فرم را انتخاب می‌کنید. از این به بعد، هر زمان کاربر فرم را ارسال کند، سرویس فرم اطلاعات آن را در قالب یک درخواست HTTP به URL مشخص‌شده می‌فرستد و سرویس مقصد پس از دریافت و پردازش اطلاعات، فاکتور را به‌صورت خودکار تولید می‌کند.

راه‌اندازی وب‌هوک با تلگرام

تلگرام برای دریافت پیام‌ها و سایر Updateهای بات، دو روش در اختیار توسعه‌دهنده قرار می‌دهد: Polling با متد getUpdates و Webhook با متد setWebhook. در روش اول، بات به‌صورت دوره‌ای از تلگرام درخواست می‌فرستد؛ اما در روش دوم، تلگرام به‌محض دریافت Update آن را به Endpoint شما ارسال می‌کند.

getUpdates؛ روش Polling

در روش Polling، برنامه بات به‌صورت دوره‌ای از Telegram API درخواست می‌فرستد تا بررسی کند آیا Update جدیدی دریافت شده است یا نه.

Your Bot

↓

GET getUpdates

↓

Telegram

↓

New Update

setWebhook؛ روش Webhook

در روش Webhook، شما یک URL عمومی را به تلگرام معرفی می‌کنید. پس از آن، هر زمان Update جدیدی برای بات دریافت شود، تلگرام اطلاعات آن را با یک درخواست HTTP به همان URL ارسال می‌کند.

User

↓

Telegram

↓

Webhook

↓

Your Server

پیش‌نیازهای Webhook تلگرام

برای راه‌اندازی Webhook تلگرام به توکن بات، یک Endpoint عمومی با HTTPS و سروری برای دریافت درخواست‌ها نیاز دارید. همچنین Endpoint باید شرایط موردنیاز Telegram Bot API برای دریافت Webhook را داشته باشد.

تنظیم Webhook تلگرام

برای ثبت Endpoint، از متد setWebhook استفاده کنید. ساختار کلی درخواست به شکل زیر است:

• https://api.telegram.org/bot<TOKEN>/setWebhook?url=<YOUR_URL>

برای مثال:

• https://api.telegram.org/bot123456:ABC-DEF1234/setWebhook?url=https://example.com/telegram/webhook

پس از ثبت Webhook، می‌توانید با متد getWebhookInfo وضعیت آن را بررسی کنید:

• https://api.telegram.org/bot<TOKEN>/getWebhookInfo

این متد اطلاعاتی مانند URL ثبت‌شده، تعداد Updateهای در انتظار و خطاهای اخیر Webhook را نمایش می‌دهد.

دریافت Update در سرور

تلگرام Updateها را با درخواست POST به Endpoint شما ارسال می‌کند. بنابراین Endpoint باید بتواند Body درخواست را دریافت و JSON ارسال‌شده را پردازش کند.

برای نمونه، در یک برنامه Node.js می‌توانید Endpoint ساده‌ای مانند زیر داشته باشید:

app.post(“/telegram/webhook”, (req, res) => {

const update = req.body;

console.log(update);

res.sendStatus(200);

});

در مثال بالا، اطلاعات دریافت‌شده در متغیر update قرار می‌گیرد و سرور با ارسال Status Code 200 دریافت موفق درخواست را به تلگرام اعلام می‌کند. سپس برنامه می‌تواند بر اساس محتوای Update، پیام کاربر را پردازش کند یا با استفاده از Telegram Bot API پاسخ مناسب را ارسال کند.

• اگر قصد دارید یک اپلیکیشن Node.js را روی سرور اجرا و مستقر کنید و با فرایند Deploy آن بیشتر آشنا شوید، مطلب «دیپلوی Node.js بدون DevOps؛ چرا PaaS بهتر است؟» می‌تواند راهنمای مناسبی برای شما باشد.

چرا Webhook برای زیرساخت ابری مهم است؟

در معماری‌های مدرن مثل Cloud، CI/CD و GitOps، Webhook می‌تواند ارتباط بین سرویس‌های مختلف را خودکار کند و فرایندهایی مانند Deploy را بلافاصله پس از وقوع یک رویداد آغاز کند. تصور کنید کد یک پروژه روی GitHub قرار دارد و اپلیکیشن شما روی یک سرور چابکان اجرا می‌شود.

با هر Push می‌توان چنین مسیری ایجاد کرد:

Git Push

↓

GitHub

↓

Webhook

↓

Deployment Server

↓

Build

↓

Test

↓

Deploy

در این مدل، با Push شدن کد، GitHub از طریق Webhook سیستم Deployment را مطلع می‌کند و فرایند Build، Test و Deploy آغاز می‌شود. دیگر لازم نیست سیستم Deployment هر چند دقیقه یک‌بار GitHub را بررسی کند تا بفهمد Commit جدیدی وجود دارد یا نه.

سخن پایانی

Webhook یکی از ساده‌ترین روش‌ها برای ایجاد ارتباط Event-Driven میان سرویس‌هاست. به‌جای اینکه یک سیستم دائماً از سرویس دیگری بپرسد «اتفاق جدیدی افتاده؟»، می‌تواند منتظر بماند تا سرویس مبدأ، درست پس از وقوع رویداد، اطلاعات لازم را ارسال کند.

این تفاوت در پروژه‌هایی مانند پرداخت آنلاین، فروشگاه اینترنتی، CI/CD، GitOps، مانیتورینگ، پیام‌رسانی و اتوماسیون زیرساخت اهمیت زیادی دارد.

البته Webhook جای API را نمی‌گیرد. API زمانی کاربرد دارد که بخواهید خودتان داده‌ای را دریافت یا تغییری در یک سرویس ایجاد کنید؛ Webhook زمانی وارد می‌شود که بخواهید از وقوع یک رویداد مطلع شوید و واکنش خودکار نشان دهید.

در معماری ابری، ترکیب Webhook با API، Queue، CI/CD و سرویس‌های مانیتورینگ می‌تواند زنجیره‌ای بسازد که بخش بزرگی از فرایندهای تکراری را بدون دخالت دستی اجرا کند.

اگر می‌خواهید این فرایندها را روی زیرساخت ابری اجرا کنید، می‌توانید همین حالا چابکان را با اعتبار رایگان امتحان کنید.

سوالات متداول (FAQ)

1. آیا وب‌هوک جایگزین API است؟

خیر. Webhook و API مکمل یکدیگرند؛ Webhook درباره وقوع یک رویداد اطلاع می‌دهد، در حالی که API برای دریافت، ایجاد، ویرایش یا حذف داده استفاده می‌شود.

2. وب‌هوک بیشتر کجا کاربرد دارد؟

هرجا که واکنش سریع به یک رویداد اهمیت داشته باشد، Webhook کاربرد دارد؛ از پرداخت و سفارش گرفته تا CI/CD، مانیتورینگ، پیام‌رسانی و همگام‌سازی داده‌ها.

3. آیا می‌توان از چند وب‌هوک به‌صورت همزمان استفاده کرد؟

بله، بسیاری از سرویس‌ها اجازه تعریف چند Webhook برای رویدادهای مختلف را می‌دهند. در برخی معماری‌ها نیز یک رویداد به چند مقصد ارسال می‌شود.

4. آیا برای راه‌اندازی وب‌هوک حتماً باید برنامه‌نویس باشم؟

برای اتصال دو سرویس آماده ممکن است فقط به ثبت یک URL نیاز داشته باشید. اما اگر قرار باشد Endpoint اختصاصی بسازید و Payload را پردازش کنید، دانش برنامه‌نویسی لازم است.

5. آیا می‌توان Webhook را آفلاین تست کرد؟

بله. سرویس‌هایی مانند Webhook.site، RequestBin و Pipedream یک URL عمومی موقت در اختیار شما قرار می‌دهند تا بتوانید درخواست‌ها و Payloadها را مشاهده کنید؛ برای تست Endpoint روی سیستم شخصی نیز ngrok کاربرد دارد.

6. اگر Endpoint وب‌هوک من از دسترس خارج شود چه اتفاقی می‌افتد؟

رفتار سرویس مبدأ به سیاست همان سرویس بستگی دارد؛ بسیاری از ارائه‌دهندگان در صورت شکست تحویل، چند بار Retry انجام می‌دهند. بنابراین Endpoint باید بتواند رویدادهای تکراری را مدیریت کند و برای رویدادهای مهم، سازوکار مناسبی برای ثبت و بازیابی داشته باشد.

7. چگونه یک وب‌هوک دریافت کنم؟

یک Endpoint عمومی ایجاد کنید که بتواند درخواست‌های HTTP، معمولاً POST، را دریافت کند و سپس URL آن را در سرویس مبدأ ثبت کنید. پس از وقوع رویداد، سرویس مبدأ Payload را ارسال می‌کند و سرور شما باید درخواست را اعتبارسنجی و با یک کد وضعیت 2xx دریافت آن را تأیید کند.

8. آیا Webhook همیشه Real-Time است؟

Webhook معمولاً با فاصله بسیار کمی پس از وقوع رویداد ارسال می‌شود، اما «Real-Time» به معنای تضمین تأخیر صفر نیست. شبکه، صف پردازش، سیاست سرویس مبدأ و وضعیت Endpoint می‌توانند روی زمان تحویل اثر بگذارند.