---
title: "كيف تختار واجهة مراسلة برمجية: قائمة تحقق للمديرين التقنيين"
description: "كيف تختار واجهة مراسلة برمجية: قائمة تحقق للمدير التقني تشمل القنوات وجودة المسارات والـ webhooks والأمان وحدود المعدل وإعادة المحاولة وSMPP وMCP والامتثال والأسعار."
canonical: "https://omnichannels.ai/ar/blog/messaging-api-buyers-checklist/"
language: "ar"
updated: "2026-10-10"
publisher: "BroadNet Technologies"
brand: "OmniChannels.ai"
category: "integration"
primaryQuery: "how to choose a messaging api"
keywords: ["قائمة تحقق لاختيار API المراسلة", "معايير تقييم منصات CPaaS", "مقارنة مزودي SMS API", "المسارات المباشرة مع المشغلين مقابل المسارات الرمادية", "webhooks في واجهات المراسلة", "أمان واجهات المراسلة البرمجية", "حدود المعدل في API المراسلة", "خادم MCP لواجهة المراسلة"]
published: "2026-10-10"
author: "OmniChannels.ai Editorial Team"
reviewer: "BroadNet Messaging Solutions Team"
readingMinutes: 13
answer: "اختر واجهة المراسلة البرمجية بناءً على الأدلة لا على قوائم الميزات. تحقق من أنها تغطي القنوات التي تحتاجها عبر تكامل واحد، وتستخدم مسارات مباشرة مع المشغّلين، وترسل حالات تسليم موحّدة إلى الـ webhooks، وتعتمد مصادقة آمنة، وتوثّق حدود المعدل والأخطاء، وتشرح كيف تعيد المحاولة دون تكرار. ثم تأكد من إتاحة الاختبار، وخيار SMPP للأحجام الكبيرة، ووصول آمن لوكلاء الذكاء الاصطناعي، ودعم الامتثال، وشروط دعم واضحة، وجدول أسعار منشور. وقيّم كل مزوّد باختبار فعلي."
takeaways: ["جودة المسار تحدد ما إذا كانت الرسائل تصل باسم المرسل الصحيح، فاسأل كيف تصل الحركة إلى كل مشغّل وتحقق من ذلك على هواتف حقيقية.", "قبول طلب الـ API يعني أن الرسالة دخلت الطابور لا أنها سُلّمت؛ فالنتيجة النهائية تصل لاحقًا عبر الـ webhooks أو تقارير تسليم SMPP.", "لا تقبل كل واجهات المراسلة مفتاح منع التكرار (idempotency key)، لذا تحقق من الطريقة التي يتوقعها المزوّد لمنع الإرسال المكرر بعد انتهاء المهلة.", "الحدود الموثّقة للمعدل، واستجابة 429 مع Retry-After، ورموز الأخطاء القابلة للقراءة آليًا، علامات على واجهة مبنية لحركة الإنتاج.", "جدول تقييم موزون يُملأ بعد اختبار عملي يقود إلى قرار أمتن من مقارنة الصفحات التسويقية."]
faq: 
  - q: "ما أهم عامل عند اختيار واجهة مراسلة برمجية؟"
    a: "بالنسبة لمعظم الشركات هو جودة التسليم على المسارات التي تهمك: هل تصل الرسائل إلى الهواتف في دولك المستهدفة، باسم المرسل المسجّل لديك، مع تقارير تسليم حقيقية. ولا تكتسب الميزات والأسعار أهمية إلا بعد أن يصبح التسليم موثوقًا. اختبر ذلك مباشرةً أثناء التقييم بالإرسال إلى هواتف حقيقية على كل مشغّل رئيسي في أسواقك."
  - q: "ما الفرق بين المسارات المباشرة مع المشغّلين والمسارات الرمادية؟"
    a: "المسار المباشر يعني أن المزوّد يرتبط بمشغّل الجوال، أو بشريك معتمد، بموجب اتفاقية تغطي نوع الحركة. أما المسار الرمادي فيسلّم حركة الرسائل من التطبيقات إلى الأشخاص عبر قنوات غير مخصصة لها، مثل اتصالات شرائح المستهلكين. وقد تبدو المسارات الرمادية رخيصة، لكنها تحمل مخاطر استبدال اسم المرسل وحجب الحركة وعدم موثوقية تقارير التسليم."
  - q: "هل أحتاج إلى مزوّد يدعم SMPP؟"
    a: "فقط إذا كنت ترسل أحجامًا كبيرة من رسائل SMS، أو تشغّل عملاء SMPP أصلًا، أو تعيد بيع خدمة SMS لعملائك. فمعظم التطبيقات تخدمها REST API بشكل أفضل، لأنها أبسط في التأمين وتغطي أيضًا WhatsApp وRCS وقنوات أخرى. واختيار مزوّد يوفر الاثنين يُبقي خيار SMPP مفتوحًا دون أن يفرضه عليك من اليوم الأول."
  - q: "كيف ينبغي أن تتعامل واجهة المراسلة مع إعادة المحاولة؟"
    a: "ينبغي أن توثّق الواجهة الأخطاء التي تصح إعادة المحاولة بعدها، وأن تعيد 429 مع ترويسة Retry-After عند تجاوز الحد، وأن تشرح كيف تتجنب تكرار الرسائل. بعض المزوّدين يقبلون مفتاح idempotency، وبعضهم يتوقع أن تسجّل كل عملية إرسال قبل تنفيذها وتتحقق من الحالة بعد انتهاء المهلة. وكلا النهجين يصلح إذا كان موثّقًا ونفّذته."
  - q: "هل ينبغي منح وكلاء الذكاء الاصطناعي وصولًا إلى واجهة المراسلة لدينا؟"
    a: "يمكن ذلك إذا كان الوصول مضبوطًا. فخادم Model Context Protocol (MCP) يتيح للوكلاء استدعاء أدوات المراسلة باستخدام token، لذا طبّق القواعد نفسها المطبقة على أي تكامل: أقل الصلاحيات اللازمة، ومفاتيح مؤقتة للتجارب، وتأكيد بشري قبل الإرسال، وأرقام اختبار أولًا، ومراجعة السجلات. ويجب أن يلتزم الوكلاء بقواعد الموافقة واسم المرسل نفسها التي يلتزم بها البشر."
  - q: "ماذا أسأل بشأن الدعم واتفاقيات مستوى الخدمة؟"
    a: "اسأل كيف يُبلَّغ عن الأعطال وكيف يُتواصل بشأنها، وما الساعات واللغات التي يغطيها الدعم، ومن يتولى المشكلات على مستوى المشغّل مثل حجب اسم المرسل، ومدى سرعة إلغاء الـ tokens، وما الذي تلتزم به الاتفاقية المكتوبة. احصل على الإجابات في العقد لا في عرض المبيعات، واسأل عن آلية التعويض بأرصدة الخدمة إذا لم تُستوفَ الالتزامات."
sources: 
  - title: "OWASP Top 10 API Security Risks – 2023"
    url: "https://owasp.org/API-Security/editions/2023/en/0x11-t10/"
  - title: "RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage"
    url: "https://www.rfc-editor.org/rfc/rfc6750"
  - title: "RFC 6585: Additional HTTP Status Codes (429 Too Many Requests)"
    url: "https://www.rfc-editor.org/rfc/rfc6585"
  - title: "OpenAPI Specification v3.1.0"
    url: "https://spec.openapis.org/oas/v3.1.0"
  - title: "Model Context Protocol specification"
    url: "https://modelcontextprotocol.io/specification/2025-06-18"
  - title: "Short Message Peer to Peer Protocol Specification v3.4 (SMPP.org)"
    url: "https://smpp.org/SMPP_v3_4_Issue1_2.pdf"
---

# كيف تختار واجهة مراسلة برمجية: قائمة تحقق للمديرين التقنيين

Canonical: https://omnichannels.ai/ar/blog/messaging-api-buyers-checklist/
Language: ar
Publisher: OmniChannels.ai by BroadNet Technologies

قائمة التحقق هذه موجّهة للمديرين التقنيين (CTOs) وقادة الهندسة والمعماريين الذين يختارون واجهة مراسلة برمجية لرسائل SMS وWhatsApp وRCS وغيرها من القنوات. وهي تحوّل المقارنة المبهمة بين المزوّدين إلى أسئلة محددة، واختبارات يمكنك إجراؤها في ظهيرة واحدة، وجدول تقييم يمكنك الدفاع عنه أمام فريقي المالية والأمن.

إذا كنت قد اخترت مزوّدًا بالفعل وتحتاج إلى بناء التكامل، فاقرأ [دليل ربط واجهات المراسلة البرمجية](/ar/blog/messaging-api-integration-guide/) بدلًا من هذا المقال. فهذا المقال يتناول القرار الذي يسبق ذلك.

## ما الذي ينبغي أن يقيّمه المدير التقني في واجهة المراسلة؟

قيّم ما يؤثر في نتائج الإنتاج: هل تصل الرسائل، وهل تستطيع رؤية ما حدث، وهل يصمد التكامل أمام الأعطال، وهل يبقى ملتزمًا بالأنظمة. فقوائم الميزات متشابهة بين المزوّدين، أما هذه الخصائص فلا.

| المجال | السؤال الذي يهم | الدليل الذي تطلبه |
|---|---|---|
| القنوات | هل يغطي تكامل واحد كل القنوات التي نحتاجها؟ | مرجع API لكل قناة، ونظام مصادقة واحد |
| جودة المسارات | كيف تصل الحركة إلى كل مشغّل؟ | وصف المسارات، واختبارات على الهواتف |
| رؤية التسليم | كيف نعرف الحالة النهائية؟ | وثائق الـ webhook، وقائمة الحالات، وخيارات إعادة الإرسال |
| الأمان | كيف تُصدر بيانات الاعتماد وتُخزن وتُلغى؟ | وثائق المصادقة، والشهادات، وإجراءات التدوير |
| الحدود والأخطاء | ماذا يحدث إذا أرسلنا بسرعة زائدة أو أرسلنا شيئًا خاطئًا؟ | حدود معدل منشورة، وبنية الخطأ، وإرشادات إعادة المحاولة |
| تجربة المطور | هل يستطيع مهندس إرسال رسالة حقيقية من الوثائق وحدها؟ | مواصفة OpenAPI، وSDKs، وأمثلة برمجية |
| التكرار | كيف نعيد المحاولة دون إرسال مزدوج؟ | إرشادات منع التكرار (idempotency) |
| إتاحة الاختبار | هل نستطيع الاختبار بأمان قبل الإنتاج؟ | بيانات اعتماد للاختبار، وأرقام موثّقة |
| الأحجام الكبيرة | هل يوجد خيار SMPP؟ | وثائق SMPP، وتجهيز جلسات الـ bind |
| وكلاء الذكاء الاصطناعي | هل يستطيع الوكلاء استخدام الواجهة ضمن ضوابط؟ | وثائق خادم MCP |
| الامتثال | أسماء المرسل، والموافقة، وحماية البيانات | إجراءات التسجيل، والشهادات |
| الدعم | من يساعد عندما يتعطل شيء؟ | شروط دعم مكتوبة |
| الأسعار | هل نستطيع توقع الفاتورة؟ | جدول الأسعار، ونموذج الفوترة |

## هل تغطي الواجهة القنوات التي تحتاجها؟

ابحث عن عنوان أساسي واحد (base URL)، ونظام مصادقة واحد، ونموذج واحد لحالات التسليم عبر القنوات. فالتكاملات المنفصلة لكل قناة تضاعف الشيفرة التي تصونها والمواضع التي قد تضيع فيها حالة ما.

- **اسرد قنواتك للسنتين القادمتين**، لا لليوم فقط. فالفرق التي تبدأ برموز OTP عبر SMS كثيرًا ما تضيف قوالب WhatsApp، ثم RCS، ثم البريد الإلكتروني أو الإشعارات الفورية.
- **تحقق من عمق دعم القناة** لا من شعارها فقط. في WhatsApp: هل تستطيع إدارة القوالب، وإرسال الرسائل التفاعلية، وتتبع الاعتماد عبر الواجهة؟ وفي SMS: هل تتوفر المراسلة ثنائية الاتجاه وUnicode وفحص الأرقام؟
- **تحقق من القناة البديلة.** إذا لم تُسلَّم رسالة WhatsApp، هل تستطيع المنصة التحويل إلى RCS أو SMS، وهل يمكن ضبط الترتيب لكل حالة استخدام؟ وتشرح [مقارنة WhatsApp وSMS وRCS](/ar/blog/whatsapp-vs-sms-vs-rcs/) متى تناسب كل قناة.

## كيف تحكم على جودة المسارات؟

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

**المسار المباشر** يعني أن المزوّد يرتبط بالمشغّل، أو بشريك معتمد، بموجب اتفاقية تغطي حركة الرسائل من التطبيقات إلى الأشخاص (A2P). أما **المسار الرمادي** فيدفع حركة A2P عبر طرق غير مخصصة لها، مثل اتصالات شرائح المستهلكين. وقد تبدو المسارات الرمادية أرخص في جدول الأسعار، لكنها تحمل مخاطر حقيقية:

- يُستبدل اسم المرسل برقم عشوائي، ما يهدم الثقة ويعطّل عادة التعبئة التلقائية لرموز OTP؛
- يكتشف المشغّلون الحركة ويحجبونها، أحيانًا في منتصف الحملة؛
- قد يولّد المسار تقارير التسليم بدل الشبكة، فلا تعني «مُسلَّمة» بالضرورة أنها سُلّمت.

أسئلة تطرحها:

1. أي الدول والمشغّلين في وجهاتنا تصلون إليهم مباشرة؟
2. كيف تتعاملون مع تسجيل اسم المرسل في كل دولة؟
3. من أين تأتي تقارير التسليم لديكم، وهل تمرّرون رمز الخطأ الصادر عن المشغّل؟
4. ماذا يحدث لحركتنا عندما يتدهور مسار ما؟ هل إعادة التوجيه تلقائية، وهل تبلغوننا؟

ثم اختبر: أرسل إلى هواتف حقيقية على كل مشغّل رئيسي، وتحقق من اسم المرسل الظاهر، وقارن التقارير بما تُظهره الهواتف. وللخلفية حول كيفية وصول رسائل SMS التجارية إلى المشغّلين، راجع [ما هي رسائل A2P SMS](/ar/blog/what-is-a2p-sms/).

## كيف تُعالَج تقارير التسليم والـ webhooks؟

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

كيف يبدو الوضع الجيد:

- **قائمة حالات موثّقة.** مثل SUBMITTED وSENT وDELIVERED وREAD وFAILED وREJECTED، مع بيان الحالات النهائية منها. ويشرح [دليل حالات التسليم](/ar/blog/message-delivery-status-explained/) معنى كل منها عمليًا.
- **أسباب الفشل.** ينبغي أن تحمل حالة FAILED أو REJECTED سبب المشغّل أو القناة متى وُجد.
- **الاستعادة.** إذا تعطلت نقطتك، هل تستطيع طلب إعادة إرسال التقارير لفترة زمنية محددة، أو قراءة الحالة لكل مستلم؟
- **إرشادات صريحة حول الترتيب والتكرار.** قد تصل الأحداث بغير ترتيبها وأكثر من مرة. والوثائق التي تقول ذلك أجدر بالثقة من وثائق تتجاهله.
- **أمان نقطة الاستقبال.** اسأل ما إذا كانت الـ webhooks موقّعة. وإن لم تكن، فينبغي أن يشرح المزوّد كيف تحمي النقطة، مثل الاقتصار على HTTPS، ومسار يصعب تخمينه، وتحقق صارم من محتوى الطلب، والتأكد من الحالة قبل أي إجراء لا يمكن التراجع عنه.

## ما المصادقة والأمان اللذان ينبغي توقعهما؟

كحد أدنى: tokens تُرسل في ترويسة `Authorization` عبر TLS ولا تُرسل أبدًا في الروابط؛ وإجراء واضح لتدوير بيانات الاعتماد وإلغائها؛ وضوابط أمنية مدققة بشكل مستقل. يعرّف RFC 6750 الـ Bearer tokens، وقائمة OWASP API Security Top 10 قائمة جيدة لمراجعتها مع المزوّد.

اسأل:

- **كيف تُصدر الـ tokens وتُحدد صلاحياتها وتُلغى؟** هل يمكنك الحصول على tokens منفصلة لكل خدمة أو بيئة؟ وما سرعة إلغاء token مسرّب؟
- **هل تُمرَّر بيانات الاعتماد أحيانًا كمعاملات في الرابط؟** لا تزال بعض واجهات HTTP القديمة تأخذ اسم المستخدم وكلمة المرور في سلسلة الاستعلام، فينتهي بها الأمر في السجلات. تجنب ذلك في التكاملات الجديدة.
- **هل تتوفر قائمة سماح لعناوين IP، وأين؟** هي شائعة في جلسات SMPP؛ فتحقق مما إذا كانت تنطبق على REST أيضًا.
- **ما الشهادات التي تغطي الخدمة؟** اطلب الشهادة أو التقرير نفسه لا الشعار فقط، وتحقق من نطاقها.
- **أين يُخزَّن محتوى الرسائل وإلى متى؟** هذا مهم لمراجعات حماية البيانات.

## ما حدود المعدل والإنتاجية التي ينبغي التخطيط لها؟

توقّع حدودًا افتراضية موثّقة، واستجابة `429 Too Many Requests` (RFC 6585) مع ترويسة `Retry-After` عند تجاوزها، وإجراءً للاتفاق على سقوف أعلى لذروات الإنتاج. فالحدود غير الموثّقة تُكتشف خلال أكبر حملاتك.

- **اسأل عن الحدود لكل واجهة**: طلبات REST وجلسات SMPP واستدعاءات فحص الأرقام كثيرًا ما تكون لها حدود منفصلة.
- **تحقق من نقاط الإرسال الجماعي.** إرسال طلب واحد بملف للمستلمين أرفق بالحدود من آلاف الطلبات المفردة.
- **اسأل كيف تُدار الذروات.** التخفيضات الخاطفة وتنبيهات الأعطال تحتاج إلى تخطيط مع المزوّد لا إلى الأمل.
- **خطّط من جهتك.** طابور ومحدّد معدل من نوع token bucket أمام الواجهة يُبقيان عدة عمّال ضمن حصتك.

ويُظهر [مرجع الأخطاء والحدود](/developers/errors-and-limits/) لدينا كيف تبدو هذه الوثائق عمليًا.

## ما مستوى جودة الـ SDKs والوثائق؟

الوثائق الجيدة تتيح لمهندس إرسال رسالة حقيقية، واستقبال حالة، ومعالجة خطأ، دون فتح تذكرة دعم. اطلب مستند OpenAPI؛ فالمزوّد الذي يحافظ عليه يستطيع أن يقدّم لك عملاء مولّدين آليًا، ومجموعات Postman، وأسماء حقول دقيقة.

علامات الجودة:

- مواصفة OpenAPI 3.x تطابق الواجهة الفعلية؛
- SDK واحدة على الأقل تُصان بانتظام، وأمثلة HTTP مباشرة للغات الأخرى؛
- أسماء حقول دقيقة للطلبات، وبنية خطأ موثّقة برمز قابل للقراءة آليًا، وأمثلة على الاستجابات؛
- دليل بدء سريع ينتهي بحالة تسليم، لا بمجرد «200 OK»؛
- ملاحظات صريحة حول ما لا يُدعم.

## كيف تتعامل الواجهة مع إعادة المحاولة والتكرار؟

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

بعض الواجهات تقبل مفتاح idempotency: ترسل قيمة فريدة مع الطلب، فيعيد التكرار بالقيمة نفسها النتيجة الأصلية. وأخرى، ومنها واجهتنا، لا تقبله؛ والنمط الموثّق حينها هو تسجيل كل عملية إرسال في قاعدة بياناتك قبل تنفيذها، وتخزين معرّف الرسالة المُعاد، وبعد انتهاء المهلة التحقق من وجود دليل على القبول قبل إعادة الإرسال. وكلا النهجين يصلح إذا كان موثّقًا. أما ما لا يصلح فهو مزوّد لم يفكر في المسألة أصلًا. وتعرض [صفحة الأخطاء والحدود](/developers/errors-and-limits/) نمط التسجيل قبل الإرسال.

## هل تتوفر إتاحة آمنة للاختبار؟

ينبغي أن تتمكن من الاختبار برسائل حقيقية إلى أرقام تتحكم فيها قبل أن تصل أي حركة إلى العملاء. اسأل كيف تبدو إتاحة الاختبار: بيئة تجريبية (sandbox) تحاكي الاستجابات، أم إرسال حقيقي مقصور على أرقام موثّقة.

البيئات التجريبية المحاكية مفيدة لاختبارات الوحدات لكنها نادرًا ما تعيد إنتاج سلوك المشغّلين. أما الإرسال الحقيقي إلى أرقام موثّقة فيُظهر لك طريقة عرض اسم المرسل والترميز والتقارير فعليًا. واسأل كم يستغرق الانتقال من الاختبار إلى الإنتاج، لأن اعتماد أسماء المرسل في بعض الدول يسير وفق الجدول الزمني للجهة التنظيمية.

## هل تحتاج إلى خيار SMPP؟

على الأرجح ليس من اليوم الأول، لكنك قد تحتاجه لاحقًا. SMPP v3.4 هو بروتوكول الاتصالات لتبادل رسائل SMS عبر اتصال دائم، ويناسب الأحجام الكبيرة والمستمرة من رسائل SMS والمجمّعين والموزّعين. اسأل ما إذا كان المزوّد يوفر SMPP عبر TLS، وكيف تُجهَّز جلسات الـ bind، وما إذا كانت تُستخدم المسارات نفسها المستخدمة في REST. ويقارن [دليل SMS API أم SMPP](/ar/blog/sms-api-vs-smpp/) بين الاثنين بالتفصيل.

## هل يستطيع وكلاء الذكاء الاصطناعي استخدام الواجهة بأمان؟

إذا كانت فرقك تستخدم مساعدين بالذكاء الاصطناعي أو تبني وكلاء، فإن خادم Model Context Protocol (MCP) يتيح لهم اكتشاف أدوات المراسلة واستدعاءها دون شيفرة ربط مخصصة. اسأل عما يستطيع الوكيل فعله وبأي صلاحيات.

أسئلة تطرحها:

- هل يعمل خادم MCP بالـ token والصلاحيات نفسها التي تعمل بها شيفرتنا؟
- هل يمكننا تفعيل الأدوات التي يحتاجها الوكيل فقط، مثل تقارير التسليم دون أدوات الإرسال؟
- هل تتوفر مفاتيح مؤقتة للتجارب؟
- هل ستظهر عمليات الإرسال في تقارير التسليم نفسها، لنتمكن من تدقيق سلوك الوكيل؟

راجع [وثائق خادم MCP](/developers/mcp/) لدينا كمثال على هذه الضوابط.

## ما دعم الامتثال الذي ينبغي أن يقدمه المزوّد؟

ينبغي أن يساعدك المزوّد في تسجيل أسماء المرسل حيث يُشترط ذلك، وأن يدعم معالجة طلبات الانسحاب، وأن يعالج البيانات ضمن ضوابط أمن وخصوصية معترف بها. وتبقى أنت مسؤولًا عن الموافقة، لكن المزوّد ينبغي أن يجعلها عملية.

- **أسماء المرسل:** تشترط بعض الدول تسجيل أسماء المرسل الأبجدية الرقمية، وبعضها يشترط معرّفات تنظيمية في كل رسالة. راجع [دليل تسجيل اسم المرسل في الإمارات والسعودية](/ar/blog/sms-sender-id-registration-uae-saudi/).
- **الموافقة:** اسأل كيف تُلتقط طلبات إلغاء الاشتراك في SMS ثنائية الاتجاه وكيف تصل إلى أنظمتك. ويغطي [دليل الموافقة](/ar/blog/opt-in-consent-multichannel-campaigns/) الالتزامات.
- **حماية البيانات:** اسأل عن اتفاقيات معالجة البيانات، وموقع الاستضافة، ومدة الاحتفاظ، والمعالجين من الباطن.

## ماذا تسأل بشأن الدعم واتفاقيات مستوى الخدمة؟

تعامل مع شروط الدعم كجزء من المنتج، واحصل عليها مكتوبة. لا تقارن الأرقام البراقة في المواد التسويقية، بل قارن ما يلتزم به العقد.

- كيف تُكتشف الأعطال ويُبلَّغ عنها وتُغلق؟
- ما الساعات والمناطق الزمنية واللغات التي يغطيها الدعم؟
- من يتولى المشكلات من جهة المشغّل، مثل حجب اسم المرسل في دولة ما؟
- هل يوجد جهة اتصال محددة أو مهندس تهيئة خلال التكامل؟
- بماذا تلتزم الاتفاقية، وكيف يُقاس ذلك، وماذا يحدث إذا لم يُستوفَ؟

## ما مدى شفافية الأسعار؟

ينبغي أن تتمكن من تقدير الفاتورة الشهرية من جدول أسعار منشور مع أحجامك. اسأل:

- هل الأسعار لكل رسالة، أم لكل جزء، أم لكل رسالة مسلّمة، وهل يختلف ذلك بين القنوات؟
- ما رسوم الأطراف الثالثة التي تُمرَّر بشكل منفصل، مثل رسوم Meta على WhatsApp؟
- هل الفوترة مسبقة الدفع أم لاحقة، وماذا يحدث إذا نفد الرصيد في منتصف الحملة؟
- هل يُحتسب فحص الأرقام، وتسجيل اسم المرسل، وجلسات SMPP المخصصة بشكل منفصل؟

وتذكّر أن Unicode والرسائل الطويلة تستهلك أجزاء SMS أكثر. ويشرح [دليل حدود الأحرف](/ar/blog/sms-character-limits-unicode-arabic/) لماذا قد تكلف الحملة العربية أكثر من نسختها الإنجليزية.

## كيف تقيّم المزوّدين؟

أجرِ الاختبار العملي نفسه مع كل مزوّد في القائمة المختصرة، ثم قيّمهم في جدول واحد. ووزّن المعايير بحسب أولوياتك؛ فالأوزان أدناه نقطة انطلاق لا معيار ثابت.

### خطوات التقييم

1. ضع قائمة مختصرة من مزوّدَين إلى أربعة يغطون قنواتك ودولك.
2. اطلب إتاحة الاختبار من كل منهم وسجّل المدة التي يستغرقها ذلك.
3. أجرِ اختبار التحقق السريع أدناه مع كل مزوّد.
4. أرسل إلى هواتف حقيقية على كل مشغّل رئيسي في أهم أسواقك.
5. اطرح الأسئلة المكتوبة من كل قسم أعلاه.
6. امنح كل معيار درجة من 1 إلى 5، واضربها في الوزن، واجمع النتائج.
7. راجع أعلى درجتين مع فرق الأمن والمالية والفريق الذي سيشغّل التكامل.

| المعيار | الوزن المقترح | المزوّد A | المزوّد B | المزوّد C |
|---|---|---|---|---|
| جودة المسارات والتسليم في أسواقك | 5 | | | |
| تقارير التسليم والـ webhooks | 4 | | | |
| الأمان وإدارة بيانات الاعتماد | 4 | | | |
| الوثائق وOpenAPI والـ SDKs | 3 | | | |
| حدود المعدل والأخطاء وإرشادات إعادة المحاولة | 3 | | | |
| تغطية القنوات والقناة البديلة | 3 | | | |
| الامتثال ودعم اسم المرسل | 3 | | | |
| شروط الدعم | 3 | | | |
| شفافية الأسعار | 3 | | | |
| إتاحة الاختبار | 2 | | | |
| خيار SMPP | 2 | | | |
| وصول وكلاء الذكاء الاصطناعي (MCP) | 1 | | | |

### اختبار تحقق سريع

ينبغي أن تتيح لك وثائق كل مزوّد تنفيذ شيء كهذا. وهذا هو الاستدعاء المكافئ على واجهتنا، كما يظهر في [دليل البدء السريع](/developers/quickstart/):

```bash
curl -X POST https://api.broadnet.me/sms/sendSms \
  -H "Authorization: Bearer $BROADNET_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "senderId": "OmniDemo",
    "destinationNumber": "447700900123",
    "message": "Your OmniDemo code is 482913",
    "messageType": "TEXT"
  }'
```

يعيد الاستدعاء الناجح `200 OK` مع معرّف الرسالة كنص عادي. وخلال الاختبار تحقق من أربعة أمور أخرى: ماذا يحدث مع token غير صالح عمدًا (المتوقع `401`)، ومع رقم بصيغة خاطئة (المتوقع `400` مع رمز خطأ)، ومع رسالة عربية (يجب أن تُرسل بترميز Unicode؛ راجع [مرجع SMS API](/developers/sms/))، وما إذا كانت حالة DELIVERED تصل إلى [الـ webhook](/developers/webhooks/) لديك.

## مثال تطبيقي: شركة تقنية مالية تختار مزوّدًا لرموز OTP والتنبيهات

«Nakheel Pay» (مثال افتراضي)، تطبيق مدفوعات في السعودية والإمارات، يحتاج إلى OTP عبر SMS الآن، وإلى تنبيهات المعاملات عبر WhatsApp خلال عام.

- **القائمة المختصرة:** ثلاثة مزوّدين يغطون الدولتين والقناتين.
- **اختبار التحقق السريع:** تصل إتاحة الاختبار من أحد المزوّدين خلال أيام، بينما يشترط آخر عملية مبيعات طويلة قبل أي اختبار. ويُسجَّل ذلك تحت معيار إتاحة الاختبار.
- **اختبارات الهواتف:** لدى أحد المزوّدين يظهر اسم المرسل المسجّل على كل المشغّلين المختبرين، ولدى آخر يُظهر مشغّل واحد مرسلًا رقميًا. فيُسأل ذلك المزوّد عن مساره ويحصل على درجة منخفضة في جودة المسارات.
- **التكرار:** يتحقق الفريق من طريقة تعامل كل مزوّد مع إعادة المحاولة. أحدهم يقبل مفتاح idempotency، وآخر يوثّق نمط التسجيل قبل الإرسال. وكلاهما مقبول، فيبني الفريق النمط مرة واحدة في خدمة الإرسال لديه.
- **المراجعة الأمنية:** يتحقق فريق الأمن من نطاقات الشهادات وإجراءات إلغاء الـ tokens.
- **القرار:** يرجّح الجدول الموزون المزوّد الذي يملك مسارات مباشرة وwebhooks موحّدة وخيار SMPP للنمو لاحقًا، رغم أن مزوّدًا آخر قدّم سعرًا معلنًا أقل قليلًا لرسائل SMS.

## أخطاء شائعة عند اختيار واجهة مراسلة برمجية

- **الاختيار بناءً على سعر الرسالة وحده.** الرسائل غير المسلّمة وأسماء المرسل المستبدلة تكلف أكثر مما توفّر.
- **الاختبار في بيئة تجريبية محاكية فقط.** سلوك المشغّلين لا يظهر إلا على هواتف حقيقية.
- **تجاهل التكرار.** حلقة إعادة محاولة بلا حماية ترسل رموز OTP مرتين.
- **اعتبار «مُرسلة» بمعنى «مُسلَّمة».** اسأل كيف تُبلَّغ الحالات النهائية.
- **تأجيل المراجعة الأمنية** إلى ما بعد التكامل، حين يصبح تغيير المزوّد مكلفًا.
- **قبول الالتزامات الشفهية.** شروط الدعم والخدمة مكانها العقد.
- **حدود قائمة التحقق هذه:** تصف الممارسات الجيدة وليست استشارة قانونية. تأكد من قواعد كل دولة مع الجهات التنظيمية ومزوّدك.

## كيف تساعدك OmniChannels.ai

تمنحك OmniChannels.ai واجهة REST واحدة على `https://api.broadnet.me` لرسائل SMS وWhatsApp وRCS وMessenger وInstagram وTelegram وEmail وPush، مع مصادقة Bearer token، ونحو 330 مسارًا موثّقًا، ومواصفة OpenAPI 3.1، وSDK بلغة TypeScript هي `@broadnet/cpaas-sdk`. وتصل حالات التسليم إلى الـ webhook لديك بصيغة واحدة. ويتوفر SMPP 3.4 عبر TLS لرسائل SMS عالية الحجم، ويتيح [خادم MCP](/developers/mcp/) لوكلاء الذكاء الاصطناعي استخدام الواجهة نفسها. وتمر الحركة عبر الروابط المباشرة لـ BroadNet مع أكثر من 1,000 مشغّل ومجمّع. وتُتاح بيئة الاختبار لأرقامك الموثّقة؛ ابدأ بـ [نظرة عامة للمطورين](/ar/developers/).