نحن بصدد إنهاء API داخل المواقع. راجع مستند حالة إنهاء API داخل المواقع للحصول على التفاصيل، والتعرف على كيفية الترحيل إلى API السحابة من الجيل القادم.
تفضل بزيارة صفحة حالة منصة واتساب للأعمال للحصول على أحدث المعلومات بشأن حالات الانقطاع في المنصة.
يراعي WhatsApp المراسلات مع مستخدمي واجهة API للأعمال الذين يديرون نقطة نهاية واجهة API على الخوادم التي يتحكمون بها لتكون مشفّرة تمامًا نظرًا لعدم إمكانية وصول الجهة الخارجية إلى المحتوى بين نقاط النهاية.
قد تختار بعض المؤسسات تفويض إدارة نقطة نهاية واجهة API الخاصة بتطبيق WhatsApp للأعمال إلى موفر حلول أنشطة تجارية تابع لجهة خارجية. وفي هذه الأمثلة، لا تزال ميزة المراسلات تستخدم تشفير بروتوكول الإشارة نفسه. ومع ذلك ونظرًا لأن مستخدم واجهة API الخاصة بتطبيق WhatsApp للأعمال قد اختار جهة خارجية لإدارة نقطة النهاية الخاصة به، لا يعتبر WhatsApp هذه الرسائل مشفّرة تمامًا. ولاحقًا في عام 2021، سينطبق ذلك أيضًا على الأنشطة التجارية التي تختار الاستفادة من الإصدار القائم على السحابة لواجهة API المُستضافة من جانب Facebook.
بالإضافة إلى ذلك، إذا كنت تستخدم بروتوكول HTTPS عند إجراء عمليات استدعاء إلى عميل واجهة API الخاصة بتطبيق WhatsApp للأعمال، فتكون هذه البيانات مشفّرة باستخدام بروتوكول SSL (من عميل الخلفية إلى عميل واجهة API الخاصة بتطبيق WhatsApp للأعمال).
للحصول على المزيد من التفاصيل، يمكنك الرجوع إلى المستند التقني حول نظرة عامة على تشفير WhatsApp لدينا.
لا، يمكنك تشغيل حساب واحد لكل مثيل. وإذا كنت بحاجة إلى حساب اختباري ثان، فتأكد من استخدام رقم آخر لهذا المثيل الثاني.
لا! يمكنك في أي وقت تضمين مثيل واحد فقط من عميل واجهة API واتساب للأعمال الذي يتم استخدامه لرقم هاتف واحد. وبمجرد أن تسجّل مثيلاً ثانيًا، فسيتم بدء مثيلك الأول ولكنه سيفشل. ونعمل حاليًا على إيجاد حل مناسب سيسمح لك بإجراء ذلك. سنخبرك دومًا بأي تحديثات.
يتطلب عميل API داخل المواقع في واتساب للأعمال توفير قاعدة بيانات لمفاتيح المتاجر لفك تشفير الرسائل المرسلة بين نشاط تجاري والعملاء. يتم تشفير كل الرسائل على واتساب باستخدام مفاتيح المرسِل والمستلِم. يتم تخزين مفاتيح العميل على جهازه المحمول ويتم تخزين مفاتيح النشاط التجاري في قاعدة بيانات النشاط التجاري. تعرَّف على المزيد حول أمان واتساب.
تمثل API سحابة في واتساب للأعمال حلاً بديلاً حيث تستضيف Meta خلالها قاعدة بيانات النشاط التجاري. تتيح لك API السحابة تنفيذ واجهات API واتساب للأعمال بدون تكلفة استضافة خوادمك الخاصة. معرفة المزيد.
لا، لا تتوفر حاليًا أية طريقة لتشغيل أرقام متعددة في إعداد عميل واجهة API الخاصة بتطبيق WhatsApp للأعمال نفسه. ونعمل حاليًا على إيجاد حل مناسب سيسمح بذلك في المستقبل.
نعم! يحاول عميل واجهة API واتساب للأعمال افتراضيًا الاتصال باستخدام chatd
عبر المنفذ 5222. وللحصول على أفضل تجربة استخدام، يمكنك فتح المنفذ 5222 لكل الزيارات الصادرة. ولا يثير ذلك مشكلة في الأمان نظرًا لأن الزيارات تكون صادرة فقط من مركز البيانات المتوفر لديك.
إذا كنت لا تفتح المنفذ 5222، فسيحاول عميل واجهة API واتساب للأعمال استخدام المنفذ 443. وإذا كان لا يزال جدار الحماية أو الوكيل الخاص بك يعمل على إنهاء الاتصالات، فيرجى التواصل مع فريق واتساب من خلال إرسال أي سؤال عبر الدعم المباشر من أجل تصحيح الأخطاء.
لا، يفتح عميل واجهة API واتساب للأعمال اتصال TCP صادرًا إلى منفذ 5222 أو 443 على خوادم واتساب. وتتم زيارة TCP عبر هذا الاتصال طويل الأجل. وتنظم جُدر الحماية ذلك بشكل طبيعي بحيث تسمح "بالزيارة الصادرة والزيارة التي تم إنشاؤها". بالطبع، ستقوم الحِزم بالدفق للأمام والخلف بمجرد إنشاء الاتصال، ولكن يكون الاتصال واردًا من عميل واجهة API واتساب للأعمال بحيث لا توجد حاجة لأية قاعدة تسمح بإجراء الاتصالات الواردة.
تعتمد المتطلبات على معدل تحميلك وحالتك. وسيعمل الحل على أي جهاز متصل بالإنترنت يقوم بتشغيل docker. فعلى سبيل المثال، يمكن إجراء الاختبار البسيط على الكمبيوتر المحمول.
عند إعداد خادم الإنتاج لمثيل واحد، نوصي باستخدام بطاقة SSD بسعة تخزين 250 جيجابايت على الأقل وذاكرة وصول عشوائي تصل إلى 16 جيجابايت ووحدة معالجة مركزية رباعية النواة. ولا يوصى باستخدام HDD لأن سرعات الإدخال/الإخراج ستصبح مواضع تعثر في ظل التحميل.
بالنسبة لإعداد خادم الإنتاج للاتصال المتعدد، نوصي باستخدام بطاقة SSD بسعة تخزين 50 جيجابايت على الأقل وذاكرة وصول عشوائي تصل إلى 4 جيجابايت ووحدة معالجة مركزية ثنائية النواة في كل حاويات Coreapp/Master/Webapp.
في معظم الحالات، يجب عليك تشغيل قاعدة البيانات على خادم فعلي منفصل من الحاويتين core وweb. ويجب ألا يتأخر خادم قاعدة البيانات في وقت الاستجابة عن بضعة مللي ثوانٍ من جهاز (أجهزة) الكمبيوتر.
تدعم عملية الإعداد هذه إرسال 20 رسالة تقريبًا لكل ثانية.
يلزم توفير MySQL بالإصدار 5.7.x، وتوفير PostgreSQL بالإصدار 9.5.x أو 9.6.x أو 10.x. وسيؤدي استخدام الإصدار السابق إلى ظهور الخطأ Unable to initialize config store
.
يمكنك إعداد MySQL محليًا باستخدام Docker من خلال اتباع دليل MySQL في Docker.
يمكنك إعداد PostgreSQL محليًا باستخدام Docker من خلال اتباع دليل PostgreSQL في Docker.
في معظم الحالات، يجب عليك تشغيل قاعدة البيانات على خادم فعلي منفصل من الحاويتين core وweb. ويجب ألا يتأخر خادم قاعدة البيانات في وقت الاستجابة عن بضعة مللي ثوانٍ من جهاز (أجهزة) الكمبيوتر.
يمكن إنشاء قائمة سماح من خلال الأسماء المضيفة أو عناوين IP.
لمزيد من المعلومات، يمكنك الرجوع إلى قسم الأسماء المضيفة في وثائق متطلبات الشبكة.
نعم، يلزم إجراء اتصال TCP. وإذا لم يتمكّن نشاطك التجاري من فتح منافذ إضافية، فمن ثمّ يمكنك استخدام بروتوكول SSL تم إنهاؤه.
لمزيد من المعلومات، يمكنك الرجوع إلى وثائق متطلبات الشبكة.
لا، ولا ندعم KOPS. ولكننا ندعم حل خدمات الويب من Amazon (AWS) استنادًا إلى ECS. ويتوفر لدينا أيضًا إعداد Kubernetes minikube عام.
يتم دعم MySQL وPostgreSQL. وفي حالة تشغيل Docker بنفسك، يجب عليك توفير قاعدة البيانات MySQL/PostgreSQL للحاويات بغرض الاتصال بها. ويؤدي استخدام قالب خدمات الويب من Amazon (AWS) إلى إعداد قاعدة بيانات MySQL افتراضيًا.
لا، لا يعمل عميل واجهة API واتساب للأعمال حاليًا على Docker في Windows. ولتلبية احتياجات التطوير، يكون الحل الموصى به هو استخدام جهاز ظاهري يعمل بنظام التشغيل Linux وتشغيل Docker فيه. وبالنسبة لأحمال العمل، نوصي باستخدام خادم يعمل بنظام التشغيل Linux لتجنب حدوث مشكلات في التوافق والأداء.
يمكنك إعادة تشغيل حاويات Docker من خلال تشغيل الرمز البرمجي التالي:
docker restart wacore<Current_WABA_Version>
docker restart webapp<Current_WABA_Version>
يمكنك التحقق من الإصدار الذي تستخدمه
docker ps
نعم، تتمتع ميزة تدوير السجل في حاويات webapp وحاويات coreapp بسلوكيات مختلفة اختلافًا طفيفًا:
يوجد برنامج نصي يمكن تشغيله خارجيًا لمسح السجلات القديمة من الحاوية:
docker exec CONTAINER_NAME /opt/whatsapp/bin/cleanup.sh
يستخدم البرنامج النصي الحاويتين webapp وcoreapp. وعند تشغيل البرنامج النصي، ستتم إزالة ملفات السجل القديمة بحيث لا يبقى سوى 30 ملف سجل في الحاوية فقط.
قد يبدأ نظامك في العمل ببطء نظرًا لأن المساحة ممتلئة. ويمكن أن يرجع ذلك إلى وجود العديد من ملفات الوسائط والرسائل وملفات السجل كبيرة الحجم. علمًا بأنه يتم تدوير ملفات السجل تلقائيًا، ولكن إذا بدأ حجمها يزيد، فيكون حذفها إجراءً آمنًا.
يتم تخزين الرسائل في قاعدة البيانات. ويمكنك حذفها عند الضرورة. كما أنه إذا تم تعيين pass_through
إلى القيمة خطأ في إعدادات التطبيق، فمن ثمّ يتم حفظ كل الرسائل في قاعدة البيانات حتى يتم حذفها صراحة.
يتم تنزيل ملفات الوسائط التي يرسلها المستخدمون إليك إلى وحدات تخزين الوسائط. ويتعين على النشاط التجاري اتخاذ قرار بشأن تحديد ملفات الوسائط المطلوب حذفها، ولكن بشكل عام يكون حذف أي ملف وسائط إجراءً آمنًا. ويمكنك استخدام docker inspect your-container-id
للتحقق من مكان وجود مجلد وحدة تخزين الوسائط.
نعم، يمكن استخدام قاعدة البيانات بطرق أخرى دون المساس بالجداول المتعلقة بواتساب.
تخزن جداول قاعدة البيانات المعلومات المتعلقة بإعدادات التطبيقات وسلسلة رسائل الدردشة والرسائل والوسائط وإلخ والمطلوبة جميعها من التطبيق ليتم تشغيله.
يعمل الإصدار v2.25.x
على تحسين الأداء الصادر والوارد عبر الإصدارات السابقة. ويعتمد هذا التحسين على إنشاء اتصالات إضافية بقاعدة البيانات. وبالنسبة لبعض عمليات النشر، قد يتسبب ذلك في زيادة عدد الاتصالات بقاعدة البيانات والوصول إلى التقييدات التي تم تكوينها. للحفاظ على الأداء المتزايد، يمكنك زيادة الحد الأقصى لعدد الاتصالات التي يمكن لخادم قاعدة البيانات قبولها. إذا لم يكن ذلك ممكنًا، يمكنك تغيير المعلمة axolotl_context_striping_disabled لتعطيل هذا السلوك. ولمزيد من المعلومات حول كيفية إجراء هذا التغيير، يمكنك الرجوع إلى وثائق إعدادات التطبيقات.
تقوم مجموعة البيانات المهملة في قاعدة البيانات بتنظيف الجدولين messages
وmessages_reciept_log
بشكل دوري للمساعدة في إدارة قاعدة البيانات.
يحتفظ جامع البيانات المهملة برسائل معينة للسماح بعملية عرض/معالجة ناجحة. فعلى سبيل المثال، الاحتفاظ بالرسائل الواردة لفترة زمنية معينة للسماح لعمليات دمج الأعمال بتحديد الرسائل كمقروءة.
يجمع Coreapp البيانات المهملة على فترات زمنية عشوائية (أي كل بضع ساعات). ويحدث ذلك لمنع لنخفاض الأداء المحتمل في مكدسات التوفّر العالي بسبب اتصال قاعدة البيانات.
تكون مجموعة البيانات المهملة مستقلة عن قائمة انتظار الاستدعاء. فعلى سبيل المثال، في حالة عدم توفّر خادم حدث Webhook لمدة أربعة أيام، سيتم تخزين الاستدعاءات لعرضها عند استعادة اتصال خادم حدث Webhook.
استخدم نقطة النهاية في واجهة services
API الخاصة بجمع البيانات المهملة في قاعدة البيانات لإزالة الرسائل وإيصالات الرسائل المقابلة من الجدولين messageStore.messages
وmessageStore.messages_receipt_log
.
في حالة نسخ عملية إعدادك الحالية احتياطيًا واستعادتها على الجهاز الجديد، يجب نقل معلومات التسجيل مع بقية إجراءات التنفيذ لديك. ولمزيد من المعلومات، راجع وثائق النسخ الاحتياطي والاستعادة.
سيؤدي تسجيل خروج مستخدم عبر نقطة النهاية users
إلى إبطال كل الرموز المميزة للمصادقة والتي تم تعيينها إلى هذا الحساب. وسيتمتع حذف أحد المستخدمين بالتأثير نفسه، على الرغم من أن هذا الإجراء أكثر حدة. عليك أن تضع في اعتبارك أن تسجيل دخول أي مستخدم عبر نقطة النهاية users
سيؤدي إلى إرجاع رمز مميز جديد للمصادقة، ولكنه لن يؤدي إلى إبطال الرموز المميزة للمصادقة المُستخدمة بالفعل لهذا المستخدم. علمًا بأنه سيظل بإمكان أي شخص لديه رمز مميز تم توفيره مسبقًا استخدام هذا الرمز المميز حتى تنتهي صلاحيته أو يتم إبطاله عبر أحد الأساليب المذكورة مسبقًا.
ملاحظة: يرجى عدم إرسال الرسالة نفسها بشكل متكرر إلى المستلم نفسه الذي يستخدم API واتساب للأعمال.
يمكن أن تكون هناك أسباب متعددة تكمن وراء عدم وصول معدلات الإرسال إلى 100%. تتضمن بعض الحالات الشائعة وصول المستخدمين بشكل متقطع إلى الشبكة أو عدم نشاطهم لفترة من الوقت أو إنشاء تجربة مستخدم عالية الجودة.
الرسائل التي يمكن إرسالها باستخدام واتساب ستتمتع بمعدل إرسال عال جدًا. ومع ذلك، يوجد العديد من الأسباب التي تكمن وراء احتمالية عدم إرسال أية رسالة. ستتمتع بإمكانية الوصول إلى حالة الرسالة بدقة من خلال التحقق من عمليات الاستدعاء لديك. يختلف هذا الأمر عن إرسال الرسائل باستخدام رسالة SMS، فعلى سبيل المثال حيث لا تتمتع بإمكانية الوصول إلى حالة الإرسال النهائية وقد ينتج عن إعادة إرسال الرسالة نتائج مختلفة بالفعل.
قد تظل الرسائل غير مُرسلة نظرًا لأن هاتف المستخدم يكون خارج الخدمة أو البطارية نفدت أو تعرض الهاتف للفقدان وحصل المستخدم على هاتف جديد وقام بتعطيل بطاقة SIM الخاصة به. ومن الممكن ظهور أخطاء في إمكانية عميل النشاط التجاري للاتصال بالشبكة. كما أنه من الممكن عدم إرسال عمليات الاستدعاء (Webhooks). يمكنك التحقق من هذه الحالات من خلال استخدام العقدة health
. ويمكنك تشغيل عمليات استدعاء إيصال الخادم لمعرفة أنه تم إرسال الرسالة إلى سحابة خادم واتساب.
كلما وحينما يعيد المستخدم الاتصال بالشبكة، سيتم إرسال كل الرسائل التي أرسلتها إليه. وسيمثل تلقي أكثر من رسالة واحدة تتضمن المحتوى نفسه تجربة سيئة بالنسبة له. ومن المرجح أنه سيحظرك أو يقدم شكوى. ولكن من المرجح أنه سيتم حظرك.
إذا أرسلت رسالة وتلقيت معرف رسالة من واجهة API، فقد اتخذت الإجراءات اللازمة لإرسال هذه الرسالة. ولا تعيد إرسال المحتوى نفسه إلى المستلم نفسه.
إذا كنت تشهد معدلات إرسال منخفضة على مدار فترة زمنية طويلة، فيرجى تقديم تذكرة دعم من خلال الدعم المباشر.
عند إرسال رسالة بمجرد استرداد معرف الرسالة، يعني ذلك أنه تم تخزين طلب الرسالة في قاعدة البيانات. وسيظل عميل واجهة API واتساب للأعمال يحاول إرسال هذه الرسالة حتى يتم الاعتراف بها من قِبل خادم واتساب. ولا تتضمن هذه العملية أي مخطط زمني للإنهاء. ومن ثمّ، سيحاول خادم واتساب إرسال هذه الرسالة إلى هاتف المستخدم. وإذا لم يكن هاتف المستخدم متصلاً، فسيتم تخزين الرسالة لمدة 30 يومًا قبل تجاهلها من قِبل خادم واتساب.
لا تتوفر أية طريقة حاليًا لمعرفة عدد المستخدمين الذين حظروا نشاطك التجاري أو لتحديدهم. ولكن المؤشر الأفضل هو الاستجابة لعمليات استدعاء الحالة وإذا لم تتلق الحالة delivered
، فمن ثمّ يكون المستخدم قد حظر نشاطك التجاري أو أن المستخدم لا يتمتع باتصال بالشبكة. ولمزيد من التفاصيل، راجع وثائق Webhook.
إذا كان المستخدم قد حظر نشاطك التجاري، فستظل واجهة API جهات الاتصال تقوم بإرجاع رقم الهاتف هذا باعتباره مستخدم واتساب صالح. ومع ذلك، عندما ترسل الرسالة، لن يتم إرسالها أبدًا. وإذا كانت رسالة مدفوعة، فلن يتم تحصيل أي رسوم منك.
في سيناريو المستهلك العادي، يرجع ذلك إلى التصميم عندما لا يكون المُرسل موجودًا في دفتر العناوين الخاص بك ولم ترسل أية رسالة إلى هذا المُرسل في السابق. أما في سيناريو المؤسسة، يجب أن يستخدم النشاط التجاري قوالب الرسائل عند تفاعل المستخدم لأول مرة من أجل تعزيز "الثقة" ومن ثمّ سيؤدي إجراء ذلك إلى التزام عميل واجهة API واتساب للأعمال بإعداد التنزيل التلقائي داخل التطبيق.
في سيناريو المستهلك العادي، يرجع ذلك إلى التصميم عندما لا يكون المُرسل موجودًا في دفتر العناوين الخاص بك ولم ترسل أية رسالة إلى هذا المُرسل في السابق. أما في سيناريو المؤسسة، يجب أن يستخدم النشاط التجاري قوالب الرسائل عند تفاعل المستخدم لأول مرة من أجل تعزيز "الثقة" ومن ثمّ سيؤدي إجراء ذلك إلى إمكانية قيام عميل واجهة API واتساب للأعمال بعرض الرابط وجعله قابلاً للنقر عليه.
بالتأكيد! يمكنك التواصل مع ممثل WhatsApp لديك وإجراء هذا الطلب.
لا، لا يتم ضمان أن يكون الترتيب الذي تم به تلقي الرسائل هو الترتيب نفسه المُستخدم عند إرسال الرسائل. وإذا كانت عملية الترتيب تمثل أمرًا مهمًا بالنسبة لحالة استخدامك، فسيكون النهج المُقترح هو الاستجابة للاستدعاء المعروض الخاص بالرسالة الأولى قبل بدء إرسال الرسالة الثانية.
عند استخدام العقدة messages
، تحتاج إلى تعيين العنوان Content-Type
إلى application/json
في عميل واجهة API واتساب للأعمال من أجل تحليل نص الرسالة بشكل مناسب. كما يتوفر عنوان Authorization
الذي يلزم تعيينه ويجب أن يحتوي على رمز وصول غير منتهي الصلاحية. وللحصول على معلومات حول كيفية الحصول على الرمز المميز ووقت انتهاء صلاحيته، راجع وثائق تسجيل الدخول والمصادقة.
نعم، يجب عليك إرسال استدعاء واجهة API إلى العقدة contacts
قبل إرسال أية رسالة. ويتم تخزين المعلومات الواردة من التحقق من contacts
مؤقتًا في الحاوية وقد يؤدي عدم إجراء ذلك إلى ظهور خطأ Unkown Contact
. ولمزيد من المعلومات، راجع وثائق التحقق من جهات الاتصال.
If there is a delay in a subset of numbers, then it is likely not an issue affecting the customers integration but rather an issue on the recipients end, these delays in delivery can happen for a number of reasons. See Send Message Performance, Delays for more information.
No this is not possible. Numbers that are registered under WABAs (WhatsApp Business Accounts) can only message regular WhatsApp accounts.
لا تتوفر آلية تنظيف تنطبق على ملفات الوسائط الصادرة أو الواردة. ويجوز لك حذف ملفات الوسائط يدويًا من خلال تحديد موقعها على نظام الملف لديك.
للعثور على نقطة تحميل وحدة تخزين الوسائط الخاصة بك، يمكنك تشغيل أمر docker.
docker volume inspect whatsappMedia
[ { "Driver": "local", "Labels": {}, "Mountpoint": "/var/lib/docker/volumes/whatsappMedia/_data", "Name": "whatsappMedia", "Options": {}, "Scope": "local" } ]
بعد ذلك، لعرض كل ملفات الوسائط الواردة، يمكنك تشغيل الأمر ls
باستخدام مسار الملف Mountpoint
الذي تم تلقيه:
ls /var/lib/docker/volumes/whatsappMedia/_data/
عند إعداد خدمات الويب من Amazon (AWS)، يتم تحميل وحدة تخزين الوسائط إلى المسار /mnt/wa/media
في المضيف.
يكون الحد الأقصى لحجم تحميل الملف 64 ميجابايت مما يعني أن هذا التقييد أيضًا ينطبق على أية صورة أو مستند أو فيديو ترسله مع الرسالة.
يكون أمر تحديد الوقت الذي يتعين خلاله حذف الوسائط متروكًا لك.
بعد تحميل الوسائط، ستتلقى معرف وسائط يمكنك استخدامه لإرسال رسالة تتضمن عنصر الوسائط الذي تم تحميله. وعند إرسال رسالة الوسائط، ستقوم واجهة API واتساب للأعمال بتشفير الوسائط وتحميلها إلى خوادم واتساب حيث ستظل محفوظة بها لمدة 14 يومًا. وبعد ذلك، يمكنك تحديد وقت حذف الوسائط من خلال توفير معرف الوسائط أو الاحتفاظ به لاستخدامه لاحقًا. رغم أننا نوصي بالاحتفاظ بالوسائط لمدة 30 يومًا، يكون أمر تحديد سياسة الاحتفاظ متروكًا لك بناءً على حالة الاستخدام أو السياسة الخاصة بنشاطك التجاري.
بالنسبة للصور، ستتم إضافة الشرح التوضيحي باعتباره وصفًا. ويظهر نص الشرح التوضيحي بالكامل في الصور على نظام التشغيل Android وهاتف iPhone.
بالنسبة للمستندات، يحل الشرح التوضيحي محل اسم الملف. ولا يعني ذلك أن يكون معروضًا على جهاز المستخدم باعتباره نصًا للوصف، وإنما من أجل عرض اسم الملف. علمًا بأن هواتف iPhone تعرض النص بالكامل، بينما تقتطع أنظمة التشغيل Android اسم الملف بحيث يكون ذلك تقييدًا تقنيًا في تنفيذ واتساب حاليًا على هذين الجهازين.
عند إرسال صورة كألبوم من واجهة API الخاصة بتطبيق WhatsApp للأعمال، ستحتاج إلى إرسال أربع صور على الأقل على التوالي. وإذا كانت طريقة عرض المحادثة الخاصة بالمستخدم نشطة حاليًا عند تلقي الصور، فمن ثمّ تكون طريقة عرض الألبوم غير متاحة حتى الزيارة التالية.
لن يتم إنشاء ألبوم في حالة تلبية أحد المعايير التالية:
لا، يجب أن نستخدم حاليًا نظام AWS EFS لمشاركة وحدة تخزين الوسائط بين Coreapp وWebapp.
لا، لا ندعم حاليًا تغيير المسار الافتراضي إلى تخزين الوسائط (/usr/local/wamedia/). ويجب أن تكون جميع وحدات تخزين الوسائط في هذا الموقع الافتراضي حتى تعمل بشكل صحيح.
المدة الحالية هي 7 أيام. وإذا لم يتم تحديث التخزين المؤقت لمدة تزيد عن 7 أيام، فسيسحب آخر حزمة لغة من الخادم بغض النظر عما إذا كان العنصر موجودًا بالفعل في الحزمة أم لا.
لاحظ أنه: يتم إيقاف استخدام سياسة لغة fallback
بداية من الإصدار v2.27.8
وأن سياسة لغة deterministic
هي السياسة الافتراضية حاليًا.
إذا كنت تنشئ ترجمة بلغة جديدة، فتحتاج إلى ترجمة كل العناصر التي تستخدمها إلى هذه اللغة. وبخلاف ذلك، قد تحصل على الأخطاء "عدم توفر البنية" نظرًا لأنه يتعذر على هاتف المستلم العثور على عنصر يتوقعه للغة التي يستخدمها. وتظهر أخطاء عدم توفر البنية هذه عند إرسال رسائل القوالب باستخدام سياسة اللغة الاحتياطية.
إذا لم يكن إنشاء ترجمات اللغة هو أحد الخيارات المتاحة لديك حاليًا، يمكنك استخدام سياسة اللغة المحددة لتجنب ظهور هذه الأخطاء.
يرسل عميل واجهة API واتساب للأعمال عمليات استدعاء Webhook إليك عبر الحاوية Coreapp. ولذلك، يلزم تكوين نقطة النهاية Webhook لقبول الطلبات الواردة من الحاوية Coreapp.
في حالة فشل Webhook في إرسال استدعاء، يتم وضع الاستدعاء في قائمة انتظار إعادة المحاولة. ولن يتم تلقي أية عمليات استدعاء مُرسلة بعد فشل الاستدعاء الأولي. ويتم ذلك فقط بعد أن ينجح الاستدعاء الأولي الذي فشل في أنه سيقوم البقية بالمتابعة.
في حالة عدم عرض حدث Webhook لأي سبب (مثل، العميل غير متصل) أو في حالة قيام طلب Webhook بإرجاع الرمز البرمجي لحالة HTTP بخلاف 200
، سنعيد محاولة عرض webhook. وسنستمر في إعادة محاولة العرض مع زيادة مدة التأخير إلى انتهاء مهلة زمنية محددة (بصفة أساسية لمدة 24 ساعة على الرغم من احتمالية اختلاف هذه المدة) أو حتى تنجح عملية العرض.
يمكن إرسال رسائل مكررة إلى Webhook في واتساب نظرًا لأن الضمان الوحيد المتوفر هو أنه سيتم تلقي الرسائل مرة واحدة على الأقل (في مقابل مرة واحدة بالضبط). وإذا كان ذلك يؤثر على طريقة معالجة الرسائل من جانبك، فمن ثمّ نقترح إلغاء تكرارات رسائل Webhook استنادًا إلى معرف الرسالة.
تحقق مرة أخرى من إعداد التطبيق pass_through
. ولن تتلقى أي عمليات لمعاودة اتصال حالة القراءة إذا قمت بتمكين pass_through
مع عميل واجهة API الخاصة بتطبيق WhatsApp للأعمال بالإصدار v2.29.1
أو الإصدارات الأحدث.
إذا كنت تريد تلقي معاودة اتصال حالة القراءة، فقم بتعطيل إعداد التطبيق pass_through
. ولاحظ أنه عند تعطيل pass_through
، قد تزداد مساحة تخزين قاعدة البيانات سريعًا. ولمزيد من المعلومات حول إدارة قاعدة البيانات، يمكنك الرجوع إلى وثائق إدارة قاعدة البيانات.
ينجم ذلك عن حدوث خطأ في أحد الإصدارات القديمة لعميل نظام iOS. ونتوقع انخفاض معدل الأخطاء مع مرور الوقت بسبب ترقيات المجموعة العامة.
تحقق أولاً من عمليات الاستدعاء بحثًا عن أخطاء فادحة لتشخيص المشكلة.
في حالة ظهور "تعارض: تم الكشف عن مثيلات متعددة تشارك الرقم نفسه"، تحتاج إلى التحقق من الحاويات المتوفرة لديك. ويرجع السبب الأرجح في ذلك إلى أن لديك العديد من حاويات Docker التي تحاول الاتصال بخوادم واتساب باستخدام حساب واتساب نفسه. تأكد من أن لديك حاوية واحدة فقط تعمل وقيد التشغيل. وإذا كانت لديك حاويات قديمة، فأوقف تشغيلها وسيختفي هذا الخطأ.
إذا كنت تريد اختبار حل الإتاحة العالية الأكثر تعقيدًا، فراجع وثائق الإتاحة العالية.
هذه مشكلة معروفة. كما تتطلب أحيانًا ترقية عميل واجهة API واتساب للأعمال التي تستخدم البرامج النصية CloudFormation تحديثًا إلى مكدس قاعدة بيانات RDS. ولن يتمتع مكدس RDS الجديد باسم المضيف نفسه باعتباره المكدس الأصلي ولا تتمكّن حاويات Docker من الاتصال بقاعدة البيانات. والحل هو إدخال بروتوكول SSH في مثيل EC2 الذي أنشأه CloudFormation وتحديث الملف whatsapp.conf
باستخدام اسم المضيف الجديد، ثم إعادة تشغيل حاويات Docker بحيث يمكنها اختيار الإعدادات الجديدة.
يظهر هذا الخطأ عندما لا يتم إعداد قاعدة البيانات بشكل صحيح.
يحدث ذلك في حالة تلف جسر Docker. وأفضل طريقة لتصحيح هذا الخطأ هي إيقاف خدمة Docker والبدء من جديد. كما يمكنك محاولة استخدام docker restart
بالحاويات لديك.
قد يعني الخطأ "الاتصال مرفوض" أن الحاوية Coreapp لا تعمل. ويمكنك استخدام docker ps
لمعرفة ما إذا كانت الحاوية Coreapp تعمل أم لا. وإذا كانت لا تعمل، فسيمكنك إلقاء نظرة على سجلات Docker. وقد يتعذر على الحاوية Coreapp الاتصال بقاعدة البيانات. لذا تأكد من إعداد قاعدة البيانات بشكل صحيح.
يرجع ذلك إلى العديد من الأسباب. فقد تكون الحاوية Coreapp مُعطلة أو لم يتم إعداد قاعدة البيانات بشكل صحيح. وإذا لم تكن هذه هي الحالة، فيرجى إلقاء نظرة على سجلات Coreapp لديك (أو سجلات Coreapp الرئيسية إذا كنت تستخدم الاتصال المتعدد). وفي حالة ظهور أخطاء في الاتصال بقاعدة البيانات، من المحتمل أن قاعدة البيانات تنفد من الاتصالات. يمكنك الرجوع إلى مستند MySQL أو مستند PostgreSQL بشأن هذا الخطأ.
نوصي بزيادة عدد الاتصالات بقاعدة البيانات في قاعدة البيانات لديك. ويجب أن يمثل العدد 1000 اتصال بقاعدة البيانات رقمًا آمنًا، ولكن يرجى اتخاذ قرار سليم من جانبك بشأن عدد الاتصالات. أما في حالة استمرار ظهور الخطأ، يرجى فتح تذكرة دعم.
في حالة ظهور هذا الخطأ ومع ذلك يتم تعيين المعلمة المطلوبة المفقودة التي يشير إليها هذا الخطأ في نص بلغة json، قد يكون ذلك خطأ في تحليل json. ويمكن ظهور هذا الخطأ عندما تكون حمولة بيانات json بالكامل غير قابلة للتحليل بسبب حدوث أخطاء في تنسيق json. يمكنك التحقق من قيم هذه المعلمات الخاصة بأحرف json غير الصالحة، مثل حالة رجوع إلى أول السطر في النهاية. ويمكن أحيانًا نسخ المعلمات بالمسافات البيضاء الزائدة والتي قد تتضمن أحرفًا تمثل فاصلاً في لغة json.
تحدث أخطاء عدم توفر البنية عندما لا يتمكن الهاتف من قراءة رسالة القالب.
يتم تخزين القوالب على الخادم. عندما يتم إرسال رسالة قالب باستخدام العقدة messages
، لن يتم إرسال إلامساحة الاسم واللغة واسم العنصر والمعلمات المحلية إلى الهاتف وليس الرسالة بأكملها. بمجرد إرسال هذه القيم إلى الهاتف، فإنه يحاول عرض الرسالة.
إذا حدثت أي أخطاء أثناء العرض، فسيتم إرسال خطأ structure unavailable
إلى عنوان URL الاستدعاء الذي يحتوي على المستلم ومعرف الرسالة. يمكن أن تحدث هذه الأخطاء بسبب خطأ في مساحة الاسم أو عدم تطابق المعلمة المترجمة أو خطأ في اسم العنصر، إلخ.
انتقل إلى مدير WhatsApp الموجود في مدير الأعمال من Facebook لعرض عدد المعلمات الصحيح. وتحقق مرة أخرى من أن مساحة الاسم صحيحة وأن اسم العنصر موجود.
يتمثل أحد المصادر الشائعة للأخطاء في عدم إنشاء ترجمات لكل القوالب المُستخدمة. فعلى سبيل المثال، إذا كان لديك قالبان ترسلهما بشكل عام وتضيف ترجمة لغة جديدة لأحدهما، فيرجى التأكد من إضافة ترجمة اللغة الجديدة هذه للقالب الآخر أيضًا. إذا كنت تخطط لدعم أكثر من لغة، فستحتاج إلى توفير ترجمات لكل القوالب بكل اللغات المدعومة.
الأمر الجيد أنه عادةً ما تكون أخطاء structure unavailable
هي بسبب وجود أخطاء في استدعاء API messages
ويمكن إصلاحها عن طريق تغيير حمولة بيانات الإرسال.
تحتاج أولاً إلى التحقق مما إذا كانت جهة الاتصال موجودة أم لا قبل إرسال أية رسالة. ولمزيد من المعلومات حول كيفية إجراء ذلك، راجع وثائق جهات الاتصال.
يرجع ظهور هذا الخطأ إلى أنه لم تتم تهيئة Coreapp بعد. ويعني ذلك أنه قد لم يتم التسجيل بنجاح. لذا يرجى محاولة التسجيل قبل إجراء استدعاء إلى نقطة نهاية أخرى. وتكون الخطوة الأولى بعد تثبيت واجهة API واتساب للأعمال هي تسجيل الدخول. أما الخطوة الثانية، فتكون التسجيل. ويلزم تنفيذ هاتين الخطوتين قبل إجراء طلبات إلى نقاط نهاية أخرى.
تتمتع كل إصدارات عميل واجهة API واتساب للأعمال بصلاحية لمدة 6 أشهر من تاريخ الإصدار. وفي حالة ظهور هذا الخطأ، قم بالترقية إلى آخر إصدار تم إطلاقه في أقرب وقت ممكن.
يشغّل واتساب تجارب لقياس تأثير إشعارات واجهة API واتساب للأعمال وإدراكه في تجربة المستخدم والمنتج الكلي بوجه عام. وإذا كان المستخدم الذي تراسله موجودًا في إحدى هذه التجارب، فقد لا يتلقى أي إشعارات منك حتى إذا كان موافقًا على تلقي هذه الإشعارات.
إذا كنت تتلقى خطأ مشابهًا للخطأ التالي عند إعداد نشر خدمات الويب من Amazon (AWS)، فحاول تغيير الاسم إلى اسم تجميع يستخدم 8 أحرف أو أقل.
اسم البلد (رمز مكوّن من حرفين) [أستراليا]:اسم الولاية أو المقاطعة (الاسم بالكامل) [بعض الولايات]:اسم المنطقة (مثل المدينة) []:اسم المؤسسة (مثل الشركة) [شركة Internet Widgits Pty Ltd]:اسم وحدة المؤسسة (مثل القسم) []:الاسم الشائع (مثل اسمك أو اسم FQDN للخادم) []:السلسلة طويلة للغاية ويجب أن يقل طولها عن 64 بايت الاسم الشائع (مثل اسمك أو اسم FQDN للخادم) []:عنوان البريد الإلكتروني []:الخطأ، لم يتم تحديد أي كائنات في ملف التكوين، مشكلات تؤدي إلى إنشاء طلب الشهادة، مفتاح الجهاز في internal-wa-inc-name-LB-123456789.ap-southeast-1.elb.amazonaws.com
سيتم إرجاع كائن profile
فارغ فقط في حالة ملء الملف الشخصي للنشاط التجاري جزئيًا. ويرجى الترقية إلى v2.21.4
لحل هذه المشكلة.
لمزيد من المعلومات حول إكمال الملف الشخصي للنشاط التجاري، راجع وثائق إعدادات الملف الشخصي لنشاط تجاري.
يتعلق الرمز البرمجي للخطأ 471
بتقييدات معدلات الاستدعاء القائمة على الجودة. ولمزيد من المعلومات، راجع وثائق تقييدات معدلات الاستدعاء القائمة على الجودة.
فيما يلي أخطاء متعلقة بالتحقق من الصحة من جانب إرسال قالب الرسالة وسبب احتمالية ظهورها لك:
template
. ولمزيد من المعلومات، يمكنك الرجوع إلى وثائق قوالب رسائل الوسائط.بالنسبة لعميل واجهة API واتساب للأعمال الذي يعمل بالإصدار 2.21.6، عند قطع اتصال العميل عن الخادم، فقد يظل الاتصال مقطوعًا لبضع دقائق (4 دقائق كحد أقصى) وبعد ذلك ستتم إعادة محاولة الاتصال. ستسمح الترقية إلى الإصدار 2.23.4 بوجود فترة تعطل أقل للعميل عند محاولة الاتصال بالخادم.
قبل الإصدار v2.29.x
، كان من المحتمل أن يزداد حجم قائمة انتظار الرسائل الصادرة مع مرور الوقت بسبب خطأ. وتحل الترقية إلى الإصدار v2.29.3
هذه المشكلة.
ستحقق عقدة Coreapp من الدليلين /usr/local/waent/data
و/usr/local/waent/log
ضمن حاوية Coreapp مما يضمن توفّر 10 ميجابايت من مساحة التخزين على الأقل، وإلا فسيظهر هذا الخطأ الفادح.
تحقق من السجلات ودليل البيانات للتأكد من أن لديك مساحة تخزين كافية.
لا تتوفر حاليًا أية طريقة لإجراء ذلك. وإذا لم تكن قادرًا على معالجة الاستجابات الواردة من المستخدمين لديك عبر واتساب، فإننا نقترح إرسال رسالة رد تلقائي بحيث تعيد توجيههم إلى قنوات الدعم المناسبة لديك.
يجب عليك تسجيل رقم هاتف ثان وتدوير مكدس CloudFormation ثان أو مثيل Docker لإجراء الاختبار. وإذا كان لديك اثنان من عملاء واجهة API واتساب للأعمال النشطة والتي تستخدم رقم الهاتف نفسه، فسيرفضك الخادم نظرًا لوجود تعارض في مفاتيح التشفير. كما نوصيك بتوفير بيئة ثانية يمكنك استخدامها لاختبار مثيل غير الإنتاج قبل إجراء أحد أنواع الترحيل على عميل الإنتاج.
تتوفر ميزة التحقق من الحالة مجانًا ويمكن الاستعلام عنها كلما لزم الأمر.
للتعرف على المزيد حول إحصاءات قاعدة البيانات والتطبيق التي يمكنك الاستعلام عنها، يمكنك الاطلاع على وثائق الإحصاءات. تكون إحصاءات التطبيق مخزّنة في الذاكرة وتتوفر بتكلفة زهيدة للاستعلام عنها. وتتطلب إحصاءات قاعدة البيانات المزيد من الموارد ولا يجب الاستعلام عنها إلا عند الضرورة.
لم يتلق نشاطك التجاري إشعارًا عندما يقوم أحد العملاء بتغيير رقم هاتفه على واتساب. وعندما تستخدم العقدة contacts
، سيكون هذا الرقم بالحالة invalid
.
إذا أصبح رقم هاتف العميل غير نشط ولكن العميل لا يزال يستخدم واتساب، فسيظل العميل يتمتع بإمكانية الوصول إلى واتساب حتى/إذا تمت إعادة تعيين أو إعادة تسجيل رقم الهاتف.
يتحقق واتساب بشدة مما إذا كان الرقم المتوفر ينتمي بالفعل إلى الهاتف أم لا. علمًا بأن حقيقة أن المستخدم يتمتع بحساب على واتساب تمثل دليلاً بأنه أكّد الرقم وبالتالي لم يستخدم أي شخص آخر هذا الرقم للتسجيل على واتساب. ومع ذلك، لا يشكّل ذلك ضمانًا للموقع الفعلي لبطاقة SIM.
من ناحية أخرى، إذا تعرض هاتف المستخدم للفقدان أو السرقة، يمكنه إلغاء تنشيط حسابه على واتساب. وللاطلاع على المزيد حول الطريقة التي يتبعها المستخدمون لإلغاء تنشيط حسابهم، راجع الأسئلة المتكررة حول الهواتف المفقودة والمسروقة.
لا، لا توجد طريقة لاستخدام واجهة API واتساب للأعمال من أجل الكشف عن العديد من الأجهزة التي تستخدم الرقم نفسه.
يمكن أن تكون حمولة بيانات الرسالة من مستخدم عبارة عن رسالة نصية أو ملف وسائط.
بالنسبة للرسالة النصية، من غير المعتقد أنه يوجد خطر محدد.
بالنسبة لملفات الوسائط:
auto_download
إلى مصفوفة فارغة. يرجى الاتصال بالدعم وتقديم أي معلومات لديك. وسنحقق في الأمر ونوقف تشغيل أي أرقام زائفة.
بدءًا من الإصدار 2.18.26، تسمح نقطة نهاية إحصاءات التطبيق بتصدير أدوات القياس الداخلية بتنسيق نص Prometheus. ولمزيد من المعلومات، راجع وثائق التحقق من المثيل.
يتطلب عميل API داخل المواقع في واتساب للأعمال توفير قاعدة بيانات لمفاتيح المتاجر لفك تشفير الرسائل المرسلة بين نشاط تجاري والعملاء. يتم تشفير كل الرسائل على واتساب باستخدام مفاتيح المرسِل والمستلِم. يتم تخزين مفاتيح العميل على جهازه المحمول ويتم تخزين مفاتيح النشاط التجاري في قاعدة بيانات النشاط التجاري. تعرَّف على المزيد حول أمان واتساب.
تمثل API سحابة في واتساب للأعمال حلاً بديلاً حيث تستضيف Meta خلالها قاعدة بيانات النشاط التجاري. تتيح لك API السحابة تنفيذ واجهات API واتساب للأعمال بدون تكلفة استضافة خوادمك الخاصة. معرفة المزيد.