---
title: "كيف أستقبل تقارير التسليم عبر Webhook؟"
description: "كيف تستقبل تقارير تسليم SMS وWhatsApp عبر Webhook: إعداد نقطة الاستقبال، وربط الحالات، وإزالة الأحداث المكررة، وتأمينها، واسترداد التقارير الفائتة."
canonical: "https://omnichannels.ai/ar/answers/delivery-report-webhook/"
language: "ar"
updated: "2026-10-10"
publisher: "BroadNet Technologies"
brand: "OmniChannels.ai"
---

# كيف أستقبل تقارير التسليم عبر Webhook؟

Canonical: https://omnichannels.ai/ar/answers/delivery-report-webhook/
Language: ar
Publisher: OmniChannels.ai by BroadNet Technologies

**الإجابة المختصرة:** لاستقبال تقارير التسليم عبر Webhook، جهّز نقطة استقبال HTTPS تقبل طلبات POST وسجّل عنوانها لدى مزوّد المراسلة. خزّن كل حدث، وردّ بسرعة برمز حالة 2xx، ثم عالجه بشكل غير متزامن. اربط الأحداث بسجلاتك عبر معرّف الرسالة، وأزل المكرر منها، ولا تسمح أبداً لحالة متأخرة بأن تحل محل حالة نهائية.

## إعداد نقطة الاستقبال

أثناء التطوير، يمنح النفق (tunnel) الخادم المحلي عنوان HTTPS عاماً.

1. جهّز نقطة استقبال HTTPS تقبل طلبات POST بجسم JSON.
2. زوّد المزوّد بعنوان URL ليُضبط على الحساب أو الحساب الفرعي الصحيح.
3. أرسل رسالة تجريبية إلى رقمك وسجّل جسم الحدث الخام.
4. حدّد الحقول التي تحتاجها من أحداث فعلية، لا من أسماء حقول مفترضة.
5. احتفظ بنماذج من الحمولات كبيانات اختبار لكل قناة تستخدمها.

## ما الحالات التي ستصلك؟

يحوّل المزوّدون تقارير المشغلين والقنوات إلى أسماء حالات خاصة بهم. وهذه المجموعة الموحّدة هي التي تستخدمها OmniChannels.ai عبر SMS وWhatsApp والقنوات الأخرى.

| الحالة | المعنى | نهائية؟ |
|---|---|---|
| SUBMITTED | قُبلت ووُضعت في قائمة الانتظار | لا |
| SENT | سُلّمت إلى المشغل أو القناة | لا |
| DELIVERED | تأكد وصولها إلى الجهاز | غالباً، وقد تليها READ |
| READ | فُتحت، في القنوات التي تُبلغ بالقراءة | نعم |
| FAILED | لم تُسلَّم، مع ذكر السبب إن توفر | نعم |
| REJECTED | رُفضت، مثلاً بسبب اسم مرسل غير مسجّل | نعم |

## اجعل المعالج موثوقاً

- خزّن الجسم الخام ثم أعد 2xx. وإذا فشل التخزين فأعد 5xx ليُعاد إرسال الحدث.
- نفّذ المعالجة الفعلية في قائمة انتظار أو عامل خلفي، لا قبل الرد.
- أزل المكرر بحسب معرّف الرسالة، فقد تصل الحالة نفسها مرتين.
- رتّب الحالات بحيث لا تحل SENT المتأخرة محل DELIVERED أبداً.
- اقبل قيم الحالات التي لا تعرفها بدلاً من الفشل.
- لا تُعِد إرسال أي رسالة من داخل معالج الـ Webhook.

## التأمين واسترداد التقارير الفائتة

اقبل HTTPS فقط، واستخدم مساراً طويلاً يصعب تخمينه، وتحقق من بنية الجسم، وتأكد من الحالة باستدعاء استعلام قبل أي إجراء لا رجعة فيه مثل الاسترداد المالي. وإذا كانت نقطة الاستقبال متوقفة، فاطلب من المزوّد إعادة إرسال التقارير لتلك الفترة أو اقرأ الحالات من نقاط التقارير لديه.

في SMPP تصل التقارير على شكل deliver_sm عبر الـ bind بدلاً من Webhook. وبعض المشغلين يعيدون التقارير متأخرة أو لا يعيدونها إطلاقاً، لذا تعامل معها كدليل قوي لا كإثبات على القراءة.

## المصادر الرسمية

- [SMPP Protocol Specification v3.4 (Issue 1.2) — SMPP.org](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)
- [RFC 9110: HTTP Semantics (IETF)](https://datatracker.ietf.org/doc/html/rfc9110)

## أسئلة ذات صلة

- https://omnichannels.ai/ar/answers/sms-delivery-report-statuses/
- https://omnichannels.ai/ar/answers/integrate-sms-api/
- https://omnichannels.ai/ar/answers/connect-sms-provider-smpp/
- https://omnichannels.ai/ar/answers/why-sms-not-delivered/

آخر تحديث: 2026-10-10