إذا تلقيت رسالة خطأ مثل "عذرًا، حدث خطأ" وتواجه مشكلة في تحديد السبب، يمكن بشكل اختياري تمكين عرض رسائل أخطاء أكثر تفصيلاً تعرض معلومات يمكن اتخاذ قرارات بشأنها. تتوفر المزيد من الوثائق عن طريقة init() لإضافة إشارة تصحيح الأخطاء إلى مجموعة SDK في https://developers.facebook.com/docs/accountkit/webjs/reference

تعمل ميزة التحقق الفوري لخدمة Account Kit على تفادي الحاجة إلى الحصول على رمز تحقق عبر إرسال SMS عند إدخال مستخدم Android رقم هاتف مطابق للرقم المسجل على فيسبوك.

وهذا متاح فقط إذا كان الشخص يستخدم تطبيق فيسبوك لنظام Android. إذا تعذر علينا التأكد من تطابق الرقمين، يتم توجيه الشخص إلى الدفق العادي ويتلقى رمز تحقق عبر رسالة SMS.

ستعرض Account Kit واجهة مستخدم متوفرة باللغات الموجودة في هذه القائمة: https://developers.facebook.com/docs/accountkit/languages.

يرجى زيارة الرابط التالي للاطلاع على قائمة حديثة بالبلدان ورموز الاتصال المدعومة:https://developers.facebook.com/docs/accountkit/countrycodes.

لا، نحن ندعم فقط ربط اللغة JavaScript عبر https://sdk.accountkit.com/en_US/sdk.js. سيجلب هذا النص البرمجي أداة تحميل SDK، والتي ستعمل على تحميل أحدث SDK من accountkit.com أو من ذاكرة التخزين المؤقت للمتصفح.

بالنسبة إلى الحالات التي تريد فيها استضافة مجموعة SDK عبر خادمك الخاص، يمكنك القيام بذلك لفترة سماح مدتها 24 ساعة. بعد انقضاء فترة السماح هذه، ستبدأ مجموعة SDK إصدار التحذيرات والتوقف عن العمل بعد مضي 7 أيام.

قم بتعيين المعلمة enableSendToFacebook (على نظام iOS) أو setFacebookNotificationsEnabled (على نظام Android) إلى القيمة صحيح.

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

ستحتاج إلى إضافة الإذن INTERNET حتى تتمكن من استدعاء طرق API. بالإضافة إلى ذلك، يمكنك اختيار إضافة أذونات إضافية وتقليل الخلافات أثناء عملية تسجيل الدخول:

• بالنسبة إلى الوصول إلى رسائل SMS، قم بإضافة الإذن RECEIVE_SMS والإذن READ_PHONE_STATE.
• بالنسبة إلى ميزات البريد الإلكتروني، قم بإضافة الإذن GET_ACCOUNTS.

يمكنك التعرف على المزيد عن دمج Account Kit في تطبيق Android الخاصة بك هنا.

عندما يقوم المستخدم بفتح مربع الحوار مشاركة للهواتف المحمولة أو مربع حوار الأخبار، لكنه يقوم بإغلاقه عن طريق الإلغاء، سيتم إشعار تطبيقك عن هذا الأمر عبر طريقة الاستدعاء onSuccess(). يمكنك النظر إلى استدعاء onSuccess() كآلية للإشارة إلى أنه تم إغلاق مربع الحوار بنجاح بطريقة ما، لكن لا يمكنك استخدامه في تحديد ما إذا كان تم بالفعل نشر شيء ما أم لا. إذا قام المستخدم بمنح تطبيقك نطاق الإذن "publish_actions" أيضًا، يتم تنفيذ الاستدعاء onCancel() بمجرد الإلغاء.

للاطلاع على التفاصيل الكاملة للفئة FacebookCallback، يرجى الرجوع إلى الوثائق المرجعية.

يعمل الزر "أعجبني" الأصلي (LikeView) على نحو مماثل للزر "أعجبني" الذي يستند إلى الويب. ولا يمكن استخدام معظم عناوين URL التي تستند إلى فيسبوك بسبب الخصوصية. ومع ذلك هناك استثناءات، من بينها صفحات فيسبوك والصفحة الرئيسية لفيسبوك.

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

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

يمكن الاطلاع على أفضل طرق المشاركة على نظام Android في الوثائق هنا.

We’ve moved all Messenger permissions to the Permissions and Features page.

We've consolidated this into one Permissions and Features page for Business apps, where you can see what access levels you have for each permission and feature.

Yes, developers may opt out of the Business app type and return to the previous App Review process for their app by selecting “Change App Type” on the App Dashboard. However, developers may not opt back into the Business app type and will need to create a new app to do so.

Additionally, apps previously in Development Mode that opt out to the legacy experience that have been approved for Advanced Access via App Review in the new model will lose access to data beyond what their business or anyone with a role on their app owns until they turn their app to Live Mode.

No.

We have replaced Development and Live Mode with Standard and Advanced Access. Standard Access is always active and allows you to access data that a developer’s business or anyone with a role on their app owns. You may submit for App Review for permissions and features to access data owned by other businesses or people. Refer to our Access Levels document to learn more.

To access one of these fields, you will need to submit for Advanced Access for the Business Asset User Profile Access feature through App Review.

Business apps designed to help businesses and organizations manage Pages, Groups, Events, Ads, and ad-related assets.

• يتم نقل التطبيق إلى نشاط تجاري مختلف لم يتم التحقق منه. وسيتم حظر كل الأذونات المُعتمدة سابقًا.

  • إذا تم حينها نقل التطبيق مرة أخرى إلى النشاط التجاري الذي تم التحقق منه، فسيتم إلغاء حظر الأذونات.
• يتم تحديد التطبيق على أنه توفير الخدمات إلى الأنشطة التجارية الأخرى، ولكن تم نقله بعد ذلك إلى نشاط تجاري مختلف لم يتم التحقق منه.

Yes, ALL apps that leverage permissions that require review (Pages API, Groups API, Events API, Business Manager API, Instagram Graph API, Messenger Platform, extended Facebook Login permissions, Marketing API and Lead Ads API) must submit for app review in adherence with the communicated deadlines.

Active apps that leverage permissions with an August 1st deadline (Pages API, Groups API, Events API, Business Manager API, Instagram Graph API, Messenger Platform, extended Facebook Login permissions) and have not yet proactively submitted for review will be auto-enrolled in the review process. You can accelerate the App Review process by submitting your app for review prior to auto-enrollment. This will give you more control over when your app is reviewed and what information is used for the review.

لمزيد من التفاصيل، تفضل بزيارة هذه الصفحة. وستمنحك العملية الفرصة لتوفير تفاصيل حول الأذونات التي تحتاج إليها وكيفية استخدامها. وسيراجع Facebook حالة الاستخدام وسيحدد ما إذا كان مسموحًا بها ضمن السياسة أم لا. وبعد مراجعة الإذن واعتمادًا على واجهة API/الإذن، قد تتوفر لدينا متطلبات إضافية مثل التحقق من النشاط التجاري وتوقيع العقد.

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

Yes, if your apps have made calls to the Graph API in the last 28 days as of July 31, 2018 and require access to the reviewable permissions with an August 1st deadline, your app will be auto-enrolled in the app review process. We will notify you when we have a process available to send us the additional information needed to complete the review process.

As we announced earlier this year, all apps accessing the Pages API, Groups API, Events API, Business Manager API, Instagram Graph API, Messenger Platform, and Facebook Login were expected to submit for app review by August 1.

To help protect the integrity of our platform, we have removed API access for apps that require these permissions, have not gone through app review, and have not been active within the last 28 days as of July 31, 2018. If you still need access to our APIs, we encourage you to submit for review through your app's App Dashboard.

All active apps that require these permissions will be auto-enrolled in app review in the coming weeks. Developers will be notified if we require additional information to complete the app review submission. If responses are not received in the allocated timeframe, reviewable API access will be disabled.

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

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

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

ستحتاج إلى طلب الإذنين leads_retrieval وpages_manage_ads.

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

توفر وثيقة تطبيقات خادم إلى خادم أيضًا إرشادات لإكمال عملية مراجعة التطبيق بالنسبة إلى التطبيقات التي لا تحتوي على واجهة مستخدم.

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

إذا كان لديك بالفعل حساب مدير أعمال، فنوصيك بربط التطبيق بمدير الأعمال الحالي.

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

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

يجب إجراء مراجعة التطبيقات لكل تطبيق. ونوصيك بمراجعة لوحة معلومات التطبيق للحصول على قائمة محددة تضم الأذونات التي تتطلب المراجعة.

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

يجب أن يكون التطبيق مرتبطًا بمدير الأعمال للنشاط التجاري الذي يمتلك التطبيق في النهاية ولديه إمكانية الوصول إلى البيانات التي يتم إنشاؤها من التطبيق. ويجب أن يخضع هذا النشاط التجاري لعملية التحقق من النشاط التجاري.

Badging for FMP and IGP will resume by the end of May.

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

You need to initiate app review before August 1, 2018 for these APIs: Pages API, Groups API, Events API, Instagram Platform API, Messenger Platform, Business Manager API, and Facebook Login.

You need to initiate App Review before February 1, 2019 for these APIs and features: the Marketing API and the Lead Ads Retrieval feature.

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

• قد تستغرق مراجعة الإذن عدة أسابيع. ويمكن العثور على آخر تحديث لدينا في اليوميات هنا.
• يجب أن تستغرق عملية التحقق من النشاط التجاري بضعة أيام، ومع ذلك ستعتمد هذه العملية على جودة الوثائق.
• يمكن إكمال التوقيع على العقد بمجرد توقيع المسؤول المكلف على العقد.

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

Same as other permissions, you will lose access.

اعتبارًا من 1 أغسطس 2018، تحتاج فقط إلى التحقق من مدير الأعمال الذي يتصل به التطبيق.

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

نعم، ستكتسب التطبيقات الاختبارية الأذونات القابلة للمراجعة من التطبيقات الأصلية.

يرجى الرجوع إلى هذا المنشور لعرض تخطيط للجدول الزمني.

يجب على كل التطبيقات الحالية التي تقوم باستدعاء الأذونات الموسّعة في تسجيل دخول فيسبوك بالإضافة إلى 6 واجهات API جديدة (الصفحات وMessenger ومدير الأعمال وInstagram والمجموعات والمناسبات) التقديم لدفق مراجعة التطبيق الجديد، والذي يتضمن التحقق من النشاط التجاري وتوقيع العقود. لا يجب بالضرورة إكمال عملية مراجعة التطبيق قبل حلول ذلك التاريخ، وإنما تقديمها فقط. إذا لم يتم التقديم قبل 1 أغسطس 2018، فسيتم حجب الوصول إلى تلك الواجهات في يوم 2 أغسطس 2018.

يجب تقديم كل التطبيقات الحالية التي تقوم باستدعاء واجهة API التسويق وواجهة API استرداد إعلانات تجميع بيانات العملاء المحتملين إلى دفق عملية مراجعة التطبيق الجديد والذي يتضمن التحقق من النشاط التجاري وتوقيع العقود قبل تاريخ 1 فبراير 2019.

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

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

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

لقد أعلنّا في 1 مايو 2018 عن عملية مراجعة تطبيق جديدة يجب الخضوع لها للحصول على تسجيل دخول فيسبوك (الأذونات الموسّعة) بالإضافة إلى 6 واجهات API جديدة (الصفحات وMessenger ومدير الأعمال وInstagram والمجموعات والمناسبات). يجب التقديم إلى عملية مراجعة التطبيق لمراجعة واجهات API هذه / الأذونات قبل تاريخ 1 أغسطس 2018 كشرط لمنحك صلاحية الوصول إلى واجهات API هذه.

في 2 يوليو 2018، أعلنّا عن طرح واجهات API إضافية تتطلب الخضوع لمراجعة التطبيق: واجهة API التسويق واسترداد إعلانات تجميع بيانات العملاء المحتملين. يجب التقديم إلى عملية مراجعة التطبيق لمراجعة واجهات API هذه قبل تاريخ 1 فبراير 2019 كشرط لمنحك صلاحية الوصول. يمكنك قراءة المزيد عن تواريخ الاستحقاق هنا.

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

لتجنب ذلك، يرجى:

• تقديم إصدار صالح لتطبيقك يستخدم الإذن
• التأكد من أن التعليمات الواردة في القسم "إضافة ملاحظات" واضحة
• التأكد من قيام أذونات تسجيل الدخول المطلوبة بإضفاء طابع شخصي على تجربة المستخدم وبتوافقها مع مبادئنا

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

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

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

إذا كان الرفض بسبب "مشكلات عامة"، فيرجى الاطلاع على كل الملاحظات بعناية. وستتلقى كل منصة ملاحظات منفصلة من المفترض أن توضح المشكلات التي ظهرت أثناء المراجعة.

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

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

To be approved for App Center, your App will need to meet our eligibility requirements. Apps eligible for the Facebook App Center must use Facebook Login or have a Facebook Canvas app.

App eligible to be listed in App Center are:

• Apps on Facebook Canvas
• Mobile apps built for iOS or Android using Facebook Login for iOS or Facebook Login for Android
• Web or mobile apps using Facebook Login

Your text assets and promotional images must also meet our guidelines.

إذا كنت تستخدم مربع الحوار مشاركة أو أي مكون إضافي آخر للتواصل الاجتماعي لنشر المحتوى مرة أخرى في Facebook، فلن تحتاج إلى تقديم التطبيق للمراجعة. وإذا كنت لا تزال في حيرة من أمرك، يمكنك الاطلاع على مزيد من المعلومات في وثائق المراجعة العامة.

يتعارض ذلك مع سياسة المنصة 4.5 لتشجيع الأشخاص على استخدام المكونات الإضافية للتواصل الاجتماعي أو تسجيل الإعجاب بالصفحة. ويشتمل ذلك على عرض مكافآت أو إتاحة محتوى التطبيق أو التطبيقات بناءً على ما إذا قام الشخص بتسجيل إعجابه بالصفحة أم لا. ولن يتم اعتماد الإذن User_likes لهذا الغرض.

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

Our review team may need additional login credentials for your app in order to complete your review.

If your app requires a secondary login before or after Facebook Login, please be sure to provide a username and password for this. This may include login credentials for a testing or demo server, secondary login for your app or an e-mail registration flow.

Apps hosted on staging or development servers may require an additional login to access your server. Please provide all necessary login credentials for this also.

If you're still not sure what credentials are missing, you can provide a video with your next submission that shows the Facebook Login option and all relevant Facebook integrations you're submitting for.

لاعتماد عملية تقديم تطبيقك، سيحتاج فريق المراجعة إلى تسجيل الدخول إلى تطبيقك والتحقق من كل أوجه الدمج مع Facebook.

وإذا تعذر على المراجع تحميل تطبيقك أو استخدامه، فيرجى التأكد مما يلي:

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

إذا تعرضت للرفض مرة أخرى للسبب ذاته، فقم بتحديث القسم تعليمات المراجعة أو إضافة ملاحظات لمطالبة المراجع بتقديم بعض التوضيحات والمعلومات الإضافية.

يُعد تسجيل الشاشة طريقة رائعة لإرشادنا عبر تطبيقك ويوضح لنا كيفية استخدامك للأذونات المطلوبة. فيما يلي بعض أفضل الممارسات والموارد الخارجية من أجل إنشاء تسجيل للشاشة.

وينبغي أن يوضح الفيديو كيفية استخدام تطبيقك لكل الأذونات التي يطلبها. إذا كنت تطلب الإذن publish_actions، ينبغي أن يوضح مقطع الفيديو أيضًا كيفية إنشاء المحتوى من تطبيقك ومشاركته على فيسبوك.

لا يمكن استخدام معرف تطبيق Facebook الذي تم إنشاؤه للعبتك الفورية على أية منصة أخرى. يمكنك العثور على المزيد من المعلومات في الوثائق التي نوفرها.

سيستخدم فريق المراجعة الإرشادات التي تقدمها لاختبار عمليات دمج تطبيقك مع فيسبوك.

إذا كنت تعتقد أن المراجع قد رفض تطبيقك عن طريق الخطأ، فيجب معاودة تقديم تطبيقك للمراجعة مع تحديث إرشادات المراجعة بحيث تقدم مزيدًا من المعلومات للمراجع.

وتُعد عملية المراجعة أفضل طريقة للتواصل مع المراجع عن طريق تحديث ملاحظاتك للرد على الملاحظات التي تلقيتها.

يستخدم فريق المراجعة عدة حسابات اختبارية عند مراجعة عمليات تقديم التطبيقات، ولا نستخدم دائمًا الحساب الاختباري الذي تقدمه. وإذا كانت عملية تقديم التطبيق تحتاج إلى المراجعة باستخدام حساب اختباري محدد، فيرجى إخبارنا بذلك في تعليمات المراجعة.

إذا قدمت حسابًا اختباريًا، فتأكد من إنشاء الحساب الاختباري بشكل صحيح وتضمين المستخدم في عملية تقديم التطبيق.

لا، إذ يمكنك بمجرد اعتماد الإذن استخدامه عبر كل إصدارات تطبيقك على أية منصة.

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

إذا كان تطبيقك عبارة عن لعبة وموجود على Facebook Canvas

يمكنك إرسال دعوة إلى لاعبين جدد للانضمام إلى لعبتك باستخدام أي مما يلي:

• مربع حوار الطلبات. عند استخدام مربع الحوار الطلبات، يمكنك تعيين 'filters=app_non_users' لفلترة مربع الحوار بحيث لا يعرض سوى الأشخاص الذين لا يستخدمون تطبيقك فقط. وإذا كان تطبيقك موجودًا على اللوحة، فقد تستخدم أيضًا مربع الحوار الطلبات على نظامي iOS وAndroid.
• واجهة API الأصدقاء الذين يمكن دعوتهم. وإذا كان تطبيقك عبارة عن لعبة وكنت تريد إنشاء أداة تحديد أصدقاء متعددين، يمكنك استخدام واجهة API الأصدقاء الذين يمكن دعوتهم والتي تقوم بإرجاع قائمة تصنيفية تضم أصدقاء الشخص الذين لا يستخدمون التطبيق. وبمجرد أن الشخص حدد عددًا من الأصدقاء لدعوتهم، يمكنك إرسال الرموز التي تم إرجاعها من خلال واجهة API الأصدقاء الذين يمكن دعوتهم إلى حقل مربع الحوار الطلبات مما سيتيح للشخص عندئذ إرسال دعوة إلى هؤلاء الأصدقاء.

إذا لم يكن تطبيقك موجودًا على Facebook Canvas

يمكنك استخدام مربع الحوار رسالة في نظامي iOS وAndroid، أو مربع الحوار إرسال في الويب. وتتيح هذه المنتجات للأشخاص إمكانية إرسال رسالة مباشرة إلى أصدقائهم تحتوي على رابط لتطبيقك.

يمثل هذا النوع من الرسائل قناة رائعة للتواصل مع عدد أقل من الأشخاص بطريقة مباشرة. ويحتوي "مربع الحوار رسالة" و"مربع الحوار إرسال" على قائمة تتيح للشخص بسهولة تحديد مجموعة من الأصدقاء الذين سيتلقون الدعوة.

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

لمزيد من المعلومات، يرجى الاطلاع على مبادئنا وعلى إرشادات أداة المساعدة.

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

عند تقديم طلب لاعتماد الإذن user_likes، يجب أن تكتب تعليمات تفصيلية تتضمن ما يلي:

• شرح واضح لسبب طلب الإذن user_likes وكيفية مساهمته في تحسين تجربة المستخدمين داخل تطبيقك.
• قائمة تضم عينات من الصفحات التي سيسجل المراجع إعجابه بها للتحقق من استخدامك للإذن user_likes. لذا يرجى تقديم رابط مباشر للصفحات التي يجب على المراجع تسجيل إعجابه بها قبل بدء اختبار تطبيقك.

إذا كنت تستخدم الإذن user_likes كجزء من خوارزمية، فمن المهم أن يتمكّن المراجع من الاطلاع على نتيجة هذه الخوارزمية وكيفية تأثيرها في المحتوى الذي يظهر للأشخاص.

In certain cases, you may need the reviewer to reproduce a certain behavior or experience available only to a specific test user. If this is the case, you can add this user to your submission on the App Review page. In the Items in Review section, you'll see a Test User (optional) section that allows you to type the name of the user you wish to be used in your review.

The only test users available here are those listed as Test Users in the Roles section of your app. Please do not share Facebook login credentials for users in your review instructions.

Learn moreتعرف على المزيد حول كيفية إنشاء حساب اختباري.

لا، لن تحتاج إلى تقديم تطبيقك للمراجعة لتشغيل إعلانات تثبيت تطبيقات الهواتف المحمولة. وستحتاج فقط إلى تطبيق متوفر في وضع البث المباشر على متجر iTunes App Store أو متجر Google Play. ويمكنك اتباع دليلنا لإنشاء إعلانات عمليات تثبيت تطبيقات الهواتف المحمولة.

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

بالنسبة لكل إذن تطلبه، اذكر تعليمات إعادة إنشائه في خطوات تفصيلية. ويجب أن تتوفر كل التعليمات باللغة الإنجليزية.

لا يجب أن تتضمن التعليمات ما يلي:

• الإشارة إلى تعليمات مُقدمة من عمليات تقديم تطبيقات أو وثائق أخرى
• تلخيص الإجراءات التي ينفذها تطبيقك بدلاً من تقديم التعليمات
• تقديم تفاصيل تقنية بشأن طريقة عمل واجهات API

فيما يلي مثال جيد على التعليمات التفصيلية:

1. اضغط على الزر "الإعدادات" من القائمة اليمنى.
2. حدد تسجيل الدخول باستخدام حساب Facebook
3. أكمل الخطوة الثالثة
4. أكمل الخطوة الرابعة

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

نظرًا للتغييرات التي طرأت على عملية المراجعة وزيادة معدل عمليات تقديم التطبيقات المتوقعة، قد يستغرق إكمال عملية مراجعة التطبيقات المُقدمة عدة أسابيع.

لذا يرجى تقديم أكبر قدر ممكن من المعلومات لمساعدة المراجع ويتضمن ذلك توفير لقطات شاشة واضحة وتعليمات تفصيلية وتسجيل شاشة لتطبيقك ودمجه مع Facebook.

لا يتعين على Facebook مراجعة التطبيقات التي تستخدم منتجات المشاركة الوسيطة مثل المكونات الإضافية للتواصل الاجتماعي ومربع الحوار مشاركة وجداول المشاركة أو مجموعة فرعية من تسجيل دخول فيسبوك. ولمعرفة المزيد حول الأمور التي تتطلب المراجعة، يرجى الرجوع إلى وثائق مراجعة التطبيقات.

نراجع تطبيقك للتأكد من توفير تجربة عالية الجودة على Facebook عبر كل التطبيقات. بوجه عام، يجب أن يكون الأشخاص على دراية بأنهم يسجلون الدخول إلى فيسبوك ويقومون بالنشر عليه. يجب أن يتمكّن الأشخاص من التحكم في المعلومات التي يشاركونها مع تطبيقك أو على Facebook.

ملاحظة: سيتمكّن الأشخاص المُدرجون في علامة التبويب "الأدوار" في تطبيقك من الوصول إلى الأذونات الموسّعة دون الخضوع للمراجعة (فعلى سبيل المثال، الإذن user_posts). ومع ذلك، عندما تتم إتاحة التطبيق للاستخدام العام، يجب أن يخضع إلى عملية مراجعة التطبيقات للوصول إلى المعلومات حتى بالنسبة للأشخاص الذين يتمتعون بأدوار في التطبيق.

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

وإذا كان يتم طلب قائمة صفحات لنشاط تجاري عبر /BUSINESS_ID/pages، فلا يمكن طلب كل حقول الصفحة، وقد تستجيب واجهة API لكن مع حدوث خطأ: (#100) Unknown fields: <FIELD_NAME>.

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

ويمكن استخدام نقطة النهاية <BUSINESS_ID>/owned_pages أو <BUSINESS_ID>/client_pages، والتي من المفترض أن تعرض كل منهما كائنات الصفحة وتدعم توسيع الحقول.

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

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

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

يجب عليك الإقرار نيابة عن كل تطبيق يديره نشاطك التجاري على نحو منفصل.

يجب عليك إكمال عملية الفحص لكل واحد من التطبيقات التي تديرها (قد يكون لكل تطبيق عدة أذونات). يمكنك الإقرار بشأن التطبيقات كل على حدة ووضع أولويات كما يتراءى لك، طالما أكملت العملية قبل الموعد النهائي المحدد لكل تطبيق.

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

يمكنك عرض كل التطبيقات التي تتطلب إجراء فحص استخدام البيانات من خلال الانتقال إلى صفحة "تطبيقاتي" في لوحة معلومات التطبيق. وهناك يمكنك عرض كل التطبيقات التي تديرها والفلترة للوصول إلى التطبيقات التي تتطلب إجراء فحص استخدام البيانات.

يجب على مسؤول التطبيق إكمال العملية. للاطلاع على من يمتلكون صلاحية المسؤول بتطبيقك، يرجى تسجيل الدخول إلى لوحة معلومات التطبيق والنقر على "الأدوار" في الجانب الأيمن من الصفحة. يجب أن يُمنح مسؤولو التطبيق صلاحية التصرف نيابة عن مؤسستك.

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

سيتوفر لك 60 يومًا من وقت بدء العملية (بمجرد تلقي أو تنبيه للمطوّر) حتى بلوغ الموعد النهائي.

بعد حلول الموعد النهائي، سنبدأ في إلغاء صلاحية الوصول إلى المنصة من خلال تقييد استدعاءات واجهة API خلال فترة الشهر الذي يلي تاريخ الموعد النهائي. خلال هذه الفترة، ستتمكن من الانتقال إلى لوحة معلومات التطبيق لديك وإكمال فحص استخدام البيانات لاستعادة تطبيقك لحالة التوافق واستعادة الوصول الكامل إلى المنصة. وعلى الرغم من ذلك، بعد مرور شهر كامل من تاريخ الموعد النهائي، سنقوم بإلغاء صلاحية الوصول إلى المنصة تمامًا.

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

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

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

يجب عليك أولاً إزالة الإذن باستخدام لوحة معلومات التطبيق (انقر على "أذوناتي وميزاتي") من القائمة المنسدلة بالجانب الأيمن أسفل "مراجعة التطبيقات"). يمكنك بعد ذلك الإقرار بالأذونات والميزات المتبقية التي لا تزال تستخدمها.

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

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

يجب عليك إكمال فحص استخدام البيانات لكل الأذونات التي يملك تطبيقك صلاحية الوصول إليها.

In order to comply with certain legal obligations, Meta’s developer services may not be available in all locations, including countries and regions currently subject to U.S. sanctions prohibitions.

Meta’s services are not available in all regions.

Registration reviews may take longer and you may be unable to access our service during that time. Please try again in a few days. For more information, please refer to Meta’s Terms of Service.

We are currently reviewing your registration details. This takes 24 to 48 hours. Once completed and approved, you may be able to login and complete your registration.

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

تحقق مما إذا كان يمكنك رؤية رسالة الخطأ دون تقديم طلب للحصول على صور المستخدم والتحقق من أن رسالة الخطأ كانت ظاهرة في البداية. قم بعد ذلك بتقديم طلب API التالي me/photos ثم قم بالرجوع للتحقق مما إذا كانت رسالة الخطأ لا تزال ظاهرة أم لم تعد ظاهرة. تأكد عند إجراء استدعاء me/photos الاختباري من استخدام التطبيق المقصود والحصول على رمز الوصول الصحيح الذي يتطلب الحصول على إذن user_photos وأن تكون جاهزًا!

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

يؤدي استخدام الترحيل 'أمان النشر بتدفق لعنوان URL' إلى إيقاف نشر تطبيقك على فيسبوك لأية عناوين URL لا تقود إلى النطاق الخاص بالتطبيق. يرجى عدم استخدام هذا الخيار إذا كان تطبيقك يقوم بنشر روابط إلى مواقع أخرى.

تمت إزالة لوحة المعلومات هذه. سيلزمك استخدام نقطة النهاية '/{app-id}/accounts/test-users/' لربط الحساب الاختباري بالتطبيق. يمكنك الاطلاع على المزيد عن هذا الأمر هنا.

هذا سلوك مقصود ومُشار إليه في الوثائق هنا - https://developers.facebook.com/docs/apps/test-users#rules - لا يمكن للحسابات الاختبارية أن تصبح من معجبي صفحة عامة على فيسبوك أو إنشاء محتوى علي هذه الصفحة، مثل الكتابة على حائط الصفحة. ورغم ذلك يمكن للحساب الاختباري رؤية أي علامة تبويب تطبيق والتفاعل معها بالصفحة المرتبطة بالتطبيق الذي أنشأ الحساب الاختباري.

هذا أمر مقصود. لا نسمح بإدخال العديد من النطاقات بشكل عشوائي لأغراض الأمان.

هذا هو السلوك المقصود. يستخدم مربع الحوار "تسجيل الدخول" عرض ثابت ولا يتم توسيعه ليناسب الشاشات الأكبر.

وهذا سلوك مقصود. تقع على عاتق المطور مسؤولية تعين 'redirect_uri' المناسب استنادًا إلى نوع جهاز المستخدم، وبالتالي إذا كان المستخدم يستخدم جهازًا محمولاً، يجب تعيين 'redirect_uri' إلى عنوان URL لموقع الهواتف المحمولة.

هذا سلوك مقصود، لأن ذلك يمنع أية ثغرات أمنية محتملة. تقوم بعض المتصفحات بإلحاق جزء التجزئة من عنوان URL إلى نهاية عنوان URL الجديد الذي تمت إعادة توجيهها إليه (في حالة عدم وجود جزء تجزئة لعنوان URL الجديد).

على سبيل المثال إذا هناك موقع ما example1.com يعرض رابط لإعادة التوجيه إلى موقع آخر example2.com، فإن المتصفح الذي ينتقل إلى الموقع example1.com#abc سينتقل إلى الموقع example2.com#abc، ويمكن الوصول إلى محتوى جزء التجزئة من example1.com لإضافة سكريبت على example2.com.

ونظرًا لأنه من الممكن وجود دفق مصادقة يقوم بإعادة التوجيه إلى دفق مصادقة آخر، يمكن الوصول إلى بيانات مصادقة حساسة من تطبيق إلى الآخر. يتم تخفيف ذلك عن طريق إلحاق جزء تجزئة جديد بعنوان URL لإعادة التوجيه لمنع سلوك المتصفح هذا. إذا كانت الناحية الجمالية أو سلوك العميل لعنوان URL الناتج من الأمور المهمة، يمكن استخدام window.location.hash (أو إعادة توجيه من الخادم) لإزالة الأحرف المخالفة.

Test apps created from Business apps will have Standard Access for all permissions and features.

No. The access level model only applies to permissions and features.

No. For a given permission, Business apps have either None, Standard, or Advanced Access.

Yes. A Business app will be auto-granted Standard Access and may request Advanced Access for a given permission.

Yes. For Business apps, the Advanced Access level includes access to all data within the Standard Access level.

لمشاركة عنوان URL، يجب أن تكون الصورة المرتبطة به بنسبة عرض إلى ارتفاع 200x200 بيكسل على الأقل. إذا لم يكن الأمر كذلك، فسيظهر لك خطأ مشابه لهذا الخطأ "og:image المقدمة غير كبيرة بالدرجة الكافية. يرجى استخدام صورة 200x200 بيكسل على الأقل".

لاختيار صورة لعنوان URL، ننظر أولاً إلى علامة 'og:image' لنتأكد من أنها موجودة ومن أن نسبة عرضها إلى ارتفاعها تتجاوز الحد المطلوب وهو 200x200 بيكسل. وفي حالة عدم وجود علامة 'og:image'، نختار أول صورة تظهر لنا على صفحة الويب.

وإذا ظهر لك خطأ لكنك تعتقد أن صورة الموقع أكبر من 200x200 بيكسل، يجب التحقق من تعيين علامة 'og:image' بشكل صحيح، لأن السبب الأكثر احتمالاً هو أننا نقوم باسترجاع صورة غير صحيحة من موقعك.

لقد قمنا بتغيير سلوك المكون الإضافي للمشاركة حتى يتناسق مع المكونات الإضافية والميزات الأخرى المتاحة على المنصة.

لن يعد بإمكان المكون الإضافة للمشاركة قبول المعلمات المخصصة، وسيقوم فيسبوك بسحب المعلومات التي يتم عرضها في المعاينة بنفس الطريقة التي تظهر بها على فيسبوك كمنشور، عبر علامات Open Graph الوصفية لعنوان URL.

لا، من غير الممكن تجاوز 'caption'، لكن يمكن فقط تجاوز 'title' و'description'.

لا يمكن للتطبيق التحميل إلى الألبومات التي تم إنشاؤها بواسطة تطبيقات أخرى.

في بعض الحالات، توجد ألبومات غير مرتبطة بأية تطبيقات (ألبوم صور الحائط). ونقترح عليك مراجعة الحقل can_upload. إذا كان الحقل can_upload يعرض قيمة خطأ، فإنك ذلك يعني أنه لا يمكن للمستخدمين وضع الصور مباشرة في هذا الألبوم عبر طريقة عرض الألبومات في الصفحة الشخصية.

يظهر زر الدعوة لاتخاذ إجراء أسفل الأيقونة 'replay' بمجرد انتهاء الفيديو.

يجب أن يقل حجم صورة GIF عن 8 ميجابايت حتى يمكن تشغيلها على فيسبوك

لا يتم دعم إنشاء تعليقات لمنشورات لم يتم نشرها عبر واجهة API في الوقت الحالي.

لا يتم عرض منشور الفيديو الذي تم إنشاؤه بشكل مضمن في نقطة النهاية promotable_posts نظرًا لأنه يتم بالفعل ترويجه. منشور الفيديو الذي تم إنشاؤه بشكل مضمن هو المنشور الذي تم إنشاؤه كجزء من عملية إنشاء الإعلان، وبالتالي لا يمكن ترويجه بشكل مستقل.

ولذلك من المتوقع عدم عرض هذا المنشور الذي تم إنشاؤه بشكل مضمن في نقطة النهاية /promotable_posts.

يمكن أن يحدث ذلك إذا كنت تستخدم رمز وصول صفحة يظهر المستخدم المرتبط به بدور محلل في قسم "الأدوار بالصفحة" في "الإعدادات" بصفحتك.

وعند تقديم طلب للحصول على البيانات باستخدام واجهة Graph API، يتم تطبيق العديد من قواعد الخصوصية التي قد تتسبب في عدم عرض البيانات حتى إذا كان يمكنك الاطلاع عليها على موقع الويب. ويعتمد ذلك على عدة عوامل مثل سياسية الخصوصية للمستخدم والأذونات المسموح بها على مستوى التطبيق وما إلى ذلك. وهذا يعني أن البيانات التي يتم عرضها بواسطة واجهة API لا تتضمن بالضرورة البيانات التي تظهر بموقع الويب.

وإذا تم إنشاء المنشور باستخدام 'object_story_spec' لواجهة API الإعلانات، يتم تصنيف هذه المنشورات على أنها منشورات مضمنة. للاطلاع على هذه المنشورات، سيلزمك استخدام عنصر الربط /{page-id}/promotable_posts واستخدام مُعامل 'is_inline' في الإصدار 2.3 والإصدارات الأقل و'include_inline' في الإصدار 2.4 والإصدارات الأعلى. يمكنك الاطلاع على المزيد هنا.

سيتم عرض الحقل "المشاركات" عند مشاركة المنشور أكثر من 10 مرات. وإذا تمت مشاركة المنشور أقل من 10 مرات، قد نقوم بحذف هذا الحقل أو محاولة عرض رقم.

يمكنك البحث عن المزيد عن نقطة النهاية هذه هنا: https://developers.facebook.com/docs/graph-api/reference/v2.4/post.

هذه قيمة قديمة مستخدمة في البنية التحتية القديمة واحتفظنا بها لأغراض التوافق مع الإصدارات السابقة عند الانتقال إلى إصدار أحدث.

وسيحدث ذلك مع المنشورات القديمة وليس مع المنشورات الحديثة.

يعمل ذلك على النحو المقصود. لا توجد صلة بين المنشور والصور المضمنة في المنشور. ونحن نعرض فقط أول صورة تم تحميلها إلى المنشور.

لن يتم عرض الحقل 'application' إذا تم إسناد المنشور إلى موقع فيسبوك على الويب أو تطبيق هواتف محمولة. وهذا متوافق مع الموقع، الذي لا يعرض إسناد هذين النوعين من المنشورات.

سيتضمن الحقل "الخصوصية" للمنشور معلومات عن إمكانية عرض هذا المنشور على فيسبوك، لكن عند استهداف أو تقييد عرض منشور الصفحة على جمهور محدد، لا تعرض المعلومات المذكورة في حقل "الخصوصية" جميع خيارات الاستهداف المحددة.

للاطلاع على التفاصيل الكاملة لكيفية استهداف المنشور أو تقييده، راجع الحقل 'targeting' (بالنسبة إلى التقييد)، والحقل 'feed_targeting' (بالنسبة إلى الاستهداف بآخر الأخبار). يرجى مراجعة وثائق المنشور لمزيد من المعلومات عن الحقول المتاحة.

يمكن أن تتضمن قيمة comment_count التي يتم عرضها لمنشور التعليقات المخفية أو المحذوفة. ولن يزيد عدد التعليقات التي تظهر في المنشور بأي حال من الأحوال عن comment_count.

لا يمكن تجاوز 'caption' لعنوان URL تمت مشاركته. يمكنك فقط تجاوز 'title' و'description' لعنوان URL هذا.

لمزيد من المعلومات والتعرف على الحقول التي يمكن نشرها عبر واجهة Graph API، يرجى الاطلاع على وثائق /feed هنا: https://developers.facebook.com/docs/graph-api/reference/v2.3/page/feed#publish

وهذا سلوك مقصود في التصميم. وهذا الأمر متوافق مع كيفية عرض المحتوى (دون إسناده إلى فيسبوك نفسه) الذي تم إنشاؤه بواسطة تطبيق فيسبوك (سواءً للهواتف المحمولة أو الويب).

أجرينا بعد التحديثات من جانبنا على كيفية استرجاع وعرض بيانات البث والمنشورات عبر واجهة API.

إذا كنت تواجه مشكلات عند إحضار المنشورات عبر واجهة API وتعتقد أنها لا تعمل على النحو الموضح في الوثائق، يرجى التحقق من الآتي -

• حصول رمز الوصول الذي تستخدمه على الأذونات المناسبة للوصول إلى المنشورات التي تهتم بها.
• يرجى التأكد من أن أية استدعاءات API تقوم بها لاسترجاع المنشورات تستخدم 'id' الذي تم عرضه في استدعاء سابق ومن أنك لم تقم بإنشاء المعرفات يدويًا استنادًا إلى الصفحة أو المستخدم أو معرفات أخرى.

يتم نشر الصور التي تم تحميلها عبر Instragram كإجراءات Open Graph، وتتطلب الحصول على أذونات Open Graph حتى يمكن قراءتها من واجهة Graph API.

في حالة صور Instagram، الإذن المطلوب هو "user_actions:instapp" حيث يمثل "instapp" مساحة اسم تطبيق Instagram.

لا تظهر إجراءات Open Graph في اتصال /feed لكن عند تحميل الصورة كإجراء Open Graph يمكن الوصول إليها باستخدام الأذونات المناسبة عبر اتصال ألبومات المستخدم أو اتصال /photos إذا كان ذلك ممكنًا.

تتوفر المزيد من المعلومات عن أذونات Open Graph هنا.

هذا سلوك مقصود. يعرض النظام لدينا رسالة الخطأ المُشار إليها أعلاه في حالة حذف الكائنات أو عدم ظهورها في عمليات التحقق من الخصوصية/الأذونات.

هذا السلوك متوقع وهذا الشكل من تقسيم الصفحات غير مدعوم للتعليقات.

قد يعرض الحقل total_count لمعلمة الملخص لنقطة النهاية /{user-id}/accounts عددًا أكبر من المتوقع. ويرجع ذلك إلى أن total_count يتضمن أيضًا أية صفحات محذوفة كان المستخدم مسؤولاً فيها.

ومع ذلك، ستتضمن البيانات التي تعرضها نقطة النهاية نفسها فقط الصفحات التي لم يتم حذفها.

تم تغيير نقطة النهاية /user/likes من تقسيم الصفحات استنادًا إلى الوقت (الذي يستخدم 'since' و'until' كمعلمات) إلى تقسيم الصفحات استنادًا إلى المؤشر (الذي يستخدم المعلمتين 'before' و'after').

يمكنك الاطلاع على المزيد عن هذه الفروق هنا: https://developers.facebook.com/docs/graph-api/using-graph-api/v2.3#paging

مع طرح معرفات المستخدمين على مستوى التطبيق، أجرينا تغييرات على كيفية عرض نقطة النهاية للبيانات.

ومع إيقاف العمل بالإصدار 1.0، سنركز على الإصدار 2.x هنا. ويمكن أن يعرض /v2.0/{id} https://www.facebook.com/{id}، أو يمكن أن يعرض https://www.facebook.com/app_scoped_user_id/{id}.

هذا أمر مقصود. يعني هذا الخطأ أن رمز الوصول الذي تحاول توسيع نطاقه لا يمكنه الوصول إلى معرف التطبيق الذي تحاول توسيع نطاق هذا الرمز له.

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

السبب التالي الأكثر احتمالاً هو أننا لا يمكننا التأكد من المستخدم يفي بالمتطلبات (أي لا نعرف موقعه)، ولا تتيح قيود تطبيقك لهذا المستخدم الوصول إلى التطبيق.

اعتبارًا من شهر يوليو 2013، لم يعد من الممكن استخدام نقطة نهاية البحث التي تستخدم بريد إلكتروني في نوع بحث المستخدم.

تم أيضًا إجراء العديد من التغييرات على واجهة Graph API مع طرح الإصدار 2.0. ولم تعد إمكانية البحث في المنشورات العامة وعمليات البحث باستخدام الكلمات الأساسية متاحة في الإصدار 2.0.

يرجى الرجوع إلى سجل التغييرات لمزيد من التفاصيل.

يستخدم أي تطبيق تم إنشاؤه بعد 30 أبريل 2014 الإصدار 2 والإصدارات الأحدث من واجهة API، والتي تعرض فقط أصدقاء تطبيقك باستخدام نقطة النهاية /me/friends، كما ذكرت. علاوة على ذلك، جميع معرفات المستخدمين في الوقت الحالي عبارة عن معرفات على مستوى التطبيق، وهي فريدة ودائمة بالنسبة إلى تطبيقك المحدد.

يمكنك التعرف على المزيد عن جميع الميزات الجديدة والتغييرات التي تم طرحها كجزء من الإصدار 2.0.

توضح وثائق الحقل email للكائن User السلوك التالي المتوقع هنا: "لن يتم عرض هذا الحقل في حالة عدم توفر عنوان بريد إلكتروني صالح".

هناك عدة ظروف قد تجعلك تعتقد أنه يجب أن يظهر للمستخدم عنوان بريد إلكتروني لكن لن يحدث ذلك. لأسباب تتعلق بالخصوصية والأمان، لا يمكن توضيح السبب الدقيق لعدم عرض أي عنوان بريد إلكتروني لمستخدم معين.

من بين الأسباب المحتملة:

• عدم وجود عنوان بريد إلكتروني في الحساب
• عدم وجود بريد إلكتروني تم تأكيده في الحساب
• عدم وجود بريد إلكتروني تم التحقق منه في الحساب
• قام المستخدم بالدخول إلى نقطة تحقق من الأمان تطلب منه إعادة تأكيد عنوان بريده الإلكتروني لكنه لم يفعل ذلك إلى الآن
• لا يمكن الوصول إلى عنوان البريد الإلكتروني للمستخدم

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

لن تتوفر منشورات المستخدم التي تمت مشاركتها على يوميات الصفحة عبر واجهة Graph API في حالة إيقاف تشغيل الإذن الأساسي للمستخدم المتعلق بنوع محتوى المنشور.

كحل بديل للتعرف على منشورات الصور المفقودة من المعجبين، قد تتمكن من إحضار ألبومات الصفحة باستخدام رمز وصول الصفحة، لكن يجب أن تكون الصور موجودة في ألبوم صور اليوميات

على الرغم من أن المنشور عام ويذكر الصفحة التي يتم طلبها، لا يمكن لتطبيقك الاطلاع على مثل هذا المنشور دون الحصول على إذن read_stream من مالك هذه المنشورات. وهذا يعني أن نقطة النهاية {page_id}/tagged لا تعرض جميع المنشورات.

يمكنك الاطلاع على المزيد عن هذا الأمر في موجز الصفحة.

هناك حالات لن يتمكن فيها تطبيق معين (أو أي تطبيق) من الحصول على أية معلومات حول مستخدم فيسبوك بسبب إعدادات الخصوصية لهذا المستخدم - وهذا يشمل الحالة التي يتم فيها الوصول إلى المنشورات بواسطة هذا المستخدم في سياق يتوقع فيه تطبيقك التمكن من الاطلاع على المنشور (أي التفاعل مع الصفحة)

على سبيل المثال، عند حظر مستخدم للتطبيق، أو تعطيل وصول جميع تطبيقات المنصة من الوصول إلى معلوماته عبر واجهة API.

مع بداية طرح الإصدار 2.1 لواجهة Graph API، تمت إزالة هذه الوظيفة. وبالنسبة إلى التطبيقات التي تم إنشاؤها قبل 7 أغسطس 2014، لم يعد هذا الحقل موجودًا في signed_request.

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

يرجى استخدام رابطي paging.next وpaging.previous الذين يتم عرضهما كاستجابة مباشرة للحصول على صفحات النتائج الأخرى. يضمن استخدام الروابط التي تم توفيرها عدم حدوث عطل في التطبيق عند تغيير تنسيق روابط تقسيم الصفحات في المستقبل.

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

على سبيل المثال، تطابق القيمة 'organic' في واجهة مستخدم رؤى الصفحة القيمة 'unpaid' في أداة القياس page_impressions_by_paid_non_paid_unique المتاحة عبر واجهة Graph API.

ونحن نسعى إلى التوفيق بينهما لكن قد يستغرق الأمر بعض الوقت.

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

يحدث هذا الخطأ عادةً عند محاولة إحضار رؤى لصفحة نشطة جدًا. قد يكون هناك تفسير لذلك إذا كنت تقوم بتقليل الفترة الزمنية التي تطلب الرؤى الخاصة بها باستخدام حقلي 'since' و'until'.

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

ويمكن الاطلاع على الخطأ المتعلق بقيد التصميم هذا هنا.

يمكن للمسؤول أو المحرر أو المشرف فقط قراءة رسائل الصفحة وإرسالها. ولا يمكن للأشخاص الذين لهم أدوار أخرى، مثل المعلن والمحلل، قراءة محادثات الصفحة.

يرجى زيارة صفحة المساعدة للتعرف على المزيد عن أدوار الصفحة المختلفة: https://www.facebook.com/help/289207354498410.

لا يساوي إجمالي أعداد 'page_fans' إجمالي أعداد 'page_fans_country' دائمًا. هناك العديد من العوامل التي يمكن أن تؤثر في قيمة 'page_fans_country'. على سبيل المثال، لا يقوم بعض معجبي الصفحة بتعيين البلد في حساباتهم، أو لدى بعض معجبي الصفحة إعداد خصوصية يحول دون ظهور البلد.

للتعرف على المزيد عن إعدادات خصوصية فيسبوك، يرجى زيارة هذه الصفحة في مركز المساعدة: https://www.facebook.com/help/445588775451827.

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

لا يمكن ترويج المنشورات التي يتم إنشاؤها بشكل مضمن كجزء من عملية إنشاء تصميم الإعلان بشكل منفصل. وبالتالي، لن تظهر هذه المنشورات في استدعاء نقطة النهاية /promotable_posts endpoint للصفحة.

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

نعتذر عن عدم دعم إنشاء صور الغلاف أو تحديثها أو حذفها عبر واجهة API في الوقت الحالي.

للتعرف على المزيد عن واجهة API لصورة الغلاف، يرجى زيارة https://developers.facebook.com/docs/graph-api/reference/cover-photo/#Creating

لا، لا يمكن تعديل العرض عبر واجهة API.

هذا هو السلوك المتبع حاليًا. لا يمكن لمسؤولي الصفحة النشر إلى الصفحات بأنفسهم عبر واجهة Graph API، حيث تتوفر هذه الوظيفة على http://www.facebook.com/ وتطبيقات الهواتف المحمولة الخاصة بنا فقط.

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

يرجى التأكد من استخدام رمز وصول صفحة عند اتخاذ إجراءات نيابة عن صفحة. تشير رسالة الخطأ إلى أنك تستخدم رمز وصول مستخدم بدلاً من رمز وصول صفحة.

يمكنك التعرف على الأنواع المختلفة لرموز الوصول هنا: https://developers.facebook.com/docs/facebook-login/access-tokens

هذا أمر غير ممكن، حيث لا تتوفر المنشورات المثبتة ولا إمكانية الاطلاع عليها إلا عبر منتجات فيسبوك الأصلية.

في حالة تشغيل ميزة انعكاس التعليقات لعنوان URL الخارجي في مرحلة ما، يتم تسجيل التفاعلات مع المنشورات التي تم عكس التعليقات فيها مقابل عنوان URL نفسه، ويتم عرضها عند استدعاء {URL-id}/reactions>

لا يتم في الوقت الحالي دعم سحب بيانات أكثر من 1000 قيمة تقسيم لنقطة النهاية /app_insights/app_event. نقترح عليك استخدام واجهة مستخدم Facebook Analytics للتمرير لأسفل إلى نقاط بيانات محددة، مثل بلدان محددة، في حالة الرغبة في تقسيم البيانات إلى فئات محددة.

ربما تقوم باستدعاء نقطة النهاية بشكل سريع جدًا حتى قبل أن يتم نشر البيانات إلى خوادمنا.

يجب الانتظار من ثانية إلى ثانيتين قبل إجراء عمليات استدعاء واجهة API للسماح بنشر المعلومات إلى خوادمنا.

عادةً ما تكون أداة القياس 'page_fans_country' عبارة عن مجموعة فرعية لعدد page_fans. توفر أداة القياس هذه تقسيمًا حسب البلد لمعجبي الصفحة، شريطة أن نتمكن من تحديد بلد المستخدم بدقة.

تتضمن أداة القياس أيضًا أهم البلدان فقط (حسب عدد المعجبين) لمعجبي الصفحة، وليس كل البلدان التي يقيم فيها المعجبون؛ وبالنسبة للصفحات التي يكون معجبوها من عدة بلدان، لن يتم تضمين البلدان التي تقل فيها الكثافة السكانية في أداة القياس هذه.

لا تدعم واجهة API استخدام تقسيم الصفحات الذي يستند إلى الإزاحة.

بدلاً من ذلك، يجب استخدام روابط "تقسيم الصفحات" التي يتم عرضها في نهاية كل استجابة من واجهة Graph API، أو استخدام تقسيم الصفحات استنادًا إلى "المؤشر"، الذي يعد الخيار المفضل.

تتوفر المزيد من المعلومات عن كيفية تقسيم الصفحات بشكل صحيح عبر واجهة Graph API هنا: https://developers.facebook.com/docs/graph-api/using-graph-api/v2.3#paging

هناك رموز وصول قصيرة الأجل وأخرى طويلة الأجل. الرموز قصيرة الأجل مخصصة للجلسات القصيرة وتنتهي صلاحيتها عادةً بعد بضعة ساعات.

ويمكنك التبديل بين رمز قصير الأجل ورمز طويل الأجل، الذي تنتهي صلاحيته بعد حوالي 60 يومًا.

يمكنك الاطلاع على هذا الأمر في وثائق رموز الوصول.

هذا سلوك مقصود، حيث تحترم واجهة API البحث الخصوصية على فيسبوك، وهي مخصصة للمستخدم الذي تستخدم رمز الوصول الخاص به، ولا تدعم البحث بالهاشتاج، وغير مصممة لتكون مكافئة لنفس البحث الذي يتم تشغيله في قائمة الكتابة المسبقة للبحث على موقع Facebook.com.

نحن لا ندعم بشكل صريح أو نهدف إلى عرض واجهة API البحث لنفس العدد من النتائج أو لنتائج محددة مثل عمليات البحث على موقع Facebook.com، وبشكل عام تخضع المنشورات التي يتم عرضها عبر واجهة API لعمليات تحقق من الأمان والخصوصية أكثر تقييدًا من تلك التي تخضع لها نفس المنشورات على فيسبوك نفسه.

يفرض النظام لدينا قيود على معدل استدعاءات API التي يتم إجراؤها بواسطة التطبيقات. للتعرف على المزيد عن القيود المختلفة ومنع تقييد تطبيقك، يرجى زيارة https://developers.facebook.com/docs/marketing-api/api-rate-limiting

يمكنك إضافة صور GIF متحركة إلى مقالتك باستخدام عنصر <figure> والذي يحيط بعنصر <img> يحيل إلى عنوان URL لصورة GIF المطلوبة. كما هو الحال مع الصور الأخرى، يمكنك إضافة شروح توضيحية وإسنادات إلى صور GIF.

يمكنك الرجوع إلى الوثائق لمزيد من التفاصيل والأمثلة هنا.

يمكنك إعادة استخدام عنوان URL لموجز على صفحات مختلفة، ولكن يُرجى العلم بأنه لا يتم استيعاب سوى المقالات التي لها عناوين URL معروفة تتطابق مع المجالات التي يتم المطالبة بها من خلال الصفحة.

أفضل طريقة نوصي بها هي استخدام موجز RSS منفصل لكل صفحة يحتوي فقط على المقالات التي يجب على هذه الصفحة استيعابها.

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

يمكنك تضمين رسومات ومحتوى تفاعلي في مقالاتك باستخدام <figure> مع فئة op-interactive. يجب أن يشتمل الشكل على <iframe>، والذي يشتمل على المحتوى المطلوب تضمينه.

يمكنك العثور على مزيد من التفاصيل والاطلاع على الأمثلة هنا.

يمكنك تحديد شرح توضيحي باستخدام العنصر <figcaption>. من داخل الشرح التوضيحي، يمكنك إضافة إسناد باستخدام عنصر <cite>.

يمكنك العثور على مزيد من التفاصيل والأمثلة في الوثائق هنا.

عندما تكون المقالة في وضع المسودة، فلن تظهر كمقالة فورية إلا إلى مسؤولي الصفحة فقط. بمجرد نشر المقالة وانتقالها إلى الوضع المباشر، يمكن لأي أحد مشاركتها على فيسبوك ويتم عرضها كمقالة فورية للجميع.

يرجى التحقق مما إذا كنت قد منحت إذن pages_manage_instant_articles للتطبيق أم لا. يعتبر هذا الإذن مطلوبًا لاستدعاء طرق واجهة API لقراءة وتحديث المقالات الفورية لصفحتك.

يمكنك التعرف على المزيد عن استخدام واجهة API هنا.

إذا كنت تستخدم السمة dir="rtl" لعرض لغة اتجاهها من اليمين إلى اليسار في مقالتك، فقد تكون المشكلة أنك تعرض المقالة في تطبيق لا يدعم اللغات ذات الاتجاه من اليمين إلى اليسار في المقالات الفورية.

يرجى التأكد من أنك تستخدم أحدث إصدار من التطبيق. الحد الأدنى للإصدار لكل تطبيق يدعم اللغات ذات الاتجاه من اليمين إلى اليسار هو:

• فيسبوك لنظام iOS: 52.0
• فيسبوك لنظام Android: 69.0
• مدير الصفحات لنظام iOS: 44.0

يرجى التأكد مما إذا كانت السمة dir="rtl" قد تم تعيينها في علامة <body> بالمقالة. إذا كانت مقالتك لا تستخدم إحدى اللغات ذات الاتجاه من اليمين إلى اليسار، يجب عدم تعيين هذه السمة في مقالتك.

تستخدم معاينة آخر الأخبار للمقالات الصورة المحددة في علامة بيانات og:image الأساسية في إصدار الويب من المقالة. يمكنك عرض مقطع فيديو بدلاً من الصورة من خلال إضافة فئة "fb-feed-cover" إلى أي فيديو تحتوي عليه مقالتك. يمكنك قراءة المزيد عن معاينات آخر الأخبار هنا.

في حالة مشاركة عنوان URL لمقالة ما قبل نشر المقالة الفورية، يتم إعادة التوجيه إلى إصدار ويب الهواتف المحمولة للمقالة. وبمجرد نشر المقالة الفورية، فإن جميع المشاركات التي تمت للرابط بما في ذلك تلك المشاركات التي تمت قبل نشر المقالة تعرض المقالة الفورية تلقائيًا عند العرض على الهواتف المحمولة.

تشتمل أداة القياس "views" (المشاهدات) في الوقت الحالي على مستخدمي iOS فقط. بينما يتم حساب المشاهدات على نظام Android بشكل مستقل في أداة القياس "android_views".

يمكنك الحصول على المزيد من المعلومات عن هذا الأمر هنا.

لقد قمنا مؤخرًا بتفعيل الدعم لموجز التطوير في مدير الصفحات لنظام Android. كطريقة بديلة يمكنك من خلالها عرض مقالاتك على نظام Android في الوقت الحالي، يمكنك إضافة المقالات على موجز الإنتاج كمسودات.

لتعديل المقالات الفورية لديك، يمكنك استخدام واجهة الصفحة. للقيام بذلك، يمكنك الانتقال إلى الصفحة في المتصفح الذي تستخدمه ثم الانتقال إلى أدوات النشر > المقالات الفورية. يمكنك عرض مقالاتك وتعديلها من هناك. يمكنك قراءة المزيد عن ذلك هنا: https://developers.facebook.com/docs/instant-articles/publishing.

المهلة المحددة لتنزيل الموجز في الوقت الحالي هي 30 ثانية.

لا، يجب أن يكون الرابط الذي تتم مشاركته هو عنوان URL المتعارف عليه للمقالة. إذا تم تغيير عنوان URL- على سبيل المثال، من خلال إضافة معلمات - يتم اعتباره عنوان URL مختلف.

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

يرجى التحقق من أن موجز RSS يتبع التنسيق المنصوص عليه في الوثائق هنا.

يجب أن يستخدم عنوان URL المتعارف عليه للمقالات المجال الذي تم تكوينه لصفحتك أو مجال فرعي تابع له. إذا كنت ترى مقالات جديدة يتم استيعابها، على الرغم من عدم إظهار التحديثات على المقالات الحالية، يرجى التحقق من أنك قمت بزيادة "op-modified" timestamp.

يمكنك العثور على المزيد من المعلومات عن هذا الأمر هنا.

من أشهر الأسباب التي تؤدي إلى عدم تحديث المقالات من موجز RSS هو أن op-modified timestamp للمقالة في الموجز يتطابق مع الإصدار الذي قمنا بجلبه في آخر مرة. لا نقوم بتحديث المقالة إلا إذا كان timestamp أحدث من آخر إصدار تم جلبه.

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

يمكنك الرجوع إلى الوثائق لمزيد من المعلومات عن كيفية جلب المقالات من موجز RSS هنا.

نحاول دائمًا تحميل وتقسيم موجز RSS بشكل كامل في غضون 10 ثوان. تشير رسالة الخطأ هذه إلى أن هذا الأمر لم ينجح.

من الطرق التي يمكن استخدامها لحل هذه المشكلة هو تضمين عناصر أقل في موجز RSS، على سبيل المثل من خلال تضمين المقالات الجديدة / التي تم تغييرها منذ آخر 10 دقائق. وبما أن الموجز يتم جلبه كل 3 دقائق، فلن يكون من الضروري تضمين المقالات التي لم يتم تغييرها.

للأسف، لا تتوفر لدينا قائمة بعناوين IP الخاصة بالمتتبع. وعلى الرغم من ذلك، يمكنك استخدام وكيل المستخدم للمتتبع الذي نستخدمه كطريقة بديلة: facebookexternalhit/1.1

إذا مر على أحد تحديثات المقالة الفورية الحالية أكثر من 24 ساعة بناءً على وقت op-modified، يتم تجاهله من عملية السحب. وذلك يعني أن الوقت المعدل يجب أن يكون في غضون 24 ساعة من الوقت المعدل الذي تم تعيينه في المقالة الحالية وليس الوقت الحالي. في تلك الحالات التي يتم فيها تجاهل التحديث، يمكنك إجراء التغييرات على المقالات يدويًا من خلال أداة تحرير المقالات الفورية التي تعمل على الويب.

يمكنك العثور على المزيد من المعلومات عن هذا الأمر هنا.

يرجى التحقق مما إذا كانت المقالات المكررة تستخدم عناوين URL متعارف عليها مختلفة أم لا. نستخدم عنوان URL المتعارف عليه للمقالة باعتباره المعرف الفريد لها، ولذلك يتم التعامل مع المقالات ذات عناوين URL المتعارف عليها المختلفة كمقالات مختلفة.

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

نعم، يتم تعيين كل صفحة بشكل فريد إلى اسم مجال ويعتبر هذا تعيين 1:1. يفرض النظام لدينا أن يكون للمقالات الفردية التي تنتمي إلى صفحة معينة عناوين URL متعارف عليها تنتمي إلى المجال المحدد أو المجال الفرعي لتابع له.

وعلى الرغم من ذلك، يجب أن يتطابق مجال عنوان URL لموجز RSS نفسه مع المجال الذي تم تعيينه للصفحة. يختص هذا التقييد فقط بعناوين URL المتعارف عليها للمقالات الموجودة في الموجز.

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

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

لا تتوفر في الوقت الحالي طريقة لنشر المقالات أو حذفها باستخدام واجهة API، إلا أننا نعمل على ذلك بالفعل.

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

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

يرجى التأكد من عدم استخدام العديد من علامات <br> في صف واحد. لتقسيم نص مقالتك إلى فقرات متعددة، نوصي باستخدام علامات الفقرة (<p>) بدلاً من فواصل الأسطر.

يرجى التأكد من إضافة فئة "op-tracker" إلى علامة <figure> التي تحيط ببيكسل التتبع. في حالة عدم وجود هذه العلامة، سيتم التعامل معها على أنها محتوى صورة مضمّن.

يرجى التأكد من استخدام تنسيق مدعوم لملف الفيديو. يمكنك العثور على قائمة بكل تنسيقات الفيديو المدعومة هنا.

كما يجب التأكد أيضًا من إحاطة محتوى الفيديو المضمن داخل علامة <figure>، وعدم إحاطة الفيديو داخل فقرة (علامة <p>).

تظهر رسالة التحذير هذه عادة عندما تقوم بإحاطة محتوى غير نصي - مثل الصور أو المحتويات المضمنة التفاعلية - بالفقرات (علامات <p>). يجب أن تحتوي الفقرات على نص فقط، بينما يجب إضافة أي محتوى آخر داخل علامة <figure> أو أي عناصر احتواء مناسبة أخرى.

لا، فإن عنصر الشرح التوضيحي (<figcaption>) لا يدعم إلا علامات <h1> و<h2> و<cite> فقط. علامة الفقرات (<p>) غير مدعومة.

سمة "muted" غير مدعومة في عناصر <video> في الوقت الحالي.

يتم تحديد الإعلانات في المقالات الفورية باستخدام عنصر HTML5 <figure>، الذي يحيط بالعنصر <iframe> الذي يحتوي على ترميز إعلانك. يمكنك تطبيق فئة op-ad إلى عنصر <figure> لتحديد أحد الإعلانات في مقالة. تتوفر طريقتان لتحديد الإعلانات: من خلال تحديد عنوان URL الخاص بالإعلان مباشرة باستخدام سمة "src" في iframe، أو من خلال تضمين مجموعة إجبارية من HTML والبرامج النصية داخل iframe.

يمكنك العثور على المزيد من المعلومات عن الإعلانات هنا: https://developers.facebook.com/docs/instant-articles/reference/ad.

لا يدعم عنصر الصورة القياسي استخدام صورة SVG. يمكنك بدلاً من ذلك استخدام محتوى تفاعلي مضمّن ("op-interactive") وإضافة عنصر <img> داخل iframe، مع تعيين سمة "src" على عنوان URL لصورة SVG المطلوب إضافتها.

يمكنك استخدام عنصر الخريطة تبعًا للمذكور في الوثائق التالية: https://developers.facebook.com/docs/instant-articles/reference/map. تعتبر هذه هي الطريقة الموصى بها لإضافة خريطة إلى المقالات الفورية.

إذا كنت تقوم بإضافة محتوى خرائط Google مضمّن لمقالتك كمحتوى مضمّن تفاعلي، فهناك مشكلة مشهورة تتعلق بطريقة عمل المحتوى المضمّن التي قد تمنع ظهور الخريطة. للتغلب على هذه المشكلة بطريقة بديلة، يجب إحاطة iframe من خلال تحميل محتوى الخريطة ("https://www.google.com/maps/embed?...") داخل iframe آخر.

يمكنك تضمين وحدات تفاعلية باستخدام الشكل op-interactive. يمكنك الحصول على المزيد من التفاصيل ونماذج الرموز هنا: https://developers.facebook.com/docs/instant-articles/reference/interactive.

لتحديد الارتفاع، قم بإضافة السمة "height" إلى عنصر <iframe> الذي يحيط بالمحتوى المضمّن. يجب أن تكون قيمة السمة رقمًا صحيحًا يشير إلى الارتفاع بوحدات البيكسل. يمكنك تعيين الارتفاع إلى 960 بيكسل بحد أقصى.

يمكنك إضافة غلاف من خلال إضافة علامة <figure> داخل العنوان. يمكنك استخدام صورة أو فيديو كغلاف من خلال إضافة علامة <img> أو <video> في الشكل.

يمكنك التعرف على المزيد عن الأغلفة هنا.

لإضافة مسافة بين الصور، يمكنك إضافة فقرات فارغة بين الصور - على سبيل المثال، <p>&nbsp;</p>.

لإضافة إسناد، يمكنك استخدام عنصر <cite> داخل عنصر <figcaption>.

في صور الغلاف، يمكن تحديد ظهور الإسناد بشكل دائم عن طريق تحديد أحد سمات المحاذاة الرأسية بشكل صريح في عنصر <cite>. بخلاف ذلك، لن يتم عرض الاستشهاد في الصورة إلى أن يتم توسيعها.

يمكنك إضافة محتوى تواصل اجتماعي مضمّن من خلال إضافة شكل بفئة "op-social" وإضافة iframe يحتوي على المحتوى المطلوب تضمينه.

يمكنك الرجوع إلى هذه الوثيقة لمزيد من التفاصيل وأمثلة الرمز البرمجي.

يجب استخدام رابط مباشر إلى ملف فيديو (على سبيل المثال، ملف بتنسيق mp4) لإضافة غلاف. وبما أن مقاطع الفيديو التي يتم استضافتها على فيسبوك لا توفر رابطًا مباشرًا، يجب استضافة مقطع الفيديو على موقع خارجي لاستخدامه كغلاف.

يمكنك استخدام بعض علامات HTML داخل عناصر قائمة، على سبيل المثال، لاستخدام الخط العريض مع النصوص أو إضافة الروابط. لتخصيص اللون أو نمط الخط، يمكنك استخدام محرر الأنماط في واجهة صفحة فيسبوك (الإعدادات->المقالات الفورية).

إذا كنت تريد تضمين فيديو باستخدام عنصر HTML من نوع <video>، لا يمكنك القيام بذلك حيث إننا لا ندعم تشغيل مقاطع فيديو متعددة في تسلسل.

إذا كنت تقوم بتضمين مشغل فيديو كمحتوى تواصل اجتماعي مضمّن في iframe، فيعتبر ذلك ممكنًا طالما كان مشغل الفيديو الذي يتم تضمينه يدعم ذلك.

علامات الاقتباس الطويل "blockquotes" غير مدعومة، ويجب وضعها خارج علامة الفقرة.

إذا كان عنوان المقالة طويلاً للغاية بصورة لا تسمح بعرضه في سطرين، يتم عرض العنوان فقط في آخر الأخبار. وإذا كان يمكن عرض العنوان بالكامل في سطر واحد، تعرض معاينة آخر الأخبار أيضًا بداية نص المقالة.

يرجى التأكد من عدم إضافة السمة "data-fb-disable-autoplay" إلى مقاطع الفيديو لديك.

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

يمكنك عرض فيديو في معاينة آخر الأخبار لمقالة ما من خلال إضافة فئة "fb-feed-cover" إلى أي فيديو تحتوي عليه مقالتك. يمكنك قراءة المزيد عن معاينات آخر الأخبار هنا

يجب تضمين عنصر <time> في ترميز HTML لكل مقالة من مقالاتك، باستخدام فئة op-published، لتحديد الوقت/التاريخ الذي تم نشر المقالة فيه لأول مرة.

لا تعتبر فئة op-modified مطلوبة. لا يجب تضمين عنصر <time> مع هذه الفئة إلا إذا كنت تقوم بتحديث محتوى المقالة وتريد منا تحديث إصدار المقالة الذي قمنا بتخزينه.

يرجى التأكد من إحاطة النصوص بالفقرات (علامات <p>). يمكنك الاطلاع على المزيد عن إنشاء ترميز مقالتك هنا.

يرجى التأكد من عدم إحاطة <figure> في الفقرات بعلامات <p>. يجب أن توجد الصور داخل علامات الأشكال التي يتم وضعها مباشرة أسفل علامة المقالة.

للأسف لا يمكنك إضافة شروح توضيحية إلى صور فردية في عرض شرائح. يمكنك إضافة شرح توضيحي واحد فقط لعرض الشرائح بالكامل.

يمكنك الرجوع إلى وثائق عروض الشرائح لمزيد من التفاصيل.

يمكنك إضافة تسجيلات الإعجاب والتعليقات إلى صورة من خلال تحديد السمة "data-feedback" في علامة <figure> التي تحتوي على الصورة. على سبيل المثال، يؤدي إضافة السمة data-feedback="fb:likes,fb:comments" إلى عرض كل من تسجيلات الإعجاب والتعليقات على الصورة.

لمزيد من المعلومات، يمكنك الرجوع إلى وثائق سمة الملاحظات.

عند تعيين العرض لأحد العناصر مثل المحتوى المضمّن التفاعلي، يرجى استخدام قيمة صحيحة تحدد العرض بوحدات البيكسل. تبعًا للإعدادات الافتراضية، يتم عرض العناصر بالعرض الكامل.

لعرض محتوى تفاعلي مضمّن دون أي هوامش، يمكنك إضافة فئة "no-margin"إلى iframe الذي يضم المحتوى المطلوب.

إذا قمنا بالفعل بالموافقة على موجز RSS لصفحتك، فلا يجب إعادة تقديمه للحصول على الموافقة مرة أخرى إذا قمت بتغيير عنوان URL للموجز.

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

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

يرجى التأكد من أنه تم في تطبيق فيسبوك تعيين معرف متجر iPhone أو معرف متجر iPad حقيقي (لأغراض الاختبار لا يلزم أن يكون هذا المعرف هو المعرف الحقيقي لك، حيث يمكنك استخدام أحد التطبيقات المتوفرة في متجر تطبيقات Apple)، وتمكين iOS - iPad في المنصات المدرجة بمركز التطبيقات.

وهذا سلوك مقصود في التصميم. يقوم مربع حوار الأخبار بنشر المحتوى الذي يتضمن مرفق، لذلك من غير الممكن تخصيص المزيد من المرفقات.

يرجى الرجوع إلى وثائق عن بعض أفضل ممارسات تحسين الصور لإنشاء معاينات رائعة هنا.

لا تتوفر بيانات الاستجابة إلا في حالة تسجيل دخول المستخدم إلى تطبيقك باستخدام فيسبوك وقيامه بمنح الإذن publish_actions. وهذا الأمر موضح أيضًا في الوثائق هنا.

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

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

سيبحث المتتبع عن سجل AAAA ويعرض رمز الاستجابة 0 في حالة عدم العثور عليه. تأكد من أنه تم تحديث سجل AAAA بشكل صحيح عند قيامك بتغيير عنوان URL أو الخادم.

يرجى مراجعة تحديث عناوين URL لمزيد من المعلومات.

ينطبق تغيير علامات og:title أو og:image أو ما يشابهها على عمليات المشاركة المستقبلية فقط لذلك الرابط.

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

إذا كنت قد قمت بمشاركة رابط ثم قمت بتحديث الصورة، ستستمر المشاركة القديمة في عرض الصورة القديمة ما لم تقم بتحديثها في المنشور.

1. تنقل إلى المنشور في آخر الأخبار لديك.
2. انقر على علامات الحذف في الزاوية العلوية اليسرى للمنشور.
3. حدد تحديث مرفق المشاركة.

نحن لا نجمد العناوين إلا بعد اتخاذ عدد من الإجراءات ضد هذا الكائن (على النحو المحدد هنا: تحديث عناوين URL.

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

بالنسبة إلى الصور الكبيرة، حاول تعيين نسبة العرض إلى الارتفاع في صورك بحيث تكون قريبة من 1.91:1 قدر الإمكان، حتى يمكن عرض الصورة كاملة دون اقتصاص في الموجز.

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

ربما قام نظام ترشيح المحتوى بوضع علامة على رابطك. إذا كنت تعتقد أن هذا حدث عن طريق الخطأ، يرجى تقديم بلاغ على موقع المساعدة مع التأكد من تضمين عنوان URL ذي الصلة.

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

-التخزين المؤقت المسبق لصورتك عن طريق تشغيل عملية استخلاص من خلال Sharing Debugger - استخدام علامتي og:image:height وog:image:width في تعيين الصورة صراحةً

يتم ربط كل المشاركات وتسجيلات الإعجاب بعنوان URL محدد (والذي نسميه عنوان URL المتعارف عليه). سيؤدي تغيير هيكلة الموقع لاستخدام عناوين URL جديدة إلى بدء إسناد تسجيلات الإعجاب والمشاركات إلى عنوان URL الجديد ذلك.

يرجى مراجعة تحديث عناوين URL لمزيد من المعلومات.

يتم ربط كل المشاركات وتسجيلات الإعجاب بعنوان URL محدد (والذي نسميه عنوان URL المتعارف عليه). سيؤدي تغيير هيكلة الموقع لاستخدام عناوين URL جديدة إلى بدء إسناد تسجيلات الإعجاب والمشاركات إلى عنوان URL الجديد ذلك.

يرجى مراجعة تحديث عناوين URL لمزيد من المعلومات.

يتم عرض الصور التي يقل حجمها عن 600 × 315 بيكسل ويزيد عن 200 × 200 بصورة مربعة صغيرة.

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

إذا كنت تستخدم عنوان URL مختلف ولكنك لا تزال ترى الصورة القديمة، يمكنك أيضًا الانتقال إلى مصحح أخطاء المشاركة وإعادة استخلاص معلومات URL:

يجب أن تكون جميع عناوين URL مطلقة حيث إنها تمثل الموقع المتعارف عليه لأحد الموارد (صفحة/صورة)، وكي نتمكن من إسناد المشاركات وتسجيلات الإعجاب إلى عنوان URL الصحيح وتخزين الصور مؤقتًا بشكل صحيح.

لم تعد الصورة الأصلية متوفرة أو حجمها كبير جدًا أو تعذر الحصول عليها بسبب مشكلة مؤقتة. تأكد من أنه يمكن للمتتبع الخاص بنا الوصول إلى عنوان URL للصورة وأن حجمها لا يزيد عن 8 ميجابايات وأن التأخر في عرضها لا يتجاوز سوى بضعة ثوانٍ.

تأكد من عدم إزالة الصورة القديمة من الموقع عند تغيير og:image للصفحة، لأنه حينئذ ستعرض المشاركات الحالية هذه المنطقة البيضاء.

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

إذا كنت تحاول قراءة تفاصيل الإعلان قبل حفظه بالكامل، فقد تتلقى GraphMethodException عبر رسالة مثل Unsupported get request. Object with ID 'XXXXXXXXXXXXXXXXXX' does not exist, cannot be loaded due to missing permissions, or does not support this operation..

يجب الانتظار بعض الوقت حتى يتم حل هذه المشكلة قبل محاولة الحصول على تفاصيل الإعلان.

قد تواجه في بعض الأحيان خطأ في التحقق عند محاولة استخدام تصميم معين في حملة إعلانية محددة. ويمكن أن يحدث ذلك عندما يكون للحملة الإعلانية هدف غير متوافق مع التصميم الذي تستخدمه. على سبيل المثال، قد يحدث ذلك عندما يشير تصميمك إلى لعبة لوحة، في حين أن هدف الحملة الإعلانية هو "MOBILE_APP_INSTALLS".

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

يرجى التحقق من أن جلسات التحميل التي لم تكن تحتوي على العناصر محل النقاش لم تتضمن أي حالات فشل.

سيتم حذف العناصر التي لم تعد موجودة في موجز جلسة التحميل الناجحة فقط عند تعيين deletion_enabled على القيمة صواب.

إذا كنت تواجه هذا الخطأ، يرجى التحقق من حالة الحساب الإعلاني الذي يتم تحديده. يظهر هذا الخطأ غالبًا عندما يكون الحساب بحالة لم تتم تسويتها.

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

الرجاء مراجعة بنية مواصفات الاستهداف، وذلك لضمان تضمن مواصفات الاستهداف لقيم ومعلمات geo_locations صالحة على وجه التحديد.

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

يرجى العلم أنه لن يتم تعيين مواصفات التحويل لبعض الأهداف افتراضيًا ويجب تحديدها بشكل واضح.

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

يحدث ذلك نظرًا لأنه تم تمكين الترحيل أمان النشر بتدفق لعنوان URL في تطبيقك.

في حالة تشغيل هذا الإعداد في تطبيقك، لن يسمح النظام بإنشاء إعلانات نشر الروابط من أي نوع ما لم يتم إعادة توجيهها إلى عنوان URL الذي يخص Canvas المشار إليه في إعداد تطبيقك. ولا يجب أن يكون تمكين هذا الإعداد شرطًا إلا إذا كان تطبيقك هو تطبيق Canvas ويقوم بنشر أحداث يتم من خلالها إعادة التوجيه إلى نطاق تطبيق Canvas مرة فقط.

تم ربط المستخدم على الأرجح بالحساب عبر ارتباط مدير الأعمال، مما يعني أنه لن يظهر كارتباط واجهة Graph API صريح.

الرجاء التأكد من أنك قمت بتحديد الفئات الشريكة في حقل الاستهداف المناسب. تحتوي الفئات الشريكة التي تم استرجاعها عبر نقطة النهاية "/partnercategories" على حقل يحمل الاسم "targeting_type" يتم من خلاله تحديد حقل الاستهداف المطلوب استخدامه عند تحديد نوع الاستهداف.

على سبيل المثال، إذا كانت الفئة الشريكة تعرض "targeting_type" من نوع "behaviors"، يجب استخدام هذه الفئة الشريكة في حقل "behavior" في مواصفات الاستهداف.

تتوفر المزيد من المعلومات عن أنواع الاستهداف والفئات الشريكة هنا: https://developers.facebook.com/docs/marketing-api/partnercategories/v2.3#targeting_types

يمكن أن يحدث هذا الخطأ بسبب جمهور مخصص لم يتم تعيين أية تضمينات/استثناءات له. وأفضل طريقة لحل هذه المشكلة هي إنشاء جمهور مخصص جديد والتأكد من تعيين بعض التضمينات/الاستثناءات.

تتوفر المزيد من المعلومات عن الجمهور المخصص هنا: https://developers.facebook.com/docs/marketing-api/custom-audience-targeting/v2.3.

يمكن أن يكون للمجموعة الإعلانية daily_budget وlifetime_budget. ويجب أن تكون قيمة daily_budget التي يتم تحديدها بعملة حسابك 100 سنت على الأقل وأن تكون المدة أكبر من 24 ساعة. وإذا قمت بالاستعلام على أي من هذين الحقلين، فإنه يتم عرض كل منهما. وفي حالة عدم استخدام حقل، يتم عرض القيمة 0.

للتعرف على المزيد، يرجى زيارة: https://developers.facebook.com/docs/reference/ads-api/adset.

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

لمزيد من المعلومات عن كيفية استخدام تقسيم الصفحات استنادًا إلى المؤشر، يرجى زيارة الرابط التالي: https://developers.facebook.com/docs/graph-api/using-graph-api/v2.0#paging.

قد يرجع ذلك إلى أنه تم إنشاء بعض المنشورات بشكل مضمن. لاسترجاع هذه المنشورات المضمنة، يرجى الاطلاع على الملاحظة الموجودة في حقل /promotable_posts "is_inline" أسفل القسم التالي في الوثائق: https://developers.facebook.com/docs/reference/ads-api/adcreative/v2.2#object_story_spec

طالما أجاب المستخدم عن السؤال الأول، ستكون الفترة الزمنية للمراسلة مفتوحة. إذا كانت الإجابات المقدمة تؤدي إلى استبعاد المستخدم أو لم يقم المستخدم بالرد، فستنتهي تجربة الإعلان وسيمرر الإعلان التحكم في سلسلة الرسائل إلى التطبيق المستهدف ويوفر بيانات التعريف "messenger_lead_gen_incomplete"، وهذا يسمح للنشاط التجاري بالحصول على تجربة احتياطية لتحويل الأشخاص من غير العملاء المحتملين إلى عملاء. يمكنك الاطلاع على أحداث webhook لبروتوكول التسليم (HOP) بعد إعلان تجميع بيانات العملاء المحتملين للحصول على مزيد من المعلومات

يتم تمكين إرسال الملخص افتراضيًا فقط عند تحديد تطبيق في مربع الحوار "إنشاء قالب" داخل الإعلان. يُرجى العلم أنه يمكن تعطيل الملخص في الإعلان بعد تحديد التطبيق المرتبط. وكذلك في حالة عدم تحديد تطبيق، سيقوم إعلان تجميع بيانات العملاء المحتملين بتمرير التحكم في سلسلة الرسائل إلى المتلقي الأساسي للتسليم، عند إعداده، أو تحرير التحكم في سلسلة الرسائل. سيتم إرسال أي رسالة متابعة بعد إرسال بيانات العميل المحتمل إلى التطبيقات المشتركة. يمكن للتطبيقات الاستعلام عن واجهة API التحويلات لاسترداد سجل الرسائل والحصول على المعلومات التي تتم مشاركتها خلال تجميع بيانات العملاء المحتملين.

يتم افتراضيًا حظر واجهة API الإرسال وWebhooks عندما يكون إعلان تجميع بيانات العملاء المحتملين قيد التقدم. سيتمكن تطبيق تجميع بيانات العملاء المحتملين في Messenger (معرف التطبيق: 413038776280800) من التحكم في سلسلة الرسائل. يمكن تعطيل هذا السلوك باستخدام مفتاح التبديل "حظر واجهة API الإرسال" في مربع الحوار "إنشاء قالب" داخل الإعلان

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

يتم تثبيت التطبيقات من موقع التطبيق على الويب باستخدام تسجيل دخول فيسبوك ومنح إذن pages_messaging لصفحة معينة. ستظهر التطبيقات المصرح لها في إعدادات الصفحة من المراسلة المتقدمة.

ستظهر التطبيقات المصرح بها للصفحة فقط. يمكنك رؤية التطبيقات المصرح بها في إعدادات الصفحة في المراسلة المتقدمة. ويتم تثبيت التطبيقات من موقع التطبيق على الويب باستخدام تسجيل دخول فيسبوك ومنح إذن pages_messaging لصفحة معينة.

ستكشف تجارب الدردشة التلقائية (مثل، "البرامج التلقائية") عن أن الشخص يتفاعل مع خدمة تلقائية:

• في بداية أية محادثة أو سلسلة رسائل
• بعد فترة زمنية طويلة
• عندما تنتقل الدردشة من التفاعل البشري إلى التجربة التلقائية

تعرف على المزيد حول هذه السياسة من هنا.

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

نعم، يمكن لتطبيق فيسبوك واحد أن يشترك في عدة صفحات. وبمجرد أن ينتقل التطبيق للمراجعة مثل الإذن pages_messaging، فيمكن للتطبيق الاشتراك لتلقي webhooks على أكثر من صفحة. وسيرجع الأمر إليك بخصوص الحصول على سياق كل webhook بناءً على حمولة البيانات.

نعم، يمكن لأكثر من تطبيق الاشتراك في الصفحة. عندما تتعامل عدة تطبيقات مع نفس المحادثة، فإنه يفضل استخدام بروتوكول التسليم لمعرفة البرنامج التلقائي الذي يمتلك سلسلة الرسائل في أي وقت محدد.

إليك حل بديل لاستخدام الحسابات الاختبارية للمنصة لتكامل منصة Messenger الخاص بك:

1. من صفحة الأدوار بتطبيقك، قم بإنشاء حساب اختباري جديد بالنقر على الزر "إضافة".
2. قم بتبديل خيار هل تريد السماح للحسابات الاختبارية بالوصول إلى هذا التطبيق؟ وقم بمنح الأذونات "manage_pages" و"page_messaging".
3. استخدم الزر "تعديل" واحصل على رمز وصول لهذا المستخدم (باستخدام الإصدار 2.6). يرجى حفظ رمز الوصول لاستخدامه لاحقًا.
4. استخدم الزر تعديل لتسجيل الدخول كحساب اختباري.
5. بعد تسجيل الدخول، قم بإنشاء صفحة كحساب اختباري.
6. واستخدم رمز وصول المستخدم الخاص بالحساب الاختباري للحصول على رمز وصول الصفحة لهذا المستخدم. ويمكنك القيام بذلك باستخدام الاستدعاء التالي:

   https://graph.facebook.com/v2.6/me/accounts?access_token=[TEST_USER_ACCESS_TOKEN]

   (الوثائق)
7. استخدم رمز وصول الصفحة لربط تطبيق فيسبوك الخاص بك بصفحتك:

   https://graph.facebook.com/v2.6/me/subscribed_apps?method=POST&access_token=[TEST_USER_PAGE_ACCESS_TOKEN]
           

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

   GET /oauth/access_token?  
       grant_type=fb_exchange_token&           
       client_id={app-id}&
       client_secret={app-secret}&
       fb_exchange_token={short-lived-token} 
           

هناك عدة أسباب لحدوث ذلك:

• استخدام معرف من تسجيل دخول فيسبوك. لا تصلح معرفات المستخدم من تسجيل دخول فيسبوك للعمل مع واجهة API الإرسال/الاستلام. ولن تصلح سوى معرفات المستخدم التي تم الحصول عليها من خلال المصادقة عبر منصة Messenger للعمل مع منصة Messenger.
• استخدام معرف برمز وصول صفحة غير صحيح. يتم توفير معرفات المستخدم لمنصة Messenger على مستوى الصفحة، وبالتالي تكون مرتبطة بصفحة محددة. وإذا استخدمت معرف مستخدم صالح ولكن برمز وصول صفحة مرتبط بصفحة مختلفة، فلن يعمل الاستدعاء. تأكد من استخدام معرف المستخدم ورمز وصول الصفحة المقترن بالصفحة ذاتها.
• الإرسال إلى رقم هاتف لم يتم التحقق منه مؤخرًا. عند استخدام واجهة API الإرسال برقم هاتف، فلن نرسل الرسائل إلا في حالة التحقق من رقم الهاتف مؤخرًا. حتى في حالة عرض رقم الهاتف كرقم تم التحقق منه، دون أن يكون التحقق قد تم مؤخرًا، فقد يفشل الإرسال. أعد التحقق من رقم هاتفك وانتظر 24 ساعة قبل إعادة المحاولة.

عند استخدام المكون الإضافي "إرسال إلى Messenger"، يمكنك استخدام معلمة مرجع البيانات كمعلمة مرور لإرسال أي معلومات تتعلق بسياق النقرة.

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

توفر لوحة معلومات التطبيق ضمن إعدادات Messenger زرًا باسم "عرض الأخطاء الأخيرة" يوضح ما إذا كانت أحداث webhooks تتلقى استجابة 200 أم أنها فشلت في ذلك.

تتوفر أداة تعرض الأخطاء الأخيرة في أحداث webhook. وإذا فشل عرض أحداث webhooks، فلن تلغي خوادم Facebook اشتراك عنوان URL الخاص بك. وللعثور على الأداة، انتقل إلى لوحة معلومات التطبيق > Messenger > الإعدادات، وضمن بطاقة أحداث Webhooks، يتوفر زر باسم عرض الأخطاء الأخيرة

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

ولاحظ أيضًا أنه يتم إرسال رمز الاستجابة الناجحة بدون تأخير. تنتهي مهلة استدعاء webhook بعد 20 ثانية. تأكد من بناء الرمز البرمجي ليساعد على معالجة وحدات webhook بشكل غير متزامن كي يتم إرسال رمز حالة نجاح على الفور وتتم المعالجة بشكل منفصل.

تحتوي استدعاءات webhook على حقل في العنوان اسمه X-Hub-Signature، والذي يمكن استخدامه للتحقق من أن الاستدعاء وارد من فيسبوك.

توجد خطوتان لتلقي الاستدعاءات. أولاً، تأكد من إعداد webhook بشكل صحيح (https://developers.facebook.com/docs/messenger-platform/webhook-reference#setup). هناك مؤشر يدل على إعداد وحدات webhook بشكل صحيح.

ثانيًا، يجب الاشتراك في كل صفحة. سيتم إدراج كل الصفحات التي تم الاشتراك فيها.

إذا تعرضت استدعاءات webhook للفشل لفترات زمنية طويلة، فسوف يتم إلغاء اشتراك تطبيقك وسيتعين عليك إعادة إضافة webhook الخاص بك وإعادة اشتراك صفحتك.

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

لا يمكنك التحكم في طريقة عرض المنشور في آخر الأخبار أو اليوميات عند مشاركة حدث Open Graph بعد توفير علامات Open Graph لصفحتك. يقوم فيسبوك بتحسين المنشورات تلقائيًا لضمان تحقيق أقصى تفاعل ممكن مع المحتوى الذي تقدمه.

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

إذا كانت صفحة الويب تستخدم علامات OpenGraph الوصفية وتتضمن إدخال og:image، فإننا سنقوم بجلب هذه الصورة وعرضها في المعاينة. بالإضافة إلى ذلك، إذا كان موقعك يوفر كل من og:image وog:image:width og:image:height، فسيتم استخدام هذه الصورة حتى لو كان ذلك في أول مشاركة يتم إنشاؤها.

ويعني الإخفاق في توفير هذه العناصر أنه سيلزمك الانتظار حتى تقوم المتتبِعات الخاصة بنا بإحضار الصور وتحليها أولاً. راجع http://ogp.me/#structured للتعرف على مثال عن كيفية حدوث ذلك.

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

يمكنك تعيين لغة الزر "أعجبني" باستخدام المعلمة 'locale' في JS SDK. وهذا سيعمل بشكل مناسب مع المستخدمين الذين لم يقوموا بتسجيل الدخول. أما في حالة قيام المستخدم بتسجيل الدخول، تتم مراعاة تفضيلات اللغة لديه. وفي حالة تعيينها على لغة محددة، يظهر الزر "أعجبني" بهذه اللغة.

يمكنك اختبار هذا السلوك عن طريق زيارة الزر "أعجبني" دون تسجيل الدخول إلى فيسبوك (أو عن طريق استخدام جلسة خاصة في المتصفح).

يخالف هذا الإجراء سياسة فيسبوك فيما يتعلق بالملء المسبق لمنطقة النص عند المشاركة إلى فيسبوك. يجب على مستخدم التطبيق الخاص بك ملء النص الذي يريد مشاركته بنفسه.

يخالف الملء المسبق لمنطقة النص عند المشاركة سياسة المنصة 2.3 ( https://developers.facebook.com/policy/#control ). ونحن نفرض هذه السياسة لضمان مشاركة المستخدمين ما يريدون مشاركته على فيسبوك بشكل دقيق، وعدم مشاركة نصوص لم يوافقوا عليها عن طريق الخطأ.

يمكن أن يكون ذلك هو السلوك المتوقع، إذا قمت بتغيير أو تعديل عنوان URL لصفحة الويب. تتم معاملة كل عنوان URL موجود في المكون الإضافي للتعليقات كعنصر open graph منفصل، ويتم ربط التعليقات بهذا الكائن. وبالتالي، إذا قمت بتعديل عنوان URL، يتم إنشاء كائن جديد ولذلك لا يتم عرض التعليقات الحالية في الصفحة.

لا، غير مسموح لك بنشر تعليقات في المكون الإضافي للتعليقات عبر واجهة API.

لن يسمح المكون الإضافي للمشاركة بتمرير معلمات مخصصة وتقوم بدلاً من ذلك بسحب بيانات التعريف مباشرةً من علامات Open Graph الوصفية للصفحة.

للتعرف على المزيد عن أفضل ممارسات مشاركة المحتوى، يرجى الرجوع إلى هذه الوثائق: https://developers.facebook.com/docs/sharing/best-practices

Yes, Whatsapp Flows can be sent with On-Premises API. You can learn more about Whatsapp Flows here, or learn how to get started with Whatsapp Flows and On-Premises API here.

No this is not possible. Numbers that are registered under WABAs (WhatsApp Business Accounts) can only message regular WhatsApp accounts.

We will provide a seven day grace period post sending the warning. This will allow time for businesses to adjust their behavior. If businesses continue to exceed our internally set threshold of calls to the Contacts API vs. number of messages sent, we will permanently disable the phone number.

Interactive messages can be reopened by the user in order to resend an option. This is in case of mistyping the desired option or wanting to choose a new option.

Through user testing we’ve identified 10 as the optimal number of rows to provide a good user experience. If you have a list of more than 10 options, and cannot condense into one list message, we recommend creating an additional step in the flow and using two list messages. During testing businesses had higher response rates and conversions with this approach than using text-based lists.

Through user testing we’ve identified 3 as the optimal number of buttons to provide a good user experience. If you have a list of more than 3 options, and cannot condense it into one button message, we recommend using list messages. During testing, businesses had higher response rates and conversions with list messages than using text-based lists.

There may be a very small number of users for whom their app version does not support this feature, the business will receive a webhook notification throwing an error that describes why the message was unable to be received. It is up to the business to determine how to handle this error elegantly. Best practice would convert the interactive message to a text-based list to allow the user to complete the workflow.

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.

لا، لا ندعم حاليًا تغيير المسار الافتراضي إلى تخزين الوسائط (/usr/local/wamedia/). ويجب أن تكون جميع وحدات تخزين الوسائط في هذا الموقع الافتراضي حتى تعمل بشكل صحيح.

لا، يجب أن نستخدم حاليًا نظام AWS EFS لمشاركة وحدة تخزين الوسائط بين Coreapp وWebapp.

لا، ولا ندعم KOPS. ولكننا ندعم حل خدمات الويب من Amazon (AWS) استنادًا إلى ECS. ويتوفر لدينا أيضًا إعداد Kubernetes minikube عام.

ستحقق عقدة Coreapp من الدليلين /usr/local/waent/data و/usr/local/waent/log ضمن حاوية Coreapp مما يضمن توفّر 10 ميجابايت من مساحة التخزين على الأقل، وإلا فسيظهر هذا الخطأ الفادح.

تحقق من السجلات ودليل البيانات للتأكد من أن لديك مساحة تخزين كافية.

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

استخدم نقطة النهاية في واجهة services API الخاصة بجمع البيانات المهملة في قاعدة البيانات لإزالة الرسائل وإيصالات الرسائل المقابلة من الجدولين messageStore.messages وmessageStore.messages_receipt_log.

تحقق مرة أخرى من إعداد التطبيق pass_through. ولن تتلقى أي عمليات لمعاودة اتصال حالة القراءة إذا قمت بتمكين pass_through مع عميل واجهة API الخاصة بتطبيق WhatsApp للأعمال بالإصدار v2.29.1 أو الإصدارات الأحدث.

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

تقوم مجموعة البيانات المهملة في قاعدة البيانات بتنظيف الجدولين messages وmessages_reciept_log بشكل دوري للمساعدة في إدارة قاعدة البيانات.

يحتفظ جامع البيانات المهملة برسائل معينة للسماح بعملية عرض/معالجة ناجحة. فعلى سبيل المثال، الاحتفاظ بالرسائل الواردة لفترة زمنية معينة للسماح لعمليات دمج الأعمال بتحديد الرسائل كمقروءة.

يجمع Coreapp البيانات المهملة على فترات زمنية عشوائية (أي كل بضع ساعات). ويحدث ذلك لمنع لنخفاض الأداء المحتمل في مكدسات التوفّر العالي بسبب اتصال قاعدة البيانات.

تكون مجموعة البيانات المهملة مستقلة عن قائمة انتظار الاستدعاء. فعلى سبيل المثال، في حالة عدم توفّر خادم حدث Webhook لمدة أربعة أيام، سيتم تخزين الاستدعاءات لعرضها عند استعادة اتصال خادم حدث Webhook.

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

قبل الإصدار v2.29.x، كان من المحتمل أن يزداد حجم قائمة انتظار الرسائل الصادرة مع مرور الوقت بسبب خطأ. وتحل الترقية إلى الإصدار v2.29.3 هذه المشكلة.

ستكون مسؤولًا عن استخدام رمز QR المناسب استنادًا إلى موقع المستخدمين المتوقع، وكذلك لغتهم.

يمكن إنشاء رموز QR الآن وإدارتها مباشرة ضمن واجهة API الخاصة بإدارة تطبيق WhatsApp للأعمال، ويمكن للمستخدمين مسحها ضوئيًا باستخدام كاميرا WhatsApp أو iOS أو Android.

بالإضافة إلى استخدام رموز QR في WhatsApp

• يمكن تخصيص الرسائل المكتوبة مسبقًا بالكامل ويمكنك تغييرها أو حذفها في أي وقت،
• وسينتقل المستخدمون دائمًا إلى التطبيق مباشرة بدون أية صفحات خلالية،
• وسترسل التجربة داخل التطبيق الخاصة بالرمز منتهي الصلاحية رسالة واضحة إلى المستخدم.

إذا كان أي مستخدم يحاول الوصول إلى رمز QR أو رابط قصير تم حذفه، فستظهر رسالة خطأ تشير إلى انتهاء صلاحية رمز QR/الرابط القصير.

إذا كان المستخدم لديه عميل WhatsApp للكمبيوتر، فسيتم بدء محادثة مع نشاطك التجاري. وإذا لم يكن الأمر كذلك، فستتم مطالبة المستخدم بتثبيت عميل WhatsApp للكمبيوتر.

تعمل الروابط القصيرة الجديدة على تمكين الرسائل المكتوبة مسبقًا والمرتبطة برابط يمكن تعديله أو حذفه في أي وقت. وتعمل أيضًا على تقليل بناء جملة عنوان URL إلى رمز برمجي عشوائي يعمل بدوره على إلغاء الحاجة إلى تضمين الرسائل في عنوان URL ويحجب رقم الهاتف.

نوصي باستخدام تنسيق الملف .svg للحصول على أفضل جودة في مواد الطباعة.

We are announcing the deprecation of Groups through the WhatsApp Business API. Starting July 8, 2020, only API phone numbers in a group created prior to July 8th can continue to use/manage Groups through the WhatsApp Business API. All other API phone numbers won’t be able to create/manage Groups through the Whatsapp Business API. On October 8, 2020, we will deprecate this feature for all API phone numbers (i.e., API phone numbers will be removed from their groups and no longer be able to send messages to their group).

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

إذا كنت ترغب أنت أو العميل النهائي في طلب حساب النشاط التجاري الرسمي في واتساب، فراجع التعليمات الواردة في قسم وثائق طلب حساب النشاط التجاري الرسمي.

لا، لا تنطبق قيود المراسلة حاليًا إلا على الرسائل التي بدأها النشاط التجاري (الإشعارات).

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

لن يتم إنشاء ألبوم في حالة تلبية أحد المعايير التالية:

1. صور بشروحات توضيحية
2. فاصل غير مقروء - يعرض المستخدم بعض الصور، ولكن ليس البقية
3. رأس التاريخ - يوم جديد بين عمليات العرض

لا، لا يعمل عميل واجهة API واتساب للأعمال حاليًا على Docker في Windows. ولتلبية احتياجات التطوير، يكون الحل الموصى به هو استخدام جهاز ظاهري يعمل بنظام التشغيل Linux وتشغيل Docker فيه. وبالنسبة لأحمال العمل، نوصي باستخدام خادم يعمل بنظام التشغيل Linux لتجنب حدوث مشكلات في التوافق والأداء.

بالنسبة لعميل واجهة API واتساب للأعمال الذي يعمل بالإصدار 2.21.6، عند قطع اتصال العميل عن الخادم، فقد يظل الاتصال مقطوعًا لبضع دقائق (4 دقائق كحد أقصى) وبعد ذلك ستتم إعادة محاولة الاتصال. ستسمح الترقية إلى الإصدار 2.23.4 بوجود فترة تعطل أقل للعميل عند محاولة الاتصال بالخادم.

يتعلق الرمز البرمجي للخطأ 471 بتقييدات معدلات الاستدعاء القائمة على الجودة. ولمزيد من المعلومات، راجع وثائق تقييدات معدلات الاستدعاء القائمة على الجودة.

تبدأ كل الأنشطة التجارية عند أقل مستوى وستتم ترقية هذا المستوى تلقائيًا إلى مستويات أعلى عندما ترسل الأنشطة التجارية المزيد من الرسائل التي تتمتع بجودة عالية.

نعم، عند إرسال قالب الرسالة وفي حالة فشل عرضها في نهاية التلقي، ستتلقى استدعاء بالحالة "فشل" مع "عدم توفر البنية" في كائن الخطأ الذي يشير إلى أنه تعذر عرض الرسالة. وبناءً على المستلم، قد تتلقى أيضًا استدعاء بالحالة "معروض" الذي يشير ببساطة إلى أنه تم عرض الرسالة إلى المستلم بعد فشل المستلم في عرض الرسالة.

فيما يلي أخطاء متعلقة بالتحقق من الصحة من جانب إرسال قالب الرسالة وسبب احتمالية ظهورها لك:

• "لا توجد قوالب الرسائل باللغة your-language" أو "لا توجد قوالب الرسائل باللغة your-language واللغة المحلية your-locale" — حزمة اللغة المتوفرة غير موجودة. ويمكنك التحقق من حساب مدير الأعمال.
• "القالب your-template-name غير موجود باللغة your-language" أو "القالب your-template-name غير موجود باللغة your-language واللغة المحلية your-locale" — إنك تحاول استخدام قالب غير موجود (لم يتم إنشاؤه أو لم يتم اعتماده بعد). وإذا كنت تحاول إرسال رسالة بقالب تم حذفه، فستتلقى أيضًا هذا الخطأ.
• "عدد localizable_params num1 غير متطابق مع عدد المعلمات المتوقع num2" — إنك تحاول إرسال رسالة قالب بمعلمات غير متطابقة مع عدد المعلمات المتوقع. لذا يرجى التحقق من استدعاء واجهة API لديك للتأكد من صحتها.
• "your-template-name هو قالب منسق ويتطلب واجهة API رسالة القالب لاستخدامه" — إنك تحاول إرسال قالب رسالة وسائط كقالب رسالة عادية. وتأكد من أن نوع الرسالة هو template. ولمزيد من المعلومات، يمكنك الرجوع إلى وثائق قوالب رسائل الوسائط.
• بمجرد اعتماد القوالب في مدير الأعمال (أو حذفها)، يمكن أن يستغرق ذلك 20 دقيقة كحد أقصى في عميل واجهة API الخاصة بتطبيق WhatsApp للأعمال لتلقي القوالب المُحدثة. وإذا كنت تحاول إرسال رسالة بقالب تم اعتماده للتو وتلقيت خطأ يخبرك بأن القالب غير موجود، يمكنك إعادة محاولة إرسال الرسالة بعد انتظار المدة المحددة أعلاه.

يمكن إرسال رسائل مكررة إلى Webhook في واتساب نظرًا لأن الضمان الوحيد المتوفر هو أنه سيتم تلقي الرسائل مرة واحدة على الأقل (في مقابل مرة واحدة بالضبط). وإذا كان ذلك يؤثر على طريقة معالجة الرسائل من جانبك، فمن ثمّ نقترح إلغاء تكرارات رسائل Webhook استنادًا إلى معرف الرسالة.

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

بدءًا من الإصدار 2.18.26، تسمح نقطة نهاية إحصاءات التطبيق بتصدير أدوات القياس الداخلية بتنسيق نص Prometheus. ولمزيد من المعلومات، راجع وثائق التحقق من المثيل.

سيتم إرجاع كائن profile فارغ فقط في حالة ملء الملف الشخصي للنشاط التجاري جزئيًا. ويرجى الترقية إلى v2.21.4 لحل هذه المشكلة.

لمزيد من المعلومات حول إكمال الملف الشخصي للنشاط التجاري، راجع وثائق إعدادات الملف الشخصي لنشاط تجاري.

إذا كنت تتلقى خطأ مشابهًا للخطأ التالي عند إعداد نشر خدمات الويب من Amazon (AWS)، فحاول تغيير الاسم إلى اسم تجميع يستخدم 8 أحرف أو أقل.

اسم البلد (رمز مكوّن من حرفين) [أستراليا]:اسم الولاية أو المقاطعة (الاسم بالكامل) [بعض الولايات]:اسم المنطقة (مثل المدينة) []:اسم المؤسسة (مثل الشركة) [شركة Internet Widgits Pty Ltd]:اسم وحدة المؤسسة (مثل القسم) []:الاسم الشائع (مثل اسمك أو اسم FQDN للخادم) []:السلسلة طويلة للغاية ويجب أن يقل طولها عن 64 بايت الاسم الشائع (مثل اسمك أو اسم FQDN للخادم) []:عنوان البريد الإلكتروني []:الخطأ، لم يتم تحديد أي كائنات في ملف التكوين، مشكلات تؤدي إلى إنشاء طلب الشهادة، مفتاح الجهاز في internal-wa-inc-name-LB-123456789.ap-southeast-1.elb.amazonaws.com

لا يوجد تقييد لعدد المعلمات المسموح به في قوالب الرسائل.

الحد الأقصى المسموح به هو 250 قالب رسالة لكل حساب واتساب للأعمال.

في حالة عدم عرض حدث Webhook لأي سبب (مثل، العميل غير متصل) أو في حالة قيام طلب Webhook بإرجاع الرمز البرمجي لحالة HTTP بخلاف 200، سنعيد محاولة عرض webhook. وسنستمر في إعادة محاولة العرض مع زيادة مدة التأخير إلى انتهاء مهلة زمنية محددة (بصفة أساسية لمدة 24 ساعة على الرغم من احتمالية اختلاف هذه المدة) أو حتى تنجح عملية العرض.

قد تتوفر حالات تحتاج فيها إلى المزيد من الوقت لمعالجة أي استعلام وارد من أحد العملاء وقد تتمكّن من تقديم استجابة بعد مرور 24 ساعة. ونوصي بإنشاء قوالب الرسائل من أجل ما يلي:

• إرسال النتيجة إلى المستخدم، أو
• مطالبة المستخدم بالرد من أجل تنشيط نافذة خدمة العملاء.

في الحالتين، يرجى التأكد من تقديم المزيد من السياق في قالب الرسالة قدر الإمكان. فعلى سبيل المثال:

• "مرحبًا {{1}}، بالنسبة للمشكلة التي أبلغت عنها مسبقًا، نأسف أن نخبرك بأن {{2}}. ونعتذر عن أي إزعاج تواجهه."
• نود أن نخبرك ببعض التحديثات فيما يتعلق بالتذكرة التي قدمتها. ويرجى الاستجابة مجددًا إذا كنت ترغب في متابعة تلقي الدعم."

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

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

نعم، تتمتع ميزة تدوير السجل في حاويات webapp وحاويات coreapp بسلوكيات مختلفة اختلافًا طفيفًا:

• Webapp: سيتم الاحتفاظ بآخر 30 ملف سجل. ولا يتم تدوير ملف السجل إلا إذا كان حجمه أكبر من 20 ميجابايت.
• Coreapp: سيتم الاحتفاظ بآخر 30 ملف سجل. ولا يتم تدوير ملف السجل إلا إذا كان حجمه أكبر من 15 ميجابايت. وتكون الملفات التي تم تدويرها مضغوطة.

يرجى الاتصال بالدعم وتقديم أي معلومات لديك. وسنحقق في الأمر ونوقف تشغيل أي أرقام زائفة.

تتمتع كل إصدارات عميل واجهة API واتساب للأعمال بصلاحية لمدة 6 أشهر من تاريخ الإصدار. وفي حالة ظهور هذا الخطأ، قم بالترقية إلى آخر إصدار تم إطلاقه في أقرب وقت ممكن.

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

يرجع ظهور هذا الخطأ إلى أنه لم تتم تهيئة Coreapp بعد. ويعني ذلك أنه قد لم يتم التسجيل بنجاح. لذا يرجى محاولة التسجيل قبل إجراء استدعاء إلى نقطة نهاية أخرى. وتكون الخطوة الأولى بعد تثبيت واجهة API واتساب للأعمال هي تسجيل الدخول. أما الخطوة الثانية، فتكون التسجيل. ويلزم تنفيذ هاتين الخطوتين قبل إجراء طلبات إلى نقاط نهاية أخرى.

لاحظ أنه: يتم إيقاف استخدام سياسة لغة fallback بداية من الإصدار v2.27.8 وأن سياسة لغة deterministic هي السياسة الافتراضية حاليًا.

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

إذا لم يكن إنشاء ترجمات اللغة هو أحد الخيارات المتاحة لديك حاليًا، يمكنك استخدام سياسة اللغة المحددة لتجنب ظهور هذه الأخطاء.

يمكن أن تكون حمولة بيانات الرسالة من مستخدم عبارة عن رسالة نصية أو ملف وسائط.

بالنسبة للرسالة النصية، من غير المعتقد أنه يوجد خطر محدد.

بالنسبة لملفات الوسائط:

• من المتوقع بشكل طبيعي أن الأنشطة التجارية تتمتع ببعض برامج الحماية (أي برامج مكافحة الفيروسات ومكافحة البرامج الضارة، وإلخ) لتحليل أي تهديدات محتملة.
• لا يمكن لواتساب تحديد محتوى الملف الذي يتم نقله أو التحقق منه نظرًا لأنه مُشفّر تمامًا (ينطبق ذلك أيضًا على محتوى الرسالة النصية فقط).
• يوجد خيار لمنع استخدام ملفات الوسائط التي يتم تنزيلها تلقائيًا في عميل واجهة API واتساب للأعمال. وفي حالة أن النشاط التجاري لا يرغب في تلقي أي ملف من المستخدمين، يمكنه تعيين الحقل auto_download إلى مصفوفة فارغة.

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

تحدث أخطاء عدم توفر البنية عندما لا يتمكن الهاتف من قراءة رسالة القالب.

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

إذا حدثت أي أخطاء أثناء العرض، فسيتم إرسال خطأ structure unavailable إلى عنوان URL الاستدعاء الذي يحتوي على المستلم ومعرف الرسالة. يمكن أن تحدث هذه الأخطاء بسبب خطأ في مساحة الاسم أو عدم تطابق المعلمة المترجمة أو خطأ في اسم العنصر، إلخ.

انتقل إلى مدير WhatsApp الموجود في مدير الأعمال من Facebook لعرض عدد المعلمات الصحيح. وتحقق مرة أخرى من أن مساحة الاسم صحيحة وأن اسم العنصر موجود.

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

الأمر الجيد أنه عادةً ما تكون أخطاء structure unavailable هي بسبب وجود أخطاء في استدعاء API messages ويمكن إصلاحها عن طريق تغيير حمولة بيانات الإرسال.

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

1. في حسابك على واتساب، انتقل إلى الإعدادات.
2. انقر على مدير واتساب.
3. حدد علامة التبويب أرقام الهواتف. ويمكنك هنا إدارة كل أرقام الهواتف الخاصة بهذا الحساب.

بالنسبة للصور، ستتم إضافة الشرح التوضيحي باعتباره وصفًا. ويظهر نص الشرح التوضيحي بالكامل في الصور على نظام التشغيل Android وهاتف iPhone.

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

في حالة فشل التسجيل باستخدام "رسالة sms" بسبب إجراء محاولات عديدة للغاية وظهور الرسالة "تم رفض الوصول"، من ثمّ يرجى محاولة التسجيل باستخدام "مكالمة صوتية"

المدة الحالية هي 7 أيام. وإذا لم يتم تحديث التخزين المؤقت لمدة تزيد عن 7 أيام، فسيسحب آخر حزمة لغة من الخادم بغض النظر عما إذا كان العنصر موجودًا بالفعل في الحزمة أم لا.

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

لمزيد من المعلومات، يمكنك الرجوع إلى إرسال قوالب الرسائل — اللغة.

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

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

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

يرجع ذلك إلى العديد من الأسباب. فقد تكون الحاوية Coreapp مُعطلة أو لم يتم إعداد قاعدة البيانات بشكل صحيح. وإذا لم تكن هذه هي الحالة، فيرجى إلقاء نظرة على سجلات Coreapp لديك (أو سجلات Coreapp الرئيسية إذا كنت تستخدم الاتصال المتعدد). وفي حالة ظهور أخطاء في الاتصال بقاعدة البيانات، من المحتمل أن قاعدة البيانات تنفد من الاتصالات. يمكنك الرجوع إلى مستند MySQL أو مستند PostgreSQL بشأن هذا الخطأ.

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

قد تتضمن أسباب رفض قالب الرسالة ما يلي:

• يمكن أن تحتوي على محتوى مسيء، مثل استخدام لغة مسيئة أو محتوى غير مهم أو احتيالي
• يمكن أن تحتوي على محتوى ترويجي
• يمكن أن تكون غير متطابقة مع نوع إشارة التحديد
• تم التنسيق بشكل غير صحيح

قد يعني الخطأ "الاتصال مرفوض" أن الحاوية Coreapp لا تعمل. ويمكنك استخدام docker ps لمعرفة ما إذا كانت الحاوية Coreapp تعمل أم لا. وإذا كانت لا تعمل، فسيمكنك إلقاء نظرة على سجلات Docker. وقد يتعذر على الحاوية Coreapp الاتصال بقاعدة البيانات. لذا تأكد من إعداد قاعدة البيانات بشكل صحيح.

يحدث ذلك في حالة تلف جسر Docker. وأفضل طريقة لتصحيح هذا الخطأ هي إيقاف خدمة Docker والبدء من جديد. كما يمكنك محاولة استخدام docker restart بالحاويات لديك.

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

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

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

WhatsApp strongly verifies whether number provided actually belongs phone. The fact that a user has a WhatsApp account is proof that they confirmed the number and no one else has used that number to register on WhatsApp subsequently. However, It is not a guarantee of the physical location of the sim.

On the other hand, if users phone is lost or stolen, they can deactivate their WhatsApp account. You may read to know more about how users can deactivate their account here.

يظهر هذا الخطأ عندما لا يتم إعداد قاعدة البيانات بشكل صحيح.

• تأكد من أنك تستخدم MySQL بالإصدار 5.7 أو الإصدارات الأحدث أو تستخدم PostgreSQL بالإصدار 9.5.x أو 9.6.x أو 10.x.
• يجب ألا تتضمن كلمة السر الخاصة بقاعدة البيانات الأحرف التالية: ?{}&~!()^.
• إذا كنت تستخدم خدمات الويب من Amazon (AWS)، فتأكد من أن المكدس المتوفر لديك يحمل اسمًا قصيرًا. ولمزيد من المعلومات، راجع وثائق التثبيت.

نعم، يلزم إجراء اتصال TCP. وإذا لم يتمكّن نشاطك التجاري من فتح منافذ إضافية، فمن ثمّ يمكنك استخدام بروتوكول SSL تم إنهاؤه.

لمزيد من المعلومات، يمكنك الرجوع إلى وثائق متطلبات الشبكة.

هذه مشكلة معروفة. كما تتطلب أحيانًا ترقية عميل واجهة API واتساب للأعمال التي تستخدم البرامج النصية CloudFormation تحديثًا إلى مكدس قاعدة بيانات RDS. ولن يتمتع مكدس RDS الجديد باسم المضيف نفسه باعتباره المكدس الأصلي ولا تتمكّن حاويات Docker من الاتصال بقاعدة البيانات. والحل هو إدخال بروتوكول SSH في مثيل EC2 الذي أنشأه CloudFormation وتحديث الملف whatsapp.conf باستخدام اسم المضيف الجديد، ثم إعادة تشغيل حاويات Docker بحيث يمكنها اختيار الإعدادات الجديدة.

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

Use the mcdockerreset script and tear down the webapps then use the mcdockersetup script to bring up a new webapp.

Reason: When the webapp first connects to the DB, it creates the database.yml file. it will never try to create it again. The coreapps will just not start up on a bad DB config; however, the webapp will, so you see the master and slave nodes in your DB because they were setup correctly once you got around all the DB and script issues but the webapps were started by the script in a bad state to begin with.

في حالة فشل Webhook في إرسال استدعاء، يتم وضع الاستدعاء في قائمة انتظار إعادة المحاولة. ولن يتم تلقي أية عمليات استدعاء مُرسلة بعد فشل الاستدعاء الأولي. ويتم ذلك فقط بعد أن ينجح الاستدعاء الأولي الذي فشل في أنه سيقوم البقية بالمتابعة.

يرسل عميل واجهة API واتساب للأعمال عمليات استدعاء Webhook إليك عبر الحاوية Coreapp. ولذلك، يلزم تكوين نقطة النهاية Webhook لقبول الطلبات الواردة من الحاوية Coreapp.

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

يلزم توفير MySQL بالإصدار 5.7.x، وتوفير PostgreSQL بالإصدار 9.5.x أو 9.6.x أو 10.x. وسيؤدي استخدام الإصدار السابق إلى ظهور الخطأ Unable to initialize config store.

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

تخزن جداول قاعدة البيانات المعلومات المتعلقة بإعدادات التطبيقات وسلسلة رسائل الدردشة والرسائل والوسائط وإلخ والمطلوبة جميعها من التطبيق ليتم تشغيله.

لم يتلق نشاطك التجاري إشعارًا عندما يقوم أحد العملاء بتغيير رقم هاتفه على واتساب. وعندما تستخدم العقدة contacts، سيكون هذا الرقم بالحالة invalid.

لا، يمكنك تشغيل حساب واحد لكل مثيل. وإذا كنت بحاجة إلى حساب اختباري ثان، فتأكد من استخدام رقم آخر لهذا المثيل الثاني.

تتوفر ميزة التحقق من الحالة مجانًا ويمكن الاستعلام عنها كلما لزم الأمر.

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

عند استخدام العقدة messages، تحتاج إلى تعيين العنوان Content-Type إلى application/json في عميل واجهة API واتساب للأعمال من أجل تحليل نص الرسالة بشكل مناسب. كما يتوفر عنوان Authorization الذي يلزم تعيينه ويجب أن يحتوي على رمز وصول غير منتهي الصلاحية. وللحصول على معلومات حول كيفية الحصول على الرمز المميز ووقت انتهاء صلاحيته، راجع وثائق تسجيل الدخول والمصادقة.

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

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

يتم تنزيل ملفات الوسائط التي يرسلها المستخدمون إليك إلى وحدات تخزين الوسائط. ويتعين على النشاط التجاري اتخاذ قرار بشأن تحديد ملفات الوسائط المطلوب حذفها، ولكن بشكل عام يكون حذف أي ملف وسائط إجراءً آمنًا. ويمكنك استخدام docker inspect your-container-id للتحقق من مكان وجود مجلد وحدة تخزين الوسائط.

يمكنك إعداد MySQL محليًا باستخدام Docker من خلال اتباع دليل MySQL في Docker.

يمكنك إعداد PostgreSQL محليًا باستخدام Docker من خلال اتباع دليل PostgreSQL في Docker.

في معظم الحالات، يجب عليك تشغيل قاعدة البيانات على خادم فعلي منفصل من الحاويتين core وweb. ويجب ألا يتأخر خادم قاعدة البيانات في وقت الاستجابة عن بضعة مللي ثوانٍ من جهاز (أجهزة) الكمبيوتر.

يكون أمر تحديد الوقت الذي يتعين خلاله حذف الوسائط متروكًا لك.

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

نعم، يمكن استخدام قاعدة البيانات بطرق أخرى دون المساس بالجداول المتعلقة بواتساب.

تحقق أولاً من عمليات الاستدعاء بحثًا عن أخطاء فادحة لتشخيص المشكلة.

في حالة ظهور "تعارض: تم الكشف عن مثيلات متعددة تشارك الرقم نفسه"، تحتاج إلى التحقق من الحاويات المتوفرة لديك. ويرجع السبب الأرجح في ذلك إلى أن لديك العديد من حاويات Docker التي تحاول الاتصال بخوادم واتساب باستخدام حساب واتساب نفسه. تأكد من أن لديك حاوية واحدة فقط تعمل وقيد التشغيل. وإذا كانت لديك حاويات قديمة، فأوقف تشغيلها وسيختفي هذا الخطأ.

إذا كنت تريد اختبار حل الإتاحة العالية الأكثر تعقيدًا، فراجع وثائق الإتاحة العالية.

يمكن إنشاء قائمة سماح من خلال الأسماء المضيفة أو عناوين IP.

لمزيد من المعلومات، يمكنك الرجوع إلى قسم الأسماء المضيفة في وثائق متطلبات الشبكة.

نعم! يسمح لك واتساب بتنسيق النص المحدد داخل الرسائل باستخدام الخط العريض أو الخط المائل أو يتوسطه خط أو الخط الأحادي.

نعم، تدعم قوالب الرسائل كل تنسيقات وأحرف المراسلة على WhatsApp، بما في ذلك الرموز التعبيرية واستخدام الخط العريض والخط المائل، وإلخ. وبالنسبة للرموز التعبيرية، ستحتاج إلى استخدام حرف الرمز التعبيري (النسخ/اللصق) بدلًا من استخدام unicode المماثل.

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

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

يمكنك الاطلاع على المزيد حول الأرقام المجانية هنا.

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

يراعي WhatsApp المراسلات مع مستخدمي واجهة API للأعمال الذين يديرون نقطة نهاية واجهة API على الخوادم التي يتحكمون بها لتكون مشفّرة تمامًا نظرًا لعدم إمكانية وصول الجهة الخارجية إلى المحتوى بين نقاط النهاية.

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

بالإضافة إلى ذلك، إذا كنت تستخدم بروتوكول HTTPS عند إجراء عمليات استدعاء إلى عميل واجهة API الخاصة بتطبيق WhatsApp للأعمال، فتكون هذه البيانات مشفّرة باستخدام بروتوكول SSL (من عميل الخلفية إلى عميل واجهة API الخاصة بتطبيق WhatsApp للأعمال).

للحصول على المزيد من التفاصيل، يمكنك الرجوع إلى المستند التقني حول نظرة عامة على تشفير WhatsApp لدينا.

ينجم ذلك عن حدوث خطأ في أحد الإصدارات القديمة لعميل نظام iOS. ونتوقع انخفاض معدل الأخطاء مع مرور الوقت بسبب ترقيات المجموعة العامة.

لا، لا يتم ضمان أن يكون الترتيب الذي تم به تلقي الرسائل هو الترتيب نفسه المُستخدم عند إرسال الرسائل. وإذا كانت عملية الترتيب تمثل أمرًا مهمًا بالنسبة لحالة استخدامك، فسيكون النهج المُقترح هو الاستجابة للاستدعاء المعروض الخاص بالرسالة الأولى قبل بدء إرسال الرسالة الثانية.

يوجد برنامج نصي يمكن تشغيله خارجيًا لمسح السجلات القديمة من الحاوية:

docker exec CONTAINER_NAME /opt/whatsapp/bin/cleanup.sh

يستخدم البرنامج النصي الحاويتين webapp وcoreapp. وعند تشغيل البرنامج النصي، ستتم إزالة ملفات السجل القديمة بحيث لا يبقى سوى 30 ملف سجل في الحاوية فقط.

ملاحظة: يرجى عدم إرسال الرسالة نفسها بشكل متكرر إلى المستلم نفسه الذي يستخدم API واتساب للأعمال.

يمكن أن تكون هناك أسباب متعددة تكمن وراء عدم وصول معدلات الإرسال إلى 100%. تتضمن بعض الحالات الشائعة وصول المستخدمين بشكل متقطع إلى الشبكة أو عدم نشاطهم لفترة من الوقت أو إنشاء تجربة مستخدم عالية الجودة.

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

قد تظل الرسائل غير مُرسلة نظرًا لأن هاتف المستخدم يكون خارج الخدمة أو البطارية نفدت أو تعرض الهاتف للفقدان وحصل المستخدم على هاتف جديد وقام بتعطيل بطاقة SIM الخاصة به. ومن الممكن ظهور أخطاء في إمكانية عميل النشاط التجاري للاتصال بالشبكة. كما أنه من الممكن عدم إرسال عمليات الاستدعاء (Webhooks). يمكنك التحقق من هذه الحالات من خلال استخدام العقدة health. ويمكنك تشغيل عمليات استدعاء إيصال الخادم لمعرفة أنه تم إرسال الرسالة إلى سحابة خادم واتساب.

كلما وحينما يعيد المستخدم الاتصال بالشبكة، سيتم إرسال كل الرسائل التي أرسلتها إليه. وسيمثل تلقي أكثر من رسالة واحدة تتضمن المحتوى نفسه تجربة سيئة بالنسبة له. ومن المرجح أنه سيحظرك أو يقدم شكوى. ولكن من المرجح أنه سيتم حظرك.

إذا أرسلت رسالة وتلقيت معرف رسالة من واجهة API، فقد اتخذت الإجراءات اللازمة لإرسال هذه الرسالة. ولا تعيد إرسال المحتوى نفسه إلى المستلم نفسه.

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

يتطلب عميل API داخل المواقع في واتساب للأعمال توفير قاعدة بيانات لمفاتيح المتاجر لفك تشفير الرسائل المرسلة بين نشاط تجاري والعملاء. يتم تشفير كل الرسائل على واتساب باستخدام مفاتيح المرسِل والمستلِم. يتم تخزين مفاتيح العميل على جهازه المحمول ويتم تخزين مفاتيح النشاط التجاري في قاعدة بيانات النشاط التجاري. تعرَّف على المزيد حول أمان واتساب.

تمثل API سحابة في واتساب للأعمال حلاً بديلاً حيث تستضيف Meta خلالها قاعدة بيانات النشاط التجاري. تتيح لك API السحابة تنفيذ واجهات API واتساب للأعمال بدون تكلفة استضافة خوادمك الخاصة. معرفة المزيد.

لا، يفتح عميل واجهة API واتساب للأعمال اتصال TCP صادرًا إلى منفذ 5222 أو 443 على خوادم واتساب. وتتم زيارة TCP عبر هذا الاتصال طويل الأجل. وتنظم جُدر الحماية ذلك بشكل طبيعي بحيث تسمح "بالزيارة الصادرة والزيارة التي تم إنشاؤها". بالطبع، ستقوم الحِزم بالدفق للأمام والخلف بمجرد إنشاء الاتصال، ولكن يكون الاتصال واردًا من عميل واجهة API واتساب للأعمال بحيث لا توجد حاجة لأية قاعدة تسمح بإجراء الاتصالات الواردة.

يتم دعم MySQL وPostgreSQL. وفي حالة تشغيل Docker بنفسك، يجب عليك توفير قاعدة البيانات MySQL/PostgreSQL للحاويات بغرض الاتصال بها. ويؤدي استخدام قالب خدمات الويب من Amazon (AWS) إلى إعداد قاعدة بيانات MySQL افتراضيًا.

تعتمد المتطلبات على معدل تحميلك وحالتك. وسيعمل الحل على أي جهاز متصل بالإنترنت يقوم بتشغيل docker. فعلى سبيل المثال، يمكن إجراء الاختبار البسيط على الكمبيوتر المحمول.

عند إعداد خادم الإنتاج لمثيل واحد، نوصي باستخدام بطاقة SSD بسعة تخزين 250 جيجابايت على الأقل وذاكرة وصول عشوائي تصل إلى 16 جيجابايت ووحدة معالجة مركزية رباعية النواة. ولا يوصى باستخدام HDD لأن سرعات الإدخال/الإخراج ستصبح مواضع تعثر في ظل التحميل.

بالنسبة لإعداد خادم الإنتاج للاتصال المتعدد، نوصي باستخدام بطاقة SSD بسعة تخزين 50 جيجابايت على الأقل وذاكرة وصول عشوائي تصل إلى 4 جيجابايت ووحدة معالجة مركزية ثنائية النواة في كل حاويات Coreapp/Master/Webapp.

في معظم الحالات، يجب عليك تشغيل قاعدة البيانات على خادم فعلي منفصل من الحاويتين core وweb. ويجب ألا يتأخر خادم قاعدة البيانات في وقت الاستجابة عن بضعة مللي ثوانٍ من جهاز (أجهزة) الكمبيوتر.

تدعم عملية الإعداد هذه إرسال 20 رسالة تقريبًا لكل ثانية.

بالتأكيد! يمكنك التواصل مع ممثل WhatsApp لديك وإجراء هذا الطلب.

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

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

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

للأسف، ستحتاج إلى اختيار رقم هاتف آخر يمكنه تلقي رسالة SMS أو مكالمة صوتية حتى نتمكّن من إرسال الرمز البرمجي للتسجيل. وفي السابق، كنا نسمح باستخدام الرموز البرمجية للتسجيل اليدوي، ولكن لم يعد ذلك مدعومًا. علمًا بأن أرقام الهواتف التي استخدمت الرموز البرمجية للتسجيل اليدوي من قبل ستظل مدعومة حسب الحاجة. وبالنسبة لأرقام الهواتف الجديدة، لن نعرض سوى الرموز البرمجية للتسجيل عبر رسالة SMS أو مكالمة صوتية.

إذا كنت تريد استخدام الرقم 1800 أو الرقم المجاني، فيرجى الاطلاع على هذا الدليل.

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

إذا كان المستخدم قد حظر نشاطك التجاري، فستظل واجهة API جهات الاتصال تقوم بإرجاع رقم الهاتف هذا باعتباره مستخدم واتساب صالح. ومع ذلك، عندما ترسل الرسالة، لن يتم إرسالها أبدًا. وإذا كانت رسالة مدفوعة، فلن يتم تحصيل أي رسوم منك.

نعم، يمكننا إعداد رقم هاتف جديد أو تغيير الاسم المُتحقق منه عندما تكون مستعدًا للبث المباشر.

يكون الحد الأقصى لحجم تحميل الملف 64 ميجابايت مما يعني أن هذا التقييد أيضًا ينطبق على أية صورة أو مستند أو فيديو ترسله مع الرسالة.

لا، يتطلب حل واجهة API واتساب للأعمال رقمًا جديدًا.

للعثور على نقطة تحميل وحدة تخزين الوسائط الخاصة بك، يمكنك تشغيل أمر 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 في المضيف.

لا تتوفر آلية تنظيف تنطبق على ملفات الوسائط الصادرة أو الواردة. ويجوز لك حذف ملفات الوسائط يدويًا من خلال تحديد موقعها على نظام الملف لديك.

يمكنك إعادة تشغيل حاويات Docker من خلال تشغيل الرمز البرمجي التالي:

حاوية Docker في Coreapp

docker restart wacore<Current_WABA_Version>

حاوية Docker في Webapp

docker restart webapp<Current_WABA_Version>

يمكنك التحقق من الإصدار الذي تستخدمه

docker ps

نعم! يحاول عميل واجهة API واتساب للأعمال افتراضيًا الاتصال باستخدام chatd عبر المنفذ 5222. وللحصول على أفضل تجربة استخدام، يمكنك فتح المنفذ 5222 لكل الزيارات الصادرة. ولا يثير ذلك مشكلة في الأمان نظرًا لأن الزيارات تكون صادرة فقط من مركز البيانات المتوفر لديك.

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

• The Page must be categorized as "App Page"
• You should have access to the page via a role
• The App Page should not already be linked to an existing app
• The Page must have the same name (or a subset of the name) of the app

• An admin of the campaigns
• A full admin of the page

• يتم إرسال طلبات الألعاب من التطبيق إلى المستخدم عبر نقطة نهاية API /apprequests. وفي هذه الحالة، يتم عرض الطلب في موجز نشاطات الألعاب، لكن لا يتم عرض إشعار بموقع الويب. https://developers.facebook.com/docs/graph-api/reference/app-request#Creating
• يتم إرسال طلبات الألعاب من مستخدم إلى مستخدم آخر عبر مربع حوار الطلب. وفي هذه الحالة، يتم عرض الطلب في موجز نشاطات الألعاب وعرض إشعار بموقع الويب. https://developers.facebook.com/docs/games/services/gamerequests
• علاوة على ذلك، هناك أيضًا إشعارات يتم إرسالها من التطبيق إلى المستخدم عبر نقطة نهاية واجهة API /notifications. وينتج عنها عرض إشعار، لكنها لا تؤدي إلى عرض الطلب في موجز نشاطات الألعاب. https://developers.facebook.com/docs/games/services/appnotifications