Skip to main content
ستتضمن واجهة REST API استجابة بقائمة الأخطاء إن وُجدت.
للأخطاء رمز حالة مُعاد 400 أو 401 أو 402 أو 403 أو 404 أو 429 أو 500 أو 502 أو 503 أو 504. النجاح له رمز حالة مُعاد 200. راجع هنا للتفاصيل.
قد يُعيد كل استدعاء API أخطاءً مختلفة بحسب الطلب المحدد وأي مشكلات تُواجه في الشبكة الاجتماعية. ستحتوي استجابة الخطأ على تفاصيل حول ما حدث من خلل خلال استدعاء API. على سبيل المثال، منشور يعتبره Twitter وFacebook تكرارًا سيُعيد الاستجابة التالية.
يُرجى ملاحظة:
  • يحتوي حقل errors على مصفوفة الأخطاء، خطأ واحد لكل شبكة اجتماعية واجهت خطأً.
  • يشير action إلى نوع الخطأ المُعاد.
  • سيكون حقل status على المستوى الأعلى “error” إذا فشل استدعاء API. على سبيل المثال، لاستدعاء /post إذا نجحت جميع عمليات النشر على الشبكات الاجتماعية، فسيكون حقل status “success”، وإلا فسيكون حقل status “error”.
  • يحتوي حقل code على رمز خطأ Ayrshare المرجعي.
  • حقل message هو التفاصيل المحددة للخطأ.

التعامل مع الأخطاء

يجب أن تتعامل مع أي استجابات خطأ وتتخذ الإجراء المناسب. حدث خطأ إذا:
  • كان رمز إرجاع الاستجابة ليس 200
  • كانت حالة استجابة JSON error
على سبيل المثال، إذا أزال المستخدم رابط Facebook — غيّر كلمة المرور أو أزال وصول Ayrshare — ستحدث الاستجابة التالية عند النشر مع رمز استجابة 400 Bad Request.
قد يكون الإجراء إشعار المستخدم عبر لوحة التحكم أو الرسائل النصية أو البريد الإلكتروني. مثال آخر إذا كانت صورة Instagram المنشورة بأبعاد أو نسبة خاطئة مع رمز استجابة 400 Bad Request:
قد يكون الإجراء إعادة إرسال الصور بالنسبة الصحيحة.

حصة المنشورات الشهرية

الرمز 106 — تجاوز حصة المنشورات الشهرية (HTTP 429) استهلك الملف الشخصي حصة منشوراته الشهرية. تُرجع /post هذا الخطأ لطلبات النشر الجديدة، بما في ذلك الطلبات التي تجدول منشورًا. وتُرجعه أيضًا طلبات النشر الأخرى، مثل جلب منشور أو حذفه أو إعادة محاولته، أو تحليلات المنشور، حتى إعادة تعيين الحصة. وتفشل أيضًا بهذا الرمز المنشورات المجدولة التي يحين موعدها بينما الحصة مستنفدة. هذا ليس حد معدل. الانتظار بضع دقائق لن يفيد. عادةً، تكون الاستجابة بأكملها هي الخطأ:
بالنسبة لمنشور مجدول، يظهر الخطأ نفسه في مصفوفة errors الخاصة بالمنشور. وقد يحدث هذا أيضًا لمنشور جديد إذا نفدت الحصة أثناء إرساله. تحقق من وجود code: 106 في كلا المكانين. الإجراء: تحقق من monthlyPostCount وmonthlyPostQuota باستخدام تفاصيل ملف المستخدم. تُعاد تعيين الحصة في اليوم الأول من كل شهر (UTC). يؤدي تغيير خطتك إلى إعادة تعيين عدّاد Primary Profile الخاص بك فورًا. تُحتسب أيضًا محاولات النشر الفاشلة، لذا أوقف أي إعادة محاولة تلقائية للمنشورات التي تستمر في الفشل. راجع ما هو الحد المسموح به من المنشورات ومكالمات API؟ للاطلاع على التفاصيل.

أخطاء المحتوى المكرر أو المشابه

قبل أن يصل المنشور إلى الشبكة الاجتماعية، يقارنه Ayrshare بمنشوراتك الأخرى ويرفض المحتوى المطابق أو شبه المطابق بالرمز 137. هذا فحص خاص بـ Ayrshare، لذا قد يُرفض المنشور حتى لو كانت الشبكة نفسها ستسمح به. ولا يشمل هذا الفحص جميع المنصات — راجع الاستثناءات أدناه.
النافذة الزمنية. يُفحص كل منشور ضمن نافذة مدتها 48 ساعة تتمحور حول scheduleDate الخاص به — 24 ساعة قبله و24 ساعة بعده. ولأن النافذة تمتد إلى الأمام كما تمتد إلى الخلف، يمكن رفض منشور بسبب منشور مجدول بعده، وليس قبله فقط. نطاق المقارنة.
  • تتم المطابقة لكل ملف مستخدم ولكل منصة على حدة. النص نفسه المرسل إلى X/Twitter وإلى LinkedIn لا يُعد تكرارًا، وملفان مختلفان للمستخدمين لا يتعارضان.
  • يُستثنى X/Twitter، ولكن فقط في حالة التطابق التام: فالمنشور المطابق تمامًا يُفحص أيضًا عبر جميع ملفات المستخدمين ضمن الحساب نفسه، لأن X لا يسمح بنشر المحتوى نفسه عبر عدة حسابات. أما التطابقات شبه المطابقة (التشابه) فتبقى مقتصرة على ملف المستخدم الذي نُشر منه المنشور فقط.
  • لا يُطبَّق فحص التكرار على Pinterest وReddit وTelegram.
لنشر محتوى حول الموضوع نفسه بوتيرة أعلى، أنشئ صياغات مختلفة باستخدام Generate API.

رموز الأخطاء الخاصة بـ Instagram

توفر رموز الأخطاء التالية تفاصيل محددة حول إخفاقات النشر على Instagram، وتحل محل الخطأ العام 138 حيثما أمكن. الرمز 435 — حد معدل Instagram (HTTP 429) تخضع حسابات Instagram الاحترافية (Business / Creator) لحد متحرك مدته 24 ساعة يبلغ 50 منشورًا في واجهة Meta لنشر المحتوى (لا يمكن للحسابات الشخصية النشر عبر API إطلاقًا وبالتالي لا تصل إلى هذا الحد أبدًا). عند تجاوز الحد، تُعيد Meta خطأ حدّ معدل. يُظهر Ayrshare أيضًا code: 435 عندما تُعيد نقطة نهاية Meta للنشر HTTP 429 مباشرةً أو عندما يشير رمز الخطأ الفرعي الأساسي (1390008) إلى تقييد نشر / تعليق.
الإجراء: انتظر حتى تُعاد نافذة حد المعدل قبل إعادة المحاولة. عندما توفر Meta ترويسة Retry-After، تُمرَّر القيمة (بالثواني) في حقل details — انتظر ذلك على الأقل قبل إعادة الإرسال. الرمز 436 — انتهاء مهلة معالجة وسائط Instagram (HTTP 400) استغرقت Instagram وقتًا طويلًا لمعالجة الوسائط المُحمَّلة. يمكن أن يحدث هذا مع ملفات الفيديو الكبيرة أو خلال فترات الحمل العالي على خوادم Meta.
الإجراء: أعد محاولة المنشور باستخدام نقطة نهاية retry post. إذا استمرت المشكلة، حاول تقليل حجم ملف الوسائط. الرمز 447 — Instagram Trial Reels: graduationStrategy مفقود (HTTP 400) يُعاد عندما يُقدَّم instagramOptions.trialParams على طلب /post لكن graduationStrategy مفقود أو null أو سلسلة فارغة. تتطلب Trial reels استراتيجية تخرّج صريحة — راجع Trial Reels.
الإجراء: عيّن instagramOptions.trialParams.graduationStrategy إلى "MANUAL" أو "SS_PERFORMANCE" وأعد المحاولة، أو أزل trialParams إن لم تكن تنوي نشر trial reel. الرمز 448 — Instagram Trial Reels: graduationStrategy غير صالح (HTTP 400) يُعاد عندما يكون graduationStrategy موجودًا لكنه ليس بالضبط "MANUAL" أو "SS_PERFORMANCE". الفحص حساس لحالة الأحرف — القيم مثل "manual" أو "ss_performance" تُرفض. يعكس حقل details المدخل المرفوض (مقتطعًا إلى 64 حرفًا) للمساعدة في التصحيح.
الإجراء: أرسل graduationStrategy كـ "MANUAL" أو "SS_PERFORMANCE" بالضبط (بأحرف كبيرة، نوع نصي). الرمز 449 — Instagram Trial Reels: وسائط غير متوافقة (HTTP 400) يُعاد عندما لا يكون شكل الوسائط أو المنشور مؤهلًا لـ trial reel. يجب أن تكون trial reels فيديو .mp4 أو .mov واحد — carousels (أكثر من URL واحد) وStories (instagramOptions.stories: true) والامتدادات غير الفيديو كلها مرفوضة. يوضح حقل details أي حالة فرعية أُطلقت.
الإجراء: أرسل عنوان URL واحد لفيديو .mp4 أو .mov بدون علامة stories: true. احذف إدخالات mediaUrls الإضافية، أو أزل trialParams إذا كنت تنوي منشور carousel/story عاديًا. الرمز 258 — خطأ حالة حساب Instagram (HTTP 400) فشل عام في حالة حساب Instagram برسالة أساسية “Error with Instagram.” يظهر هذا عندما ترفض Meta الطلب بسبب حالة حساب Instagram المتصل وليس بسبب محتوى المنشور.
عندما يكون error_subcode الأساسي لـ Meta هو 2207085 (“Generic Internal Error”، خطأ داخلي عام)، فهذا عطل مؤقت من جانب Meta. تعيد Ayrshare محاولة النشر تلقائيًا لمدة تصل إلى نحو 50 ثانية قبل إرجاع الخطأ، وتُعيّن الاستجابة retryAvailable: true. ولا تُعيّن relink: true — لأن إعادة الربط لا تحل هذه الحالة. وعندما توفّر Meta قيمة fbtrace_id، تُرجَع في details:
الإجراء: للحالة الفرعية 2207085، أعد محاولة النشر بعد بضع دقائق — فهذه حالة من جانب Meta تُحل عادةً من تلقاء نفسها، وإعادة الربط لا تصلحها. وفقط إذا استمر الخطأ أكثر من 24-48 ساعة، اطلب من المستخدم إلغاء ربط حساب Instagram وإعادة ربطه في Social Accounts، مع منح جميع الأذونات المطلوبة، أو تواصل مع دعم Meta مع fbtrace_id الموجود في details. لأخطاء حالة الحساب الأخرى، تحقق من أن حساب Instagram في وضع جيد لدى Meta وأعد المحاولة.

إعادة المحاولة متاحة

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

أخطاء صوت Instagram Reels

تغطي هذه الرموز إرفاق الموسيقى بـ Instagram Reel باستخدام instagramOptions.audioConfiguration، ونقطتَي نهاية بحث الصوت واستعلام الصوت.
لا يمكن حل الرمز 514 بمنح إذن أو ترقية خطة. فـ Audio API الخاص بـ Meta “متاح فقط على Instagram API مع Facebook Login. وهو غير مدعوم على Instagram API مع Instagram Login.” الحساب المرتبط بواسطة Instagram Login يعيد 514 في كل استدعاء صوت حتى تتم إعادة ربطه من خلال Facebook Login مع صفحة Facebook متصلة.راجع دليل أهلية إرفاق الموسيقى للإعداد الكامل، بما في ذلك المكان الذي يوجد فيه الآن ربط صفحة Facebook ضمن إعدادات Facebook.
يصل الرمز 518 في postIds[].warnings[] وليس في errors[]. يسمح Instagram بمقطع واحد لكل Reel، لذا عند إرسال كلٍّ من audioConfiguration وaudioName، تفوز audioConfiguration ويُسقط audioName. لا تزال الاستجابة status: "success" مع HTTP 200 — تعامل مع 518 على أنه إعلامي ولا تفشل بسببه. التحذير متداخل في إدخال postIds الخاص بتلك المنصة وليس في المستوى الأعلى، ويحمل feature: "audioName".
يُبلَّغ عن التحقق من مستوى الصوت بالرمز العام 101 وليس برمز مخصص. يجب أن يكون audioVolume وvideoVolume عددين صحيحين من 0 إلى 100. القيمة العشرية، أو السلسلة الرقمية مثل "80"، أو الرقم خارج النطاق، أو null الصريحة تعيد code: 101 مع تسمية الحد في details، قبل استدعاء Instagram. أغفل الحقل بدلًا من إرسال null.

أخطاء الردود الخاصة للأتمتة (رسائل خاصة عبر التعليقات)

تظهر هذه الرموز في الأتمتة المُشغَّلة بالتعليقات (comment_keyword) عندما يتعذّر إرسال الرد الخاص الذي يحمل الرسالة الخاصة. تظهر في صف النشاط بالحالة status: "failed" مع ذكر السبب في actionResults[].errorDetails. لا يُعاد المحاولة تلقائيًا لأي منها — فليس لدى Instagram Send API مفتاح idempotency، مما يجعل إعادة المحاولة التلقائية تخاطر بتسليم الرسالة الخاصة مرتين. تختلف طريقة المعالجة بحسب الرمز (انظر الإجراء أدناه): معظمها دائم لذلك التعليق تحديدًا، أما 492 فيتطلب إعادة ربط الحساب، و493 يزول من تلقاء نفسه عند إعادة تعيين الحد بالساعة.
يغطي الرمز 491 عدة أسباب لا يميّز بينها Instagram، والرمز 490 هو الاستثناء الضيّق. يُعيد Instagram خطأً واحدًا مشتركًا لتعليق مضى عليه أكثر من 7 أيام، ولتعليق تلقّى ردًا بالفعل (لا يُسمح إلا برد خاص واحد لكل تعليق إطلاقًا)، ولتعليق محذوف، ولمعلّق يحجب طلبات الرسائل. جميع هذه الحالات تُبلَّغ برمز 491.يُبلَّغ 490 فقط في الحالة الأضيق التي يُصنّف فيها Instagram معرّف التعليق بأنه غير صالح صراحةً بدلًا من إعادة الرمز المشترك — لذلك يمكن أن يظهر تعليق محذوف بوصفه إما 490 أو 491 حسب ما يعيده Instagram.بما أن واجهة برمجة التطبيقات لا تفصل بين هذه الحالات، اقرأ دائمًا errorDetails: فهو يحمل صياغة Instagram نفسها، وهي عادةً محددة بشأن السبب.
الرمز 489 محجوز ولا يُعاد حاليًا. إنه محجوز لحالة “هذا التعليق تلقّى ردًا بالفعل”، وهي حالة لا يكشفها Instagram حاليًا كإشارة مميزة — وهذه الحالة تُبلَّغ اليوم بالرمز 491. مذكور هنا فقط لكيلا يُعاد استخدام الرقم.
اتصال منتهي الصلاحية أو غير صالح فعليًا ليس ضمن هذا النطاق. إذا انتهت صلاحية بيانات اعتماد Instagram المخزنة، يكون صف النشاط بالحالة status: "auth_error" بدلًا من failed، وإعادة ربط الحساب هي الإصلاح الصحيح. باستثناء 492 — وهو إذن مفقود يُمنح بإعادة ربط الحساب — فإن الرموز أعلاه هي حالات على مستوى التعليق ولا تعني أبدًا “إعادة الربط”.
تظهر هذه الرموز في شكلين مختلفين حسب مكان قراءتك لها، ويُسمَّى الحقل الذي يحمل سبب Instagram بشكل مختلف في كل منهما. 1. في صف نشاط الأتمتة — ما تعيده GET /automations/:id/activity. يظهر سبب Instagram في actionResults[].errorDetails:
2. كمظروف خطأ مباشر من API — الشكل القياسي للخطأ، حيث يظهر السبب نفسه في details:
بالنسبة إلى أتمتة مُشغَّلة بتعليق فستقرأ الشكل 1 في معظم الأحيان. يحمل errorDetails هناك نفس النص الذي يضعه المظروف في details. الإجراء:
  • 490، 491، 495 — حالات على مستوى التعليق. لا يمكن استرجاعها لذلك التعليق تحديدًا، ولن تُفيد إعادة المحاولة؛ تعمل الأتمتة طبيعيًا مع التعليق الجديد التالي. اقرأ errorDetails للاطلاع على السبب المذكور من Instagram.
  • 492 — أعد ربط حساب Instagram، مع منح جميع الأذونات المطلوبة. هذا إصلاح على مستوى الحساب وسيؤثر على كل تعليق بخلاف ذلك.
  • 493 — لا يلزم أي إجراء سوى الانتظار؛ يُعاد تعيين الحد بالساعة تلقائيًا. لا يُعاد المحاولة تلقائيًا، لذا لا تُرسل الرسالة الخاصة لذلك التعليق.
  • 494 — سوء تهيئة داخلي، وليس حالة على جانب العميل. اتصل بالدعم إذا تكرّر.
لا تضمن حالة sent التسليم. بمعزل عن حالات الفشل أعلاه، يمكن للردّ الخاص الذي يقبله Instagram (status: "sent") أن يُسقَط بصمت عندما يمنع إعداد Message requests الخاص بالمستلم على Instagram الغرباء — وهذا لا يُنتج أي رمز خطأ. راجع رسالة أتمتة أُرسلت لكنها لم تُسلَّم.

أخطاء خيارات Thread والوسائط

تُعاد هذه الرموز عندما يتعذر تطبيق خيار على المنشور — وغالبًا ما يحدث ذلك على X Thread أو Threads thread، حيث تنطبق الخيارات التي ترسلها على الـ thread بأكمله.
  • 182 — الفيديو لا يستوفي متطلب المدة. الفيديو أقصر من الحد الأدنى للشبكة أو أطول من حدها الأقصى. تذكر الاستجابة المدة الفعلية للفيديو إلى جانب الحد الأدنى والحد الأقصى المطبَّقين، فقارن الثلاثة لتأكيد أي حد تجاوزته. على X، النطاق القياسي من 0.5 إلى 140 ثانية (دقيقتان و20 ثانية)؛ لنشر فيديو أطول عيّن longVideo: true، وهو ما يرفع الحد الأقصى إلى 4 ساعات للحساب المعتمد من X للفيديو الطويل. للشبكات الأخرى حدودها الخاصة — راجع إرشادات الوسائط للشبكة التي تنشر عليها.
  • 101 — معاملات مفقودة أو غير صحيحة. على Threads يُعاد هذا الرمز عند إرسال allowCountries من حساب لم تجعله Meta مؤهلًا لقيود الموقع الجغرافي. لا يُنشر أي جزء من المنشور أو الـ thread. تحقق من isEligibleForGeoRestrictions في /user قبل إرسال الخيار.
  • 111 — رفضت X المنشور. هذا هو الرمز العام لفشل من X لا يملك رمزًا أكثر تحديدًا، لذا اقرأ details في الاستجابة — فهو يحمل رسالة X نفسها وهو ما يخبرك بالسبب. من الأسباب الشائعة خيار لا يحق للحساب استخدامه، مثل subscribersOnly بدون X Subscriptions، أو longPost على منشور واحد بدون X Premium؛ في هذه الحالة أزل الخيار أو تحقق من صلاحيات الحساب. تظهر أيضًا حالات فشل الاتصال وأخطاء أخرى من جانب X كـ 111، وتلك تستحق إعادة المحاولة بدلًا من تغيير طلبك.لاحظ أن longPost ليس سببًا للرمز 111 على thread — فهناك يُتجاهل مع تحذير ويُنشر الـ thread. راجع المنشور الطويل.
  • 275 — المنشور أطول من أن يُنشر كـ thread. أنتج تقسيم النص أكثر من الحد الأقصى البالغ 30 منشورًا. اختصر النص أو قسّمه على threads منفصلة. إضافة فواصل thread الخاصة بك باستخدام \n\n لن تفيد هنا — فكل فاصل ينشئ منشورًا آخر، وقد يدفع العدد أبعد فوق الحد.
الخيار الذي لا يمكن لحسابك استخدامه يُفشل المنشور بأكمله بدلًا من أن يُتجاهل. وعلى thread يعني هذا أنه لا يُنشر أي جزء من الـ thread — وتُحذف نيابةً عنك الأجزاء التي كانت قد خرجت بالفعل. الحذف يجري على أفضل جهد ممكن: إذا رفضت الشبكة عملية حذف، فقد يبقى ذلك الجزء منشورًا، لذا تحقق من الـ thread وأزل أي شيء متبقٍ. في السابق كانت بعض هذه الخيارات تُسقط بصمت على الـ threads وكان الـ thread يُنشر بدونها.
تخص الرموز من 501 إلى 513 الربط الاجتماعي: إنشاء رابط عبر إنشاء Link Session، وفتحه. وهي تحمل "action": "link session". رموز سلسلة الـ 500 الأخرى في هذه الصفحة غير ذات صلة — فالرموز من 514 إلى 518 تخص صوت Instagram Reels. طابق على code الرقمي، لا على نص الرسالة، الذي قد يتغيّر أو يُترجم. أي من هذه الرموز تستطيع صفحتك سماعه. مع ضبط origin، ترسل نافذة الربط المنبثقة أحداث اكتمال الربط إلى صفحتك، ويمكن أن يصل 513 بهذه الطريقة كـ connect:error. أما 501 و502 و503 فلا يمكنها ذلك: فالرابط الميت يُرفض قبل أن تعرف الصفحة إلى أين ترسل الأحداث، فيرى مستخدمك السبب على الشاشة وتسمع صفحتك connect:cancelled عندما يغلق النافذة. للتمييز بين تلك الثلاثة، استطلع الحصول على Link Session. الرموز من 504 إلى 510 هي رفض لطلب POST نفسه ولا تصل أبدًا كأحداث إطلاقًا، بينما يُرفع 511 و512 أثناء استدعاء الشبكة الاجتماعية الراجع، فيظهران هناك لا على صفحتك.

أخطاء مفاتيح X/Twitter BYO

رموز الأخطاء التالية خاصة بعمليات مفاتيح X/Twitter BYO (Bring Your Own): الرمز 272 - فشل التحقق من هوية BYO Twitter (HTTP 400) لم يتمكن Ayrshare من تأكيد هويتك على X/Twitter باستخدام مفاتيح المستهلك BYO وعلامات OAuth المخزّنة وقت الربط. يختلف شكل الاستجابة بحسب الاستدعاء الذي أطلقها؛ يُطابق كلا الشكلين نفس الحالات الفرعية الثلاث أدناه. تحقق من أي منها ينطبق بتسجيل الدخول إلى x.com بالحساب الذي يملك BYO Developer App. مسار النشر يُصدر استجابة موجزة:
يُصدر مسار التحليلات رسالة أطول وذاتية التوثيق وقد يتضمن حقل details يحمل نص خطأ X الأصلي:
عند حضوره، يعكس details تلميح جانب X ويُعدّ الإشارة الأكثر موثوقية لأي حالة فرعية أدناه تنطبق. الحساب موقوف. تسجيل الدخول إلى x.com يعرض إشعار إيقاف. الإجراء: اتصل بدعم X. لن تُعيد إعادة الربط الوصول حتى تُعيد X تفعيل الحساب. الحساب مقفل. تسجيل الدخول إلى x.com يعرض تحدي فتح (CAPTCHA، تحقق هاتف، إلخ). الإجراء: أكمل تحدي الفتح على x.com، ثم أعد الطلب. لا يلزم إعادة الربط. عدم تطابق الهوية أو المفتاح. حسابك X في وضع جيد على x.com، لكن مفاتيح المستهلك BYO تنتمي إلى تطبيق X Developer مختلف عن علامات OAuth المخزّنة وقت الربط. الإجراء: أعد ربط X ضمن Social Accounts وصرّح بنفس حساب X الذي يملك BYO Developer App. الرمز 364 — حد معدل X (HTTP 429) قيّدت X طلبًا أُرسل باستخدام مفاتيح BYO الخاصة بك. هذا هو رمز حد المعدل المشترك في Ayrshare، وهو يغطي الآن مسار قراءة تعليقات X: يُعيده Get Comments عندما تفرض X حد المعدل على القراءة، بعد أن كانت تُعاد سابقًا قائمة تعليقات فارغة بدلًا منه.
الإجراء: انتظر حتى تُعاد تهيئة نافذة حد المعدل في X، ثم أعد المحاولة. تطبّق X حدودها لكل X Developer App، لذا تُحتسب الطلبات من كل User Profile يستخدم مفاتيح BYO نفسها ضمن الحد نفسه. الرمز 416 — نفاد أرصدة X (HTTP 402) لا يوجد لحساب X Developer الخاص بك أي أرصدة API مُحمَّلة. تتطلب جميع استدعاءات X API أرصدة، لذا قد يُعاد هذا الرمز على أي مسار في X: النشر والتحليلات والقراءات مثل Get Comments. وعلى مسار التعليقات يحل محل قائمة التعليقات الفارغة التي كانت تُعاد سابقًا، فلم يعد نفاد الأرصدة يُبلَّغ عنه على أنه منشور بلا تعليقات. تُحتسب عمليات تحميل الوسائط كاستدعاءات API. يؤدي إرسال صورة أو فيديو مع منشور X إلى إرجاع code: 416 عند نفاد أرصدة الحساب، لذا لا يقتصر الرمز 416 على نشر النصوص أو جلب التحليلات. تفشل عملية التحميل قبل نشر المنشور، ولا تتم إعادة المحاولة — إذ لا يمكن أن تنجح أي إعادة محاولة قبل توفّر أرصدة في الحساب.
الإجراء: اذهب إلى console.x.com → Billing → Credits واشترِ أرصدة. حتى $5 كافية لمئات استدعاءات API. الرمز 417 — أذونات تطبيق OAuth 1.0a (HTTP 403) لا يمتلك X Access Token الأذونات الصحيحة للعملية المطلوبة.
قد ترى أيضًا ترويسة الاستجابة x-access-level: read، والتي تؤكد أن Access Token الخاص بك تم توليده بأذونات للقراءة فقط. الإجراء: في X Developer Console، حدّث أذونات تطبيقك إلى Read and write and Direct message، ثم أعد توليد Access Token تحت Keys and tokens. سيرث الرمز الجديد الأذونات المُحدَّثة. راجع دليل إعداد مفاتيح X BYO للتفاصيل. الرمز 419 - بيانات اعتماد BYO مفقودة (HTTP 400) تتطلب عمليات X/Twitter بيانات اعتماد API الخاصة بـ BYO في ترويسات الطلب. يُعيد Ayrshare الرمز 419 عندما تكون كلتا الترويستين مفقودتين، وكذلك عندما يكون واحد فقط من الزوج موجودًا. تختلف سلسلة message بحسب أي ترويسة/ترويسات مفقودة. عندما يكون كل من X-Twitter-OAuth1-Api-Key وX-Twitter-OAuth1-Api-Secret مفقودَين:
عندما يكون واحد فقط من الزوج موجودًا (مثلًا، المفتاح دون السر):
الإجراء: أرسل كلًا من X-Twitter-OAuth1-Api-Key وX-Twitter-OAuth1-Api-Secret على كل طلب مُوجَّه إلى X. إذا قدّمت أحدهما دون الآخر، فسيُرفض الطلب بنفس الرمز. راجع مرجع ترويسات مفاتيح X BYO للقائمة الكاملة للترويسات. الرمز 423 — OAuth القديم لـ X/Twitter لم يعد مدعومًا (HTTP 403) يُعاد عندما يعتمد طلب X/Twitter على مسار OAuth القديم (غير BYO)، الذي لم يعد مدعومًا. يتطلب وصول X API الآن بيانات اعتماد X Developer App الخاصة بك، المُقدَّمة عبر ترويسات الطلب.
الإجراء: هيّئ X Developer App وأرسل ترويسات X-Twitter-OAuth1-Api-Key وX-Twitter-OAuth1-Api-Secret في كل طلب مُوجَّه إلى X. راجع دليل إعداد مفاتيح X BYO لخطوات الإعداد الكاملة.

أخطاء تحسين التسميات التوضيحية

الرمز 441 — فشل تحسين التسمية التوضيحية (HTTP 502) يُعاد عندما يفشل تحسين تسمية توضيحية (مثل shortenLinks) لمنصة واحدة أو أكثر أثناء تحضير منشور. تظهر كل منصة متأثرة في مصفوفة errors مع source: "handlePostAdditions" وcode: 441. عندما تفشل بعض المنصات فقط، تُنشر المنصات الأخرى بنجاح وتظهر نتائجها في postIds. في تلك الحالة يكون status على المستوى الأعلى "error" لكن postIds غير فارغ — يجب أن يعامل العملاء status وerrors[] كمتكاملَين وليس متنافيَين.
إذا فشل جميع المنصات في التحسين، تكون الاستجابة code: 441 على المستوى الأعلى مع HTTP 502 ولا يُنشأ أي منشور:
الإجراء: إخفاقات تحسين التسميات التوضيحية عابرة عادةً (خدمة الاختصار أو التحسين الأساسية أعادت خطأً).
  • إذا كان postIds غير فارغ (نشرت بعض المنصات بنجاح)، لا تعِد إرسال مجموعة المنصات الكاملة — سيؤدي ذلك إلى تكرار المنشور على المنصات الناجحة. بدلًا من ذلك، افحص errors[] لتحديد المنصات الفاشلة وأعد الطلب مع تلك المنصات فقط، أو اعتمد على تدفق إعادة المحاولة الآمن من التكرار لديك.
  • إذا كان postIds فارغًا أو مفقودًا (فشل تام وقت الجدولة/النشر)، أعد إرسال الطلب الكامل بأمان.
  • إذا استمر الفشل، أرسل المنشور بدون علامة التحسين (مثلًا، احذف shortenLinks) أو اتصل بالدعم.

أخطاء جلب الوسائط / وصول الزاحف

الرمز 499 — فحص وسائط Ayrshare غير متاح مؤقتًا (HTTP 503) يُعاد عندما لا يستطيع Ayrshare إكمال فحص الوسائط السابق للنشر لأنه تعذّر الوصول إلى خدمة فحص الوسائط الداخلية أو أنها أعادت استجابة غير صالحة. هذا فشل في خدمة Ayrshare، وليس دليلًا على أن mediaUrl أو تهيئة CDN أو قواعد وكيل المستخدم (user-agent) أو robots.txt لديك غير صحيحة. يحمل الخطأ retryAvailable: true؛ أعد المحاولة على المنصة الفاشلة بعد فترة وجيزة. إذا نجح طلب متعدد المنصات جزئيًا، فأعد المحاولة فقط على المنصات المدرجة في errors[] لتجنّب النشر المكرر.
الرمز 164 — تعذّر على Ayrshare الوصول إلى الوسائط (HTTP 400) الرمز 164 هو مظروف قديم للوصول إلى الوسائط / المدخلات ويُستخدم في عدة مسارات، بما في ذلك mediaUrls مشوّهة، والوسائط التي لا يمكن قراءتها، وبعض حالات فشل الرفع أو الجلب عبر الشبكة. تحقق أولًا من أي حقل details مُعاد. بالنسبة لفشل الوصول، تأكد من أن عنوان URL متاح للعموم، ويظل صالحًا لفترة كافية للنشر، ولا يحجب الطلبات البعيدة. يُجري /media/urlExists فحص إمكانية وصول HEAD فقط؛ ونجاحه لا يضمن أن فحص الوسائط الأعمق السابق للنشر أو أن زاحف الشبكة الاجتماعية يمكنه تنزيل الملف ومعالجته. عندما يكون الفشل تحديدًا هو عدم توفر خدمة الفحص الخاصة بـ Ayrshare نفسها، فستستقبل الرمز 499 القابل لإعادة المحاولة بدلًا من الرمز 164. الرمز 440 — لم تتمكن الشبكة الاجتماعية من تنزيل الوسائط (HTTP 400) يُعاد عندما لا يستطيع زاحف نشر المنصة تنزيل mediaUrl الذي قدّمته — الأسباب الأكثر شيوعًا هي أن robots.txt أو قاعدة WAF / bot-fight تحجب الزاحف (مثل facebookexternalhit من Meta). تأتي سلسلة details من المنصة الأعلى، وغالبًا ما تكون نص الخطأ 2207052 من Meta/Instagram.
الرمز 138 — جلب وسائط Instagram محجوب (HTTP 400) الرمز الاحتياطي لإخفاقات جلب وسائط Instagram عندما تكون الاستجابة الأعلى أقل تحديدًا من تلك التي تُطلق الرمز 440. تحتوي سلسلة details عادةً على "Restricted by robots.txt" أو "HTTP error code 403". يُستخدم الرمز 138 أيضًا لمشكلات نسبة العرض / التنسيق وأخطاء Instagram عامة أخرى، لذا يمكن التعرف على النسخة الخاصة بجلب الوسائط عبر سلسلة details.
الرمز 379 — خطأ نشر Threads يُعاد عندما يفشل النشر على Threads. غالبًا ما يكون السبب هو نفس مشكلة جلب الوسائط الخاصة بالرموز 440 / 138 عند النشر على كلا المنصتين بنفس mediaUrl. لا تُعيد Threads API سلاسل تفاصيل، لذا يتطلب التشخيص عادةً التحقق من وجود 440 أو 138 مصاحب لـ Instagram في نفس النشر.
الإجراء: راجع Meta Media Crawler Blocked لاستكشاف الأخطاء الكامل، بما في ذلك مقتطفات robots.txt وأمر تحقق.

وسائط Threads غير جاهزة

الرمز 522 — وسائط Threads غير جاهزة للنشر (HTTP 400) لم تكن Threads قد انتهت من تجهيز المنشور عندما حاولت Ayrshare نشره. قد تُبلغ Threads بأن المنشور جاهز قبل بضع ثوانٍ من قبولها للنشر فعليًا. تنتظر Ayrshare وتعيد المحاولة لمدة تصل إلى 30 ثانية إجمالًا لمنشور Threads، عبر جميع أجزاء السلسلة متعددة الأجزاء، قبل إعادة هذا الخطأ، لذا تُنشر معظم هذه المنشورات الآن دون أي خطأ. يكون هذا عادةً مؤقتًا من جانب Threads ولا يكون المحتوى الخاص بك هو السبب. تحصل تعليقات Threads والردود والتعليقات الأولى على فترة الانتظار نفسها (يحصل التعليق الأول على 30 ثانية خاصة به بعد نشر المنشور)، لكنها لا تُعيد الرمز 522. في السلسلة متعددة الأجزاء، لا يكون كائن code: 522 موجودًا مباشرةً في errors: بل يكون الإدخال الأخير في مصفوفة posts الخاصة بخطأ Threads، وتنطبق حالة HTTP 400 المذكورة أعلاه على منشور Threads واحد فقط. لا يؤدي noAutoRetry: true إلا إلى منع خادم Ayrshare MCP من إعادة محاولة المنشور تلقائيًا؛ ولا يزال بإمكانك إعادة المحاولة.
الإجراء: لا تحتاج إلى تغيير المنشور. تحقق من postIds أولًا. إذا لم يُنشر شيء، فأعد محاولة المنشور باستخدام نقطة نهاية retry post. إذا كانت منصة أخرى في المنشور نفسه قد نُشر عليها بالفعل، فأرسل بدلًا من ذلك منشورًا جديدًا إلى Threads فقط: تُعيد retry post إرسال الحمولة الأصلية إلى كل المنصات، مما سيؤدي إلى النشر على المنصات الناجحة مرة ثانية. السلاسل متعددة الأجزاء: لا يُثبت كون postIds فارغًا أنه لا يوجد أي جزء من السلسلة منشور. تحذف Ayrshare الأجزاء التي نُشرت عندما يفشل جزء لاحق، ولكن إذا فشل الحذف، يبقى ذلك الجزء على Threads. قبل إعادة محاولة سلسلة متعددة الأجزاء، تحقق من حساب Threads واحذف أي أجزاء لا تزال موجودة، وإلا فستنشرها إعادة المحاولة مرة أخرى.

حد معدل تحليلات Facebook

الرمز 444 — حد معدل تحليلات صفحة Facebook (HTTP 429) يُعاد عندما تكون صفحة Facebook قد تجاوزت حد معدل Meta لكل صفحة على نقطة نهاية التحليلات. خطأ Meta الأساسي هو 80001 (“There have been too many calls to this Page account.”). تبقى الصفحة مرتبطة ويستمر النشر بالعمل — تُقيَّد فقط تفرعات التحليلات لتلك الصفحة. عند اكتشاف التقييد لمنشور واحد في استجابة /history/facebook أو analytics، يحمل كل منشور متأثر code: 444 عند facebook.code مع errCode: 80001:
الإجراء: انتظر بضع دقائق وأعد المحاولة. تُحلّ نافذة حد المعدل لكل صفحة من Meta عادةً خلال ساعة دون أي إجراء على الصفحة. لا تطلب من المستخدم إعادة ربط الحساب — هذا تقييد عابر من جانب Meta وليس فشل تصريح.
إذا كنت تتعامل مع هذه الحالة سابقًا كـ code: 161 (“Facebook authorization error … unlink and re-link”)، فحدّث تكاملك للتعرف على code: 444 وأعد المحاولة مع تراجع تصاعدي بدلًا من بدء تدفق إعادة ربط. تم تصحيح تصنيف 161 في أبريل 2026.

التحقق من هوية Meta

الرمز 326 — مطلوب التحقق من هوية Meta (HTTP 403) يُعاد عندما تتطلب Meta تحققًا إضافيًا من الهوية للحساب المتصل قبل قبول الطلب. ينطبق ذلك عبر منصات Meta — Facebook وInstagram وFacebook Groups وThreads وMessenger. إعادة توصيل الحساب لا تحل هذا؛ يجب إكمال التحقق من جانب Meta.
الإجراء: اطلب من مالك الحساب إكمال التحقق من هوية Meta في Meta Business Support، ثم أعد الطلب. لا تطلب من المستخدم إعادة ربط الحساب — إعادة الربط لن تُزيل هذا المطلب.

حظر Facebook بموجب معايير المجتمع

الرمز 249 — حظر Facebook بموجب معايير المجتمع (HTTP 400) يُعاد عندما يحظر Facebook منشورًا بموجب معايير المجتمع (Community Standards) الخاصة به. قد يكون الحظر مفروضًا على حساب Facebook أو الصفحة، أو على المنشور نفسه. يستخدم Facebook الخطأ الأساسي نفسه في الحالتين ولا يوضح أيهما ينطبق. عمليًا، يُفرض الحظر في أغلب الأحيان على الحساب أو الصفحة، لذا فإن إعادة صياغة المحتوى أو إعادة إرساله لا تفيد في كثير من الأحيان. كما هو الحال مع تقييد حساب Facebook (الرمز 476)، هذا إجراء تنفيذي من جانب Meta، فهو غير قابل للإعادة ولا يحمل علامة retryAvailable. عند المخالفة الأولى يبقى الحساب مرتبطًا بـ Ayrshare ولا يلزم إعادة ربط، فإعادة الربط لا تُزيل الحظر. أما المخالفة المتكررة فأمرها مختلف؛ راجع أدناه. لا يُعيد Facebook السبب المحدد عبر API، لذا يجب على العميل التحقق من صفحة حالة الحساب (Account Status) على Facebook مباشرةً لرؤية السبب والاستئناف. عندما يقدم Facebook نصه الخاص، يعرضه Ayrshare في حقل details. يُرسل Ayrshare أيضًا بريدًا إلكترونيًا إخطاريًا لمالك الحساب عند اكتشاف الحظر. تؤدي مخالفة متكررة لمعايير المجتمع على ملف المستخدم (User Profile) نفسه إلى إلغاء ربط حساب Facebook بـ Ayrshare وتعليق ملف المستخدم.
اعتمد في المطابقة على القيمة الرقمية لـ code وهي 249، وليس على نص message. قد تُحسَّن صياغة message بمرور الوقت، بينما يبقى الرمز ثابتًا. الإجراء: سجّل الدخول إلى Facebook، انقر على صورة ملفك الشخصي (أعلى اليمين)، افتح قسم Help وحدد Account Status. يعرض مساعد الدعم من Facebook هناك السبب المحدد (الذي لا تُعيده API) ويتيح لك الاستئناف. لا تطلب من المستخدم إعادة ربط الحساب، فإعادة الربط لا تُزيل الحظر المفروض على مستوى الحساب أو الصفحة. راجع هل حسابك على Facebook أو Instagram مقيّد؟ للاطلاع على دليل استكشاف الأخطاء وإصلاحها الكامل.

تقييد حساب Facebook

الرمز 476 — تقييد حساب Facebook (HTTP 400) يُعاد عندما يفشل منشور إلى Facebook لأن Meta وضعت تقييدًا على الحساب (رموز Meta الفرعية 2424009 و1404078، أو صياغة التقييد من Meta عندما لا يحمل الخطأ رمزًا فرعيًا). هذا تقييد على مستوى الحساب، وليس عارضًا مؤقتًا في النشر — إنه غير قابل للإعادة ولا يحمل علامة retryAvailable. إعادة إرسال نفس المنشور لن تنجح حتى يُحل التقييد مع Meta. يبقى الحساب مرتبطًا بـ Ayrshare؛ لا يلزم إعادة ربط. لا تُعيد Meta سبب التقييد المحدد عبر API، لذا يجب على العميل التحقق من صفحة حالة حساب Meta مباشرةً لرؤية السبب والاستئناف. عندما تقدم Meta نصها الخاص، يعرضه Ayrshare في حقل details. يُرسل Ayrshare أيضًا بريدًا إلكترونيًا إخطاريًا لمالك الحساب عند اكتشاف التقييد.
الإجراء: سجّل الدخول إلى Facebook، انقر على صورة ملفك الشخصي (أعلى اليمين)، افتح قسم Help وحدد Account Status. يعرض مساعد الدعم من Meta هناك سبب التقييد المحدد ويتيح لك الاستئناف. نظرًا لأن التقييد تفرضه Meta على مستوى الحساب، فإن هذا الرمز غير قابل للإعادة — لا تُبنِ منطق إعادة المحاولة التلقائية حوله؛ حُل التقييد مع Meta أولًا.

أخطاء تحويل تنسيق الصورة

يحوّل Ayrshare تلقائيًا صور WebP وHEIC وHEIF وAVIF إلى JPEG قبل النشر على المنصات التي لا تقبلها (Instagram وLinkedIn وTikTok وGoogle My Business وThreads وSnapchat لـ WebP؛ جميع المنصات لـ HEIC وHEIF وAVIF). يعمل التحويل بشفافية وقت الإرسال. تُطلق الأخطاء الثلاثة أدناه فقط عندما لا يستطيع خط التحويل نفسه الإكمال؛ إذا كانت الصورة المصدر بالفعل بتنسيق مدعوم، فلن تُحاول أي تحويل ولن تظهر هذه الرموز. الرمز 450 — فشل تحويل تنسيق الصورة (HTTP 400) نُزّلت الصورة لكن لم يُتمكن من إعادة ترميزها كـ JPEG. الأسباب الأكثر شيوعًا ملف مصدر تالف، أو تنسيق داخلي غير متوقع داخل الحاوية، أو صورة تتجاوز الحد الأقصى لحجم التحويل.
الإجراء: افتح mediaUrl المصدر مباشرةً في متصفح للتأكد من عرضه. إذا فُتح، أعد تصدير الصورة إلى JPEG أو PNG نظيف وأعد المحاولة. الرمز 451 — فشل تنزيل الصورة للتحويل (HTTP 400) لم يتمكن خط التحويل من جلب الصورة المصدر. الأسباب النموذجية تشمل استجابة 4xx/5xx من الأصل، أو انتهاء مهلة الشبكة، أو سلسلة إعادة توجيه تتجاوز حد القفزات، أو URL يُحل إلى عنوان غير عام (محجوب بحارس SSRF). يحمل حقل details، عند حضوره، سلسلة السبب الأساسي.
الإجراء: تأكد من أن mediaUrl قابل للوصول عامًا (بدون تصريح، بدون حجوبات robots.txt، يُحل عبر HTTPS). إذا أعاد الـ URL توجيهًا، تأكد من أن الوجهة النهائية عامة أيضًا وليست على شبكة خاصة. الرمز 452 — فشل تحميل الصورة المُحوَّلة (HTTP 500) نجح التحويل لكن Ayrshare لم يتمكن من تخزين JPEG المُحوَّل مؤقتًا في حاوية التخزين المؤقتة. هذا فشل داخلي في جانب Ayrshare وقابل للإعادة.
الإجراء: أعد محاولة المنشور. إذا استمر الخطأ عبر عدة محاولات، اتصل بالدعم مع mediaUrl والطابع الزمني التقريبي.

أخطاء تحميل YouTube العابرة

توفر رموز الأخطاء التالية إشارات محددة لإخفاقات تحميل YouTube العابرة عادةً والآمنة للإعادة. تتضمن كلتا الاستجابتين retryAvailable: true، بحيث يمكن للتكاملات التفرّع على تلك القيمة المنطقية بدلًا من رمز حالة HTTP. معظم استجابات code: 176 السابقة لتحميلات YouTube تُوَّجّه الآن إلى 453 (انتهاء مهلة عابر) أو 454 (خدمة غير متوفرة عابرة)، وكلاهما مع retryAvailable: true. إذا كان تكاملك يُصفّي على HTTP 500 لإعادة تحميلات YouTube، فبدّل إلى التصفية على حقل retryAvailable في جسم الاستجابة. الرمز 453 — انتهت مهلة تحميل YouTube (HTTP 504) يُعاد عندما تنتهي مهلة خط استيعاب YouTube من Google أثناء قبول التحميل. عادةً ما يكون هذا عابرًا ويحل نفسه في غضون دقيقة أو دقيقتين.
الإجراء: أعد محاولة المنشور بعد 1-2 دقيقة مع تراجع تصاعدي. تفرّع على حقل retryAvailable في جسم الاستجابة بدلًا من حالة HTTP لاكتشاف الإخفاقات القابلة للإعادة. يمكنك استخدام نقطة نهاية retry post لإعادة إرسال نفس الحمولة. الرمز 454 — خدمة تحميل YouTube غير متوفرة مؤقتًا (HTTP 503) يُعاد عندما تعيد نقطة نهاية تحميل YouTube حالة 5xx، أو عندما يُعاد تعيين الاتصال بـ YouTube أو تنتهي مهلته على مستوى المقبس (ECONNRESET، ETIMEDOUT، ESOCKETTIMEDOUT). هذه الحالات عابرة.
الإجراء: أعد محاولة الطلب مع تراجع تصاعدي. تفرّع على حقل retryAvailable في جسم الاستجابة بدلًا من حالة HTTP لاكتشاف الإخفاقات القابلة للإعادة.
عندما يستهدف المنشور أكثر من منصة واحدة، تحقق من postIds قبل إعادة المحاولة. الفشل على منصة واحدة يُعلّم المنشور بأكمله كخطأ حتى مع نشر المنصات الأخرى، وتُعيد retry post إرسال الحمولة الأصلية إلى كل منصة في ذلك المنشور — مما سينشر المنصات الناجحة مرة ثانية. أرسل منشورًا جديدًا للمنصات المذكورة في errors بدلًا من ذلك، واستخدم retry post فقط عندما لم يُنشر أي شيء.

أخطاء صور YouTube المصغّرة الرمز 307

يُعاد الرمز 307 عندما لا يمكن تطبيق thumbNail مخصص لـ YouTube. عندما ينشر الفيديو نفسه بنجاح، فإن هذا لا يُفشل المنشور — تبقى نتيجة YouTube بحالة status: "success" ويظهر الفشل بشكل إضافي في مصفوفة warnings (feature: "thumbnail"، code: 307). يُحتفظ بالكائن الفرعي القديم thumbnail للتوافق العكسي. السبب الأكثر شيوعًا هو قناة YouTube غير مُتحقّق منها. عندما لم تُكمل قناة التحقق الهاتفي، يُعيد YouTube 403 أعلى مع الرسالة العامة "The authenticated user doesn't have permissions to upload and set custom video thumbnails". تبدو تلك الصياغة مثل مشكلة OAuth، لكنها عمليًا مشكلة تحقق دائمًا تقريبًا، لذا تحقق من القناة أولًا. إعادة ربط حساب YouTube هو سبب ثانوي.
يتحقق Ayrshare أيضًا من الصورة المصغّرة قبل النشر حيثما أمكن: يجب أن يكون الملف PNG أو JPG/JPEG، و2 ميجابايت أو أقل، ومُقدَّمًا من URL يمكن الوصول إليه. لا تُفشل مشكلة الصورة المصغّرة المنشور أبدًا — يُنشر الفيديو دائمًا ويظهر الفشل دائمًا كإدخال warnings غير قاتل (يبقى status على المستوى الأعلى "success"). يصح ذلك بغض النظر عن متى تُكتشف المشكلة:
  • مُلتقطة قبل التحميل. عندما يستطيع التحقق قبل النشر أن يجزم أن الصورة المصغّرة غير صالحة (نوع ملف خاطئ، أكثر من 2 ميجابايت مؤكدًا، أو URL غير قابل للوصول)، يتخطى Ayrshare الصورة المصغّرة، لا يزال ينشر الفيديو، ويُبلّغ عن السبب الدقيق في warnings — لذا تتجنب محاولة تحميل محكوم عليها بالفشل وتحصل على رسالة أوضح من تلك التي يُعيدها المزود.
  • مُلتقطة بعد التحميل. عندما يمكن اكتشاف الفشل فقط بمجرد أن يعالج YouTube الطلب (مثلًا 403 القناة غير المُتحقّق منها، أو 413 لصورة كبيرة الحجم)، فإن الفيديو مباشر بالفعل ويظهر الفشل في نفس مصفوفة warnings.
في كلتا الحالتين، تبدو الاستجابة مثل مثال status: "success" + warnings الموضّح سابقًا في هذا القسم. الإجراء: تحقق من قناة YouTube الخاصة بك على https://www.youtube.com/verify (تحقق هاتفي). إذا كانت قناتك مُتحقّقة بالفعل ولا تزال الصور المصغّرة تفشل، فألغِ ربط حساب YouTube وأعد ربطه في Social Accounts وامنح جميع الأذونات. راجع YouTube Thumbnail Not Applied (Unverified Channel) لدليل استكشاف الأخطاء الكامل.

أخطاء تفويض Google Business Profile

الرمز 519 — خدمة تفويض Google Business Profile غير متوفرة مؤقتًا (HTTP 503) يُعاد عندما يتعذر على Ayrshare إكمال تجديد رمز تفويض Google، لأن نقطة نهاية الرموز لدى Google كانت بطيئة في الاستجابة أو أعادت فشلًا عابرًا. تُعاد محاولة التجديد تلقائيًا قبل إعادة هذا الرمز، وتحمل الاستجابة retryAvailable: true، بحيث يمكن للتكاملات التفرّع على تلك القيمة المنطقية بدلًا من رمز حالة HTTP. يبقى الحساب متصلًا — هذه حالة مؤقتة في خدمة تفويض Google، وليست اتصالًا معطوبًا. كل عملية على Google Business Profile تُجدّد التفويض أولًا، لذا يمكن لـ أي منها أن تُعيد هذا الرمز — نشر منشور، وقراءة سجل المنشورات، وتحديث بيانات الموقع، وجلب الحساب المتصل، وسرد المراجعات، والرد على مراجعة. معظم استجابات code: 227 السابقة على هذه المسارات تُوَجّه الآن إلى 519 مع retryAvailable: true. يطلب الرمز 227 من المستخدم إعادة ربط الحساب، وهو ما لم يحل قط فشل تجديد عابرًا — فقد كان التفويض نفسه سليمًا طوال الوقت. إذا كان تكاملك يُصفّي على 227 لطلب إعادة ربط Google Business Profile، فبدّل إلى التفرّع على حقل retryAvailable في جسم الاستجابة وإعادة المحاولة مع تراجع بدلًا من ذلك.
يحمل details السبب الذي أبلغ عنه Google، أو — عندما تنتهي مهلة التجديد محليًا دون جسم استجابة من Google — ملخصًا للمحاولات التي جرت والوقت المنقضي. الإجراء: أعد محاولة الطلب مع تراجع تصاعدي. تفرّع على حقل retryAvailable في جسم الاستجابة بدلًا من حالة HTTP لاكتشاف الإخفاقات القابلة للإعادة.
بالنسبة لمنشور متعدد المنصات فاشل، افحص postIds وerrors أولًا؛ إذا نجحت منصة أخرى بالفعل، فأعد المحاولة لمنصة GMB الفاشلة فقط بدلًا من إعادة إرسال الحمولة الكاملة — تُعيد retry post إرسال الحمولة الأصلية إلى كل منصة في ذلك المنشور، مما سينشر المنصات الناجحة مرة ثانية. بالنسبة لمنشور فشل بالكامل، يمكنك استخدام نقطة نهاية retry post لإعادة إرسال نفس الحمولة.

تحذير إفصاح AI في Pinterest

الرمز 521 — لم تُطبَّق إفصاحات AI في Pinterest (HTTP 200) تحذير وليس خطأ. يُعاد عندما يكون pinterestOptions.aiDisclosures غير صالح، على سبيل المثال قيمة غير معروفة أو حالة أحرف خاطئة. عبر REST API، تُعيد القيمة التي ليست مصفوفة من النصوص الرمز 521 أيضًا. لا يزال الـ Pin يُنشر، لكن Ayrshare لا ترسل أي إفصاح عن الذكاء الاصطناعي إلى Pinterest. يتحقق خادم MCP وGraphQL API من أنواع القيم أولًا، لذا تُرفض هناك القيم غير الصحيحة البنية، مثل قائمة تحتوي على رقم، قبل النشر. يصل التحذير في postIds[].warnings[] الخاص بإدخال Pinterest، وليس في errors[]، ويحمل feature: "pinterestOptions.aiDisclosures". القيم المقبولة هي AI_MODIFIED وSYNTHETIC_PERFORMER.

أخطاء النشر على Reddit

الرمز 442 — Subreddit محظور على Reddit (HTTP 400) يُعاد عندما يُحظر الحساب من النشر على الـ subreddit المستهدف. لا يمكن إعادة المحاولة — لن ينجح المنشور إذا أُعيد إرساله كما هو. تتضمن الرسالة اسم الـ subreddit المتأثر (مثل r/news).
الإجراء: أزل الـ subreddit المحظور من الـ subreddits المستهدفة. إعادة محاولة المنشور دون تغيير لن تنجح. الرمز 443 — كلمة غير مسموح بها في عنوان Reddit (HTTP 400) يُعاد عندما يرفض subreddit المنشور لأن عنوانه يحتوي على كلمة غير مسموح بها. عدّل العنوان قبل إعادة المحاولة — إعادة الإرسال كما هو لن تنجح. تتضمن الرسالة اسم الـ subreddit المتأثر (مثل r/news).
الإجراء: عدّل عنوان المنشور لإزالة الكلمة غير المسموح بها، ثم أعد المحاولة.

أخطاء الاعتدال

الرمز 438 — مدخل الاعتدال مرفوض (HTTP 400) يُعاد بواسطة POST /validate/moderation عندما يرفض مزود الذكاء الاصطناعي المدخل المُقدَّم — على سبيل المثال، نوع ملف غير مدعوم. هذه مشكلة مدخلات مع الطلب، وليست فشل معالجة عابر.
الإجراء: تحقق من أن مدخل الاعتدال صالح ويستخدم نوع ملف مدعوم، ثم أعد الإرسال.
قارن الرمز 438 مع الرمز 331. يغطي الرمز 331 نفس سيناريو الاعتدال لكنه يمثّل فشل معالجة حقيقيًا من جانب المزود (HTTP 500، الرسالة “There was an issue with the AI processing. Please try again.”). الرمز 331 فشل عابر من جانب الخادم يمكنك إعادة محاولته، بينما يشير الرمز 438 إلى أن المدخل نفسه رُفض ويجب تصحيحه قبل إعادة المحاولة.

أخطاء تحديث تفويض LinkedIn

الرمز 524 — رفض تحديث رمز LinkedIn المميز (HTTP 500) يُعاد عندما يرفض LinkedIn تحديث التفويض بسبب مشكلة في إعدادات LinkedIn الخاصة بالتطبيق، وليس في حساب المستخدم. يظل اتصال LinkedIn الخاص بالمستخدم صالحًا، لذا فإن إعادة الربط لا تحل المشكلة. لا تتضمن الاستجابة الحقل resolution.relink، وتحمل retryAvailable: false لأن إعادة المحاولة لا تحل المشكلة. يمكن لأي عملية في LinkedIn تقوم بتحديث التفويض أولًا أن تُعيد هذا الرمز، مثل نشر منشور بعد انتهاء صلاحية رمز الوصول.
الإجراء: تواصل مع دعم Ayrshare مع تفاصيل الطلب. لا تطلب من المستخدم إعادة ربط LinkedIn. إعادة الربط لا تساعد، كما أن إزالة Ayrshare من إعدادات LinkedIn نفسها تُلغي وصول المستخدم على كل ملف تعريف قام بربطه.
إذا استمر LinkedIn في إفشال التحديث لسبب مؤقت، فإن Ayrshare يعيد المحاولة ثم يُعيد الرمز 119 (“There was an issue connecting with LinkedIn. Please try again.”) بدلًا من ذلك. يمكن إعادة المحاولة لاحقًا بأمان مع الرمز 119؛ أما الرمز 524 فلا تحله إعادة المحاولة.

أخطاء تحليلات LinkedIn

الرمز 475 — أعد ربط ملف LinkedIn للحصول على التحليلات (HTTP 403) يُعاد بواسطة POST /analytics/post وPOST /analytics/social لملف LinkedIn شخصي (عضو) رُبط قبل شحن تحليلات الأعضاء. تفتقر هذه الملفات إلى نطاقات تحليلات أعضاء LinkedIn (r_member_postAnalytics، r_member_profileAnalytics)، لذا يرفض LinkedIn طلب التحليلات. لا يتأثر النشر.
الإجراء: اطلب من مالك الحساب إعادة ربط ملف LinkedIn الخاص به في Social Accounts لمنح نطاقات التحليلات الجديدة، ثم أعد محاولة طلب التحليلات. بعد إعادة الربط، انتظر بضع دقائق قبل أن يُمسح الخطأ: يُخزّن Ayrshare هذا الخطأ مؤقتًا لفترة قصيرة كما يُخزّن LinkedIn أيضًا أذونات الرمز، لذا يمكن لملف تمت إعادة ربطه أن يستمر في إعادة الرمز 475 لمدة تصل إلى ~5-10 دقائق قبل نجاح التحليلات.

أخطاء تعليقات TikTok

الرمز 288 — تعليق TikTok مؤجل / المنشور لا يزال في المعالجة (HTTP 400) يعالج TikTok الفيديوهات بشكل غير متزامن، لذا فإن id للمنشور المُنشور حديثًا هو "pending" حتى يحل webhook post.publish.publicly_available من TikTok معرّف الفيديو الحقيقي. يُرفض طلب get-comments أو تعليق أو رد على منشور لا يزال في المعالجة (أو id هو "failed") قبل أي استدعاء لـ TikTok ويُعاد الرمز 288 بدلًا من فشل عام.
الإجراء: انتظر حتى ينتهي TikTok من المعالجة، ثم أعد المحاولة. استمع إلى tikTokPublished Scheduled Action webhook أو استعلم /history حتى يصبح id المنشور معرّف الفيديو الرقمي المحلول. يُنشر تعليق أول تلقائيًا بمجرد أن يُحل المنشور، لذا لا يلزم إعادة محاولته. لمنشور "failed" بدلًا من ذلك تُشير الرسالة إلى أن الفيديو فشل في النشر ولن يُنفَّذ الإجراء.

أخطاء Story منتهية الصلاحية أو غير المتاحة

الرمز 485 — تعليقات Instagram / Facebook Story وتحليلات Instagram Story (HTTP 404 عندما يكون تمثيليًا) يمكن أن تصبح Stories منتهية الصلاحية أو غير متاحة بعد نافذة توفرها. بعد تلك النافذة، لا يمكن استرداد التعليقات أو الرؤى. الرمز 485 يُحدّد:
  • أرجل Instagram وFacebook Story منتهية الصلاحية أو غير المتاحة من get-comments؛ و
  • ساق Instagram Story منتهية الصلاحية أو غير المتاحة من POST /analytics/post.
تحليلات Facebook Story غير متاحة ولا يشملها الرمز 485. يجب على العملاء المطابقة على code الرقمي، وليس على نص الرسالة الحرفي، الذي قد يختلف أو يُترجم. في قراءة متعددة المنصات حيث تنجح منصة أخرى واحدة على الأقل، تظهر الساق الفاشلة في مصفوفة errors[] على المستوى الأعلى بينما تُعاد المنصات السليمة بشكل طبيعي. الاستجابة الإجمالية هي HTTP 200 مع status: "partial" على المستوى الأعلى (راجع القراءات متعددة المنصات والنجاح الجزئي للتعليقات والتحليلات).

مثال نجاح جزئي في Get Comments

مثال نجاح جزئي في Post Analytics

عندما تفشل كل منصة، تحتوي الاستجابة على status: "error" على المستوى الأعلى وتشمل مصفوفة errors[] الكاملة. الرمز التمثيلي 485 يُطابق HTTP 404؛ الرموز التمثيلية الأخرى تستخدم مطابقات HTTP الخاصة بها. الإجراء: تعامل مع الرمز 485 كإشارة إلى أنه يتعذر استرداد تعليقات أو رؤى Story المطلوبة. طابق على الرمز بدلاً من استخلاص استنتاجات بشأن الفشل الدائم أو قابلية الإعادة أو ربط الحساب من نص الرسالة.

ترجمة رسالة الخطأ

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