إنتاجية واجهة واتساب Cloud API وحدود المعدل: شرح مبسّط

ما رموز الأخطاء التي تظهر عند بلوغ حد؟

طابق الرمز بالحد، ثم اختر الاستجابة.

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

على واجهة OmniChannels.ai يصل الرفض من المصدر بصيغة HTTP 502 مع رمز خطأ Meta ونصه في message، ويعيد تحديد المعدل لدينا 429 مع ترويسة Retry-After. راجع الأخطاء والحدود للجدول الكامل والحدود الافتراضية.

كيف أضع الإرسال في طابور وأعيد المحاولة؟

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

1. ضع كل إرسال في طابور. يكتب تطبيقك الرسائل في طابور ويفرغه مجمّع عمال. لا تمرّ على قائمة العملاء في حلقة داخل معالج طلب واحد.
2. قيّد المعدل بدلو الرموز (token bucket) أدنى من إنتاجيتك، مع ترك مجال للردود وللحركة الأخرى التي تشترك في السقف نفسه.
3. سجّل كل محاولة أولًا. اكتب صفًا لكل رسالة بمفتاح معرّف العملية لديك، وخزّن معرّف الرسالة المُعاد، وتجاوز كل ما قُبل سابقًا.
4. أعد محاولة الإخفاقات المؤقتة. تُعاد أخطاء التقييد وأخطاء الخادم المؤقتة؛ ولا تُعاد أخطاء التحقق (400) ولا أخطاء المصادقة ولا أخطاء القوالب.
5. تراجع مع تشويش. انتظر مدة أطول بعد كل محاولة، وأضف عشوائية كي لا يعيد العمال المحاولة معًا، وضع حدًا أقصى للتأخير ولعدد المحاولات.
6. احترم Retry-After حين تتضمنه الاستجابة.
7. تحقق قبل إعادة الإرسال بعد انتهاء المهلة. فقدان الاستجابة لا يعني فقدان الرسالة؛ انظر أولًا إلى أحداث الحالة.

const RETRYABLE = new Set([429, 500, 502, 503, 504]);

async function sendWithBackoff(send, { maxAttempts = 5, baseMs = 500, capMs = 30000 } = {}) {
  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    const res = await send();
    if (res.ok) return res;
    if (!RETRYABLE.has(res.status) || attempt === maxAttempts) throw new Error(`failed: ${res.status}`);
    const wait = Math.random() * Math.min(capMs, baseMs * 2 ** (attempt - 1)); // full jitter
    await new Promise((r) => setTimeout(r, wait));
  }
}

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

كيف أخطط لإرسال كبير؟

احسب الزمن والحدود وحمل webhooks قبل أن تبدأ.

1. احسب المستلمين الفريدين وقارنهم بحد المراسلة لديك. ابدأ بـخطة التوسع الآمن إن كانت القائمة أكبر من شريحتك.
2. قدّر المدة. عدد الرسائل مقسومًا على إنتاجيتك يعطي الثواني. حسابيًا، 100,000 رسالة بمعدل 80 في الثانية تستغرق 1,250 ثانية، أي نحو 21 دقيقة، إن لم يستخدم السقف شيء آخر.
3. احجز سعة. يحتسب السقف الرسائل الواردة أيضًا، فاترك هامشًا لردود العملاء أثناء الإرسال.
4. هيّئ خادم webhooks. تقول Meta إن خوادم webhooks ينبغي أن تتحمل ثلاثة أضعاف حركة رسائلك الصادرة إضافة إلى حركتك الواردة المتوقعة، بزمن استجابة وسيط لا يتجاوز 250 ملّي ثانية، وأقل من 1% من الطلبات فوق ثانية واحدة. راجع دليل webhooks.
5. تحقق من سلامة القوالب والجودة أولًا، وقسّم الإرسال إلى دفعات لتتمكن من التوقف إذا ارتفعت الإخفاقات أو الحظر. راجع الإرسال الجماعي دون التعرض للحظر.
6. استخدم معرّفات الوسائط لا الروابط عند إرسال الملفات بكميات كبيرة، كما تنصح Meta. راجع أنواع الوسائط وحدودها.

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

مثال تطبيقي: عرض خاطف في دبي

"Marina Gadgets" (مثال افتراضي) تخطط لقالب عرض خاطف إلى 60,000 عميل وافقوا على الاستلام.

1. حد المراسلة لديهم يسمح بذلك، فالحجم ليس القيد؛ بل السرعة. عند 80 رسالة في الثانية تحتاج 60,000 رسالة إلى 750 ثانية.
2. يرسلون على ست دفعات من 10,000 مع محدِّد معدل عند 60 رسالة في الثانية، مما يترك مجالًا للردود.
3. تُظهر إحدى الدفعات عدة أخطاء 131056 لعملاء تلقوا أيضًا تحديثًا لطلبهم في الدقيقة نفسها. فيؤخرون تلك الرسائل بضع دقائق.
4. يعيد عامل محاولة الطلبات المقيَّدة بتراجع مشوَّش، ولا تُعاد محاولة أي رسالة بعد أن صار لها معرّف.
5. تخزّن نقطة نهاية webhook الأحداث وتعيد 200، ثم يحدّث عامل الحالات.
6. بعد كل دفعة يتحققون من الإخفاقات وجودة القالب قبل المتابعة.

ما الأخطاء الشائعة؟

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

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

BroadNet مزوّد حلول أعمال رسمي لدى Meta (Business Solution Provider)، وترسل OmniChannels.ai رسائل واتساب عبر واجهة واحدة مع نقاط إرسال جماعي، وحقل delay لتقييد الوتيرة، والجدولة، وحالات التسليم في صيغة webhook موحَّدة واحدة. ويحصل الموزّعون (resellers) على webhooks ورصيد منفصلين لكل حساب فرعي. خطّط لأوقات الذروة مع فريقنا، واقرأ وثائق واتساب API والأخطاء والحدود وصفحة الحملات.