WhatsApp Cloud API مقابل On-Premise API:أيّهما يجب أن تستخدم في 2026؟
مايو 21, 2026
·
12 دقيقة قراءة
في هذا المقال: الإجابة في 60 ثانية · بنيتان معماريتان · جدول مقارنة كامل · الجدول الزمني للـ deprecation · Throughput وrate limits · تفكيك التكلفة الحقيقي · مشكلة webhook الوارد التي لا يتحدث عنها أحد · ما يتغير عند الهجرة · الأسئلة الشائعة
الإجابة في 60 ثانية
في 2026، هذا ليس خيارًا. وصلت WhatsApp On-Premise API إلى end-of-life رسمي في 23 أكتوبر 2025. توقفت Meta عن إرسال security patches، وتوقفت عن قبول تسجيلات أرقام جديدة في 15 يناير 2024، وعلّمت الـ On-Premise stack كـ software غير مدعوم. إذا كنت لا تزال تشغّل حاوية Docker self-hosted، فأنت على بنية تحتية ميتة.
WhatsApp Cloud API — حيث تستضيف Meta الخادم، تتعامل مع scaling، ترسل patches، وتدفع الرسائل الواردة إلى عنوان webhook الخاص بك — كانت الـ default لكل رقم جديد لـ WhatsApp Business منذ منتصف 2022. Cloud API أرخص، أسرع في التجهيز، أعلى throughput، وتحصل على ميزات جديدة أولاً. لا يوجد سيناريو في 2026 حيث يكون On-Premise هو الإجابة الصحيحة لتكامل جديد.
On-Premise EOL: 23 أكتوبر 2025بدون patches جديدة — أبدًاCloud API: default منذ 2022تكلفة infra لـ Cloud API: $0Throughput لـ Cloud: 1,000 msg/sذروة On-Premise: ~30–50 msg/s
بنيتان معماريتان، اسم منصة واحد
كل من Cloud API وOn-Premise API هما تقنيًا جزء من "WhatsApp Business Platform". الـ branding متطابق. البنية المعمارية مختلفة تمامًا — وفهم البنية المعمارية هو الطريقة الوحيدة لفهم لماذا فازت Cloud API.
WhatsApp Cloud API (مستضافة من Meta)
تطبيقك يرسل HTTP POST إلى https://graph.facebook.com/v21.0/{phone_number_id}/messages. تستلمه Meta، تُوجّه الرسالة عبر الـ backend الخاص بـ WhatsApp، تُسلّمها للعميل، وتدفع حالة التسليم والردود الواردة обратно إلى عنوان webhook المسجّل لديك. لا تلمس خادمًا أبدًا. المصادقة هي access token دائم بالإضافة إلى توقيعات payload بـ HMAC-SHA256. الـ media مستضاف على CDN من Meta مع سياسة احتفاظ لمدة 90 يومًا.
WhatsApp On-Premise API (self-hosted، مُهمَلة)
أنت — أو الـ BSP الخاص بك — تشغّل صورتين Docker نشرتهما Meta (whatsapp/coreapp وwhatsapp/web) على بنيتك التحتية الخاصة. يتصل الـ coreapp outbound إلى relay من Meta، يُخزّن الرسائل في قاعدة بيانات MySQL، ويُعرّض REST API على المنفذ 443. يدير فريقك تدوير الشهادات، تكرار MySQL، تخزين media، النسخ الاحتياطي، وكل security patch تُصدره Meta. كانت المواصفات الدنيا للأجهزة 4 vCPU و8 GB RAM لكل رقم هاتف.
إذا كنت لا تزال على On-Premise: آخر security patch أُرسل في 23 أكتوبر 2025. لا توجد patches مستقبلية مخططة. أنت تشغّل software به ثغرات معروفة وغير مُصحّحة، صفر تحديثات للميزات، وبدون دعم من Meta. الهجرة ليست اختيارية — لقد تأخرت.
جدول مقارنة كامل
البُعد
Cloud API
On-Premise API
الحالة في 2026
نشط — الـ default
EOL 23 أكتوبر 2025
من يستضيف الخادم
Meta
أنت أو الـ BSP الخاص بك
البصمة المادية للأجهزة
لا شيء
4 vCPU + 8 GB RAM كحد أدنى لكل رقم
وقت الإعداد (عبر BSP)
أقل من 10 دقائق
2–6 أسابيع (نشر الحاوية + تثبيت الشهادة)
المصادقة
Access token + HMAC-SHA256
شهادة عميل + admin bearer token
Throughput (الافتراضي)
80 msg/s لكل رقم
30–50 msg/s (محدود بالأجهزة)
Throughput (الحد الأقصى)
1,000 msg/s عند الطلب
80 msg/s مع multi-node + load balancer
Webhooks الواردة
HTTP POST إلى عنوانك — تنسيق Graph API
HTTP POST إلى عنوانك — تنسيق On-Premise REST
Security patches
تُدفع من قبل Meta تلقائيًا
سحب ونشر يدوي — لا شيء منذ أكتوبر 2025
استضافة الـ media
CDN من Meta، احتفاظ لمدة 90 يومًا
تخزينك، سياسة الاحتفاظ الخاصة بك
ميزات جديدة (Flows، إلخ)
اليوم الأول
Backported متأخر — أو أبدًا
تكلفة البنية التحتية/شهر
$0
$400–$1,200 لكل رقم هاتف
التكلفة لكل محادثة
نفس شبكة أسعار Meta
نفس شبكة أسعار Meta
توحيد Graph API
نعم — سطح مشترك مع FB + IG
لا — سطح REST منفصل
إقامة البيانات
مراكز بيانات Meta (الولايات المتحدة/الاتحاد الأوروبي)
خيارك
تسجيل أرقام جديدة
مفتوح
مغلق منذ 15 يناير 2024
الجدول الزمني للـ deprecation
معظم مقالات المقارنة تتجاوز التواريخ. هذه التواريخ هي القصة كاملة. إذا كنت لا تزال على On-Premise، فإن معرفة متى أُغلق كل باب بالضبط يخبرك بمدى إلحاح وضعك.
1 أغسطس 2018
إطلاق On-Premise API
يُشحن WhatsApp Business API مع On-Premise فقط. مطلوب حاويات Docker self-hosted. تبدأ قصة WhatsApp للمؤسسات.
19 مايو 2022
Cloud API تصل إلى general availability
أُعلن عنها في F8 2022. تصبح Cloud API متاحة لجميع الشركات. توصي Meta فورًا بـ Cloud كـ المسار المفضل للتكامل لجميع الأرقام الجديدة.
27 أكتوبر 2023
On-Premise API مُهمَلة رسميًا Deprecated
تنشر Meta إشعار الـ deprecation. تحديد تاريخ end-of-life في 23 أكتوبر 2025. تبدأ الساعة. يُوضَع كل مشغّل لـ On-Premise على جدول زمني إلزامي للهجرة.
15 يناير 2024
إغلاق تسجيلات الأرقام الجديدة على On-Premise
تتوقف Meta عن قبول أرقام WhatsApp Business جديدة على الـ stack الخاص بـ On-Premise. يجب أن تستخدم جميع الأرقام الجديدة Cloud API. يمكن للأرقام الحالية لـ On-Premise الاستمرار في العمل — مؤقتًا.
23 أكتوبر 2025
End-of-life رسمي — آخر security patch End of Life
أُرسِل آخر security patch. أصبحت حاويات On-Premise الآن software غير مدعوم. بدون patches مستقبلية، بدون إصلاحات للأعطال، بدون backports للميزات. أي مشغّل لـ On-Premise لا يزال يعمل في 2026 يعمل على codebase مجمّدة وغير مُصحّحة.
2026 وما بعده
Cloud API — المسار المدعوم الوحيد نشط
Cloud API هي تكامل WhatsApp Business API المدعوم الوحيد. WhatsApp Flows، Calling API (أُطلقت في يوليو 2025)، أنواع رسائل تفاعلية جديدة — كلها تصل إلى Cloud أولاً، وفقط على Cloud من الآن فصاعدًا.
Throughput وrate limits: الأرقام التي تهم فعليًا
تكون مستويات المراسلة اليومية متطابقة بين Cloud وOn-Premise — يتم تحديدها بواسطة نظام quality scoring لأرقام الهواتف من Meta، وليس بواسطة الـ API التي تستخدمها. تشارك كلتا الـ APIs نفس المستويات الأربعة:
Tier 1: 1,000 عميل فريد بدأه العمل لكل 24 ساعة (الـ default لجميع الأرقام الجديدة)
Tier 2: 10,000 عميل فريد لكل 24 ساعة
Tier 3: 100,000 عميل فريد لكل 24 ساعة
Tier 4: غير محدود لكل 24 ساعة
لا تحتوي رسائل الجلسة (الردود ضمن نافذة 24 ساعة فتحها العميل) على حد يومي في أي مستوى. حيث تتفوق Cloud API بشكل كبير على On-Premise هو في throughput في الثانية:
Cloud API
1,000 msg/s
لكل رقم هاتف (عند الطلب)
80 msg/s out of the box. قابلة للتوسيع إلى 1,000 msg/s عند الطلب لمرسلي الحجم العالي. تمتص Meta الحمل — لا تتطلب أي تغييرات في البنية التحتية من جانبك.
On-Premise API
30–50 msg/s
الحد العملي (عقدة واحدة)
ينطبق حد 80 msg/s نظريًا، لكن Docker بعقدة واحدة على VM بـ 4 vCPU يشبع عادةً عند 30–50 msg/s. الوصول إلى 80 msg/s يتطلب réplica لـ MySQL، إعداد multi-node، وload balancer.
بالنسبة لحملة Black Friday ترسل 100,000 رسالة في نافذة ساعة واحدة، تمتص Cloud API الحمل بدون تكوين. يتطلب On-Premise عمل هندسي مسبق — نشر multi-node، تكرار MySQL، load balancer أمام الـ coreapp — ثم لا يزال يصطدم بسقف صلب تزيله Cloud API بالكامل.
ما تدفعه فعليًا
تسعير كل محادثة من Meta متطابق لكلتا الـ APIs. الفرق كليًا في تكاليف البنية التحتية الثابتة. تتجاوز معظم مقالات المقارنة هذا الجزء لأنه غير ملائم لـ BSPs التي لا تزال تشغّل stacks لـ On-Premise.
Cloud API — التكلفة الشهرية لكل رقم
استضافة الخادم$0
قاعدة البيانات (MySQL)$0
إدارة الشهادات$0
Security patching / DevOps$0
تخزين الـ media$0 (CDN من Meta)
رسوم محادثات Metaحسب الحجم
Overhead ثابت للبنية التحتية$0 / شهر
On-Premise API — التكلفة الشهرية لكل رقم
استضافة الخادم (4 vCPU / 8 GB)$150–$400
MySQL (مكرر)$80–$200
إدارة شهادات TLS$20–$60
هندسة on-call$150–$400
تخزين الـ media / CDN$30–$140
رسوم محادثات Metaحسب الحجم
Overhead ثابت للبنية التحتية$430–$1,200 / شهر
تنطبق تكاليف البنية التحتية هذه لكل رقم هاتف. كانت وكالة تدير 10 أرقام WhatsApp للعملاء على On-Premise تحرق $4,300–$12,000/شهر قبل دفع رسوم محادثة واحدة لـ Meta. تزيل Cloud API هذا البند بالكامل.
القطعة التي تفوتها كل مقالة مقارنة: webhooks الواردة على Cloud API
تركز كل مقالة عن Cloud API مقابل On-Premise على outbound — إرسال الحملات، القوالب، البث. لا يشرح أي منها تقريبًا ما يحدث للرسائل الواردة على Cloud API، وهنا هو المكان الذي تصطدم فيه معظم الفرق بالمشاكل بعد الهجرة.
عندما يرسل عميل رسالة إلى رقم WhatsApp Business الخاص بك المتصل عبر Cloud API، تطلق البنية التحتية لـ Meta طلب HTTP POST إلى عنوان webhook المسجّل لديك. يحدث هذا خلال ميلي ثوانٍ. الـ payload هو كائن JSON منظم بتنسيق Graph API من Meta. يجب أن يكون خادمك — أو منصة webhook —:
قابل للوصول علنًا عبر HTTPS في جميع الأوقات
قادرًا على الاستجابة بـ HTTP 200 خلال 20 ثانية (وإلا تعيد Meta المحاولة)
التحقق من توقيع HMAC-SHA256 في هيدر X-Hub-Signature-256 قبل المعالجة
تحليل تنسيق payload لـ Graph API — الذي يختلف عن تنسيق REST لـ On-Premise
إليك كيف يبدو payload لرسالة واردة من Cloud API عند تطبيعه عبر تكامل webhook لـ WhatsApp من SocialHook — مُسلَّم إلى عنوانك بتنسيق متسق بغض النظر عن نوع الرسالة:
cloud-api-inbound-payload.json — مُسلَّم في <50ms عبر SocialHook
دور SocialHook في stack لـ Cloud API: تُسلّم Cloud API من Meta الأحداث الواردة إلى عنوان واحد. يجلس SocialHook بين Meta وخادمك — يتعامل مع التحقق من webhook (HMAC-SHA256)، يُطبع تنسيق payload لـ Graph API، يضيف retry تلقائي 3 مرات مع backoff أسي إذا أعاد خادمك non-200، ويسجّل كل تسليم مع سجل حالة كامل. يستلم خادمك حدث JSON نظيف ومتسق. لا يهم ما إذا كانت الرسالة جاءت من WhatsApp، أو Facebook Messenger، أو Instagram DMs — تنسيق payload متطابق عبر الثلاثة. عنوان واحد. ثلاث قنوات. ثابت $50/شهر.
ما يتغير فعليًا عند الهجرة من On-Premise إلى Cloud API
هجرة رقم هاتفك من On-Premise إلى Cloud API مدعومة وتحافظ على رقمك — لا يلاحظ العملاء أي تغيير. لكن كود جانب الخادم الخاص بك يحتاج إلى تحديثات في ثلاثة أماكن محددة تدفنها معظم أدلة الهجرة في الحواشي.
1
طريقة المصادقة تغيير كاسر
استخدم On-Premise شهادات TLS للعميل وadmin bearer token. تستخدم Cloud API access token دائم لـ outbound وHMAC-SHA256 للتحقق من payload الوارد. تحتاج إلى تحديث رؤوس المصادقة الخاصة بك وتنفيذ فحص التحقق من التوقيع على معالج webhook الخاص بك قبل الذهاب إلى الإنتاج.
2
بنية payload الوارد تغيير كاسر
تستخدم REST API لـ On-Premise وGraph API لـ Cloud API هياكل JSON مختلفة لأحداث webhook الواردة. تختلف أسماء الحقول، والتعشيش، والبيانات الوصفية. سيحتاج محلل payload الخاص بك إلى إعادة كتابة كاملة — أو تستخدم طبقة تطبيع مثل SocialHook التي تُجرّد هذا تمامًا من كود التطبيق الخاص بك.
3
منطق تنزيل الـ media
خزّن On-Premise الـ media الواردة على خادمك. تخزن Cloud API الـ media على CDN من Meta مع سياسة احتفاظ لمدة 90 يومًا. عندما يرسل عميل صورة أو مستند، يحتوي payload webhook الخاص بك على media ID. يجب أن تستدعي Cloud API لاسترداد عنوان التنزيل، ثم تجلب الملف. سينكسر الكود الحالي الذي يقرأ من مسار محلي.
4
عنوان API لـ outbound
عرّض On-Premise REST API على المنفذ 443 من حاويتك. تستخدم Cloud API عنوان Meta Graph API في graph.facebook.com. يختلف تنسيق الطلب، وهيدر المصادقة، وهيكل العنوان جميعًا. حدّث تكوين عميل HTTP الخاص بك وهيئات الطلب وفقًا لذلك.
5
إيقاف تشغيل البنية التحتية
بعد الهجرة والتحقق، أوقف تشغيل حاويات Docker الخاصة بك، ونسخة MySQL، والمراقبة المرتبطة. هنا هو المكان الذي تسترد فيه $400–$1,200/شهر. تحقّق من عدم وجود كود تطبيق لا يزال يشير إلى العنوان المحلي القديم قبل إيقاف التشغيل.
هل لا يزال خيار الـ On-Premise حلاً منطقياً في عام 2026؟
لقد اطلعنا على كافة الحجج الداعية للاحتفاظ بنظام الـ On-Premise في عام 2026. إليك التحليل الصريح:
متطلبات إقامة البيانات
كانت أقوى حجة تاريخية لصالح الـ On-Premise هي سيادة البيانات — أي الاحتفاظ ببيانات الرسائل الوصفية (Metadata) داخل شبكتك الخاصة (VPC) وفي نطاق قضائي محدد. أما واجهة Cloud API فهي ترسل البيانات عبر بنية "ميتا" التحتية (مراكز بيانات في الولايات المتحدة والاتحاد الأوروبي). بالنسبة للشركات الخاضعة للوائح حكومية أو مالية معينة، كان هذا عائقاً حقيقياً. في عام 2026، تم حل معظم هذه السيناريوهات من خلال إعدادات إقامة البيانات في الاتحاد الأوروبي المتوافقة مع GDPR من ميتا، أو عبر فئات Enterprise API التي توفر اتفاقيات معالجة بيانات صريحة. نادراً ما تصمد حجة إقامة البيانات أمام المراجعة القانونية الآن — وبالتأكيد لا تصمد أمام المخاطر الأمنية لتشغيل برمجيات غير محدثة.
مجموعات تقنيات الـ BSP القديمة
بعض مزودي خدمات الأعمال (BSPs) لم ينتهوا بعد من ترحيل كامل أسطول الـ On-Premise لديهم إلى الـ Cloud API. إذا كان نظام واتساب الخاص بك يدار من قبل BSP ولم يقم بنقلك بعد، فاضغط عليهم بقوة. إنهم يشغلون برمجيات غير مدعومة بالنيابة عنك. أي حادث أمني يقع على نظام الـ On-Premise الخاص بهم بعد أكتوبر 2025 يقع تحت مسؤوليتهم القانونية — وربما مسؤوليتك أنت أيضاً.
الحكم النهائي
لا يوجد سيناريو لبناء نظام جديد في عام 2026 يكون فيه الـ On-Premise هو الخيار الصحيح. بالنسبة لعمليات النشر الحالية التي تواجه قيوداً في إقامة البيانات — استشر فريقك القانوني بشأن شروط اتفاقية معالجة البيانات (DPA) من ميتا وخيارات مراكز بيانات الاتحاد الأوروبي، ثم قم بالهجرة بأسرع ما تسمح به تلك المراجعة. إن تشغيل برمجيات بدون تحديثات أمنية ليس وضعاً مقبولاً للامتثال في أي قطاع منظم.
إذا كنت تبني تكاملاً جديداً مع واتساب اليوم: ابدأ بواجهة Cloud API. استخدم BSP أو منصة Webhook للإعداد. قم بتسجيل رقم هاتفك، وتكوين نقطة نهاية الـ webhook، واستقبل أول رسالة واردة على خادمك. العملية برمتها — بما في ذلك الربط بـ SocialHook لتلقي بيانات JSON نظيفة — تستغرق أقل من 15 دقيقة. راجع دليل البدء السريع.
الأسئلة الشائعة
أسئلة شائعة
هل واجهة WhatsApp On-Premise API لا تزال مدعومة في 2026؟
لا. أوقفت "ميتا" دعمها رسمياً في 27 أكتوبر 2023، وكان التاريخ النهائي لنهاية العمر الافتراضي هو 23 أكتوبر 2025. لم يتم إصدار أي تحديثات أمنية منذ ذلك التاريخ، ولا يمكن تسجيل أرقام هواتف جديدة على نظام On-Premise (تم إغلاق ذلك في 15 يناير 2024)، ولن يتم نقل أي ميزات جديدة إليه أبداً. أي شخص لا يزال يشغل حاوية (Container) مستضافة ذاتياً في عام 2026 يعمل على برمجيات غير مدعومة وغير محدثة أمنياً.
ما هي واجهة WhatsApp Cloud API وكيف تختلف عن الـ On-Premise؟
واجهة WhatsApp Cloud API هي النسخة المستضافة من قبل ميتا لمنصة WhatsApp Business. أنت تقوم باستدعاء graph.facebook.com لإرسال الرسائل — وتدير ميتا البنية التحتية بالكامل. أما الـ On-Premise فكان يتطلب منك تشغيل حاويات Docker على خوادمك الخاصة، وإدارة قواعد بيانات MySQL، وتدوير شهادات TLS، وإصدار التحديثات الأمنية بنفسك. الـ Cloud API تقضي على كل تلك الأعباء التشغيلية.
ما هي حدود سعة الإرسال (Throughput) في WhatsApp Cloud API؟
تدعم الـ Cloud API بشكل افتراضي 80 رسالة في الثانية لكل رقم هاتف، ويمكن زيادتها إلى 1,000 رسالة في الثانية عند الطلب للمرسلين ذوي الأحجام الكبيرة. فئات المراسلة اليومية (1 ألف / 10 آلاف / 100 ألف / عملاء غير محدودين لكل 24 ساعة) متطابقة بين Cloud و On-Premise — حيث يتم التحكم فيها من خلال نظام تقييم الجودة من ميتا، وليس إصدار الـ API.
هل أحتاج إلى خادم خاص لاستقبال رسائل واتساب الواردة على الـ Cloud API؟
نعم — أو تحتاج إلى منصة Webhook. عندما يرسل عميل رسالة إلى رقمك، تقوم واجهة Cloud API بإرسال طلب HTTP POST إلى رابط الـ webhook المسجل لديك. تحتاج إلى خادم متاح للوصول العام (أو خدمة مثل SocialHook) لاستقبال الرسالة، والتحقق من توقيع HMAC-SHA256، ومعالجة البيانات. بدون نقطة نهاية webhook تعمل، لن تصلك الرسائل الواردة برمجياً أبداً.
كيف تختلف أسعار الـ Cloud API عن أسعار الـ On-Premise؟
تسعير ميتا لكل محادثة متطابق في كليهما. الفرق الحقيقي يكمن في تكلفة البنية التحتية الثابتة. كان الـ On-Premise يتطلب ما بين 400 إلى 1,200 دولار شهرياً لكل رقم هاتف في الاستضافة، وMySQL، والمراقبة، والهندسة. أما الـ Cloud API فتكلفة بنيتها التحتية هي 0 دولار — حيث تتحملها ميتا بالكامل. عادةً ما تكون التكلفة الإجمالية للملكية (TCO) في الـ Cloud API أقل بنسبة 30-60% من الـ On-Premise عند نفس حجم الرسائل.
ما الذي سيتغير في خادمي عند الهجرة من On-Premise إلى Cloud API؟
ثلاثة تغييرات جذرية: (1) المصادقة — كان الـ On-Premise يستخدم شهادات العميل؛ بينما يستخدم الـ Cloud API رمز وصول (Access Token) والتحقق من توقيع HMAC-SHA256. (2) هيكل البيانات (Payload) — يستخدم الـ Cloud API تنسيق Graph API JSON، والذي يختلف عن هيكل REST في الـ On-Premise. (3) التعامل مع الوسائط — كان الـ On-Premise يخزن الوسائط على خادمك؛ بينما يخزنها الـ Cloud API على شبكة توصيل المحتوى (CDN) الخاصة بميتا، مما يتطلب استدعاء API لاسترداد روابط التنزيل. يحتاج معالج الـ webhook، ومحلل البيانات، ومنطق الوسائط لديك جميعاً إلى تحديث.
الـ Cloud API متاح حالياً. ابدأ في استقبال الـ webhooks.
اربط رقم WhatsApp Cloud API الخاص بك بـ SocialHook واحصل على كل رسالة واردة يتم تسليمها إلى خادمك كبيانات JSON نظيفة — موثقة، موحدة، ومعاد محاولتها عند الفشل — في أقل من 50 مللي ثانية. بدون بنية تحتية. بدون Docker. بدون نوبات عمل تقنية للمراقبة.
