Skip to main content

​
رفضات 10DLC وإعادة التحقق ودورة ما بعد الموافقة

ينتهي دليل تسجيل 10DLC عند “ابدأ الإرسال.” يغطي هذا الدليل ما يحدث بعد ذلك — رفض مع رمز غامض، أو درجة تحقق تسقّ فطتك، أو حملة معتمدة لم يعد سقفها اليومي يطابق حجمك. كل ما هنا ضابط على تسجيلاتك أنت؛ وقرارات شركات الاتصالات والسجل تبقى لهم.

​
من أين يأتي الرفض

الرفض أحد أمرين، والفرق يحدد كل ما تفعله لاحقًا:
  • رفضات السجل (TCR وشركات CSP التي تُمثّله) تشتعل أثناء أو بعد مراجعة التسجيل — الإيداع نفسه مرفوض. تظهر هذه على هيئة سجلات حالة FAILED / REJECTED مع سلسلة rejectionReason، في ثلاثة أماكن: معالج Settings > Compliance > 10DLC، وإشعار لوحة التحكم عند الانتقال النهائي، وحقل rejectionReason على GET /api/v1/compliance/10dlc/campaigns/:id/status.
  • رفضات شركات الاتصالات (AT&T، T-Mobile) يمكن أن تصل بعد موافقة TCR، داخل خريطة mnoStatuses لكل شركة اتصالات — تدقيق عميل مباشر على العلامة، أو شركة اتصالات واحدة تخالف قرار مستوى CSP.
تُصدر بعض الرموز قبل أن يقرر TCR شيئًا: DUPLICATE-BRAND وفشل lowercase-usecase إشارات وقت الإيداع، لا نتائج مرحلة المراجعة. الرفض الذي يُظهره المعالج مباشرة بعد الإيداع عادة ينتمي إلى هذه الفئة. إلى رفضين يقفلان السجل بدل طلب التعديل — BRAND-DCA-FAIL وDUPLICATE-BRAND يُعيدان بطاقة إصلاح مع resubmit_allowed: false، أي أن معرّف العلامة محروق والإصلاح تسجيل جديد، لا تعديل.

​
حوّل رمز الرفض الخام إلى بطاقة إصلاح

يُعيد TCR وشركات CSP رموزًا مثل 30883 و40016 و EIN-MISMATCH مع سبب نصي حر من سطر واحد ولا إصلاح لكل حقل. جدول الترميذ على استكشاف الأعطال: حملة 10DLC مرفوضة يغطي الحالات الشائعة ثابتة؛ نقطة نهاية المُفكِّك تطبق الكتالوج نفسه على أي رمز — بما فيه الصيغ والرموز التي لا يعددها الجدول. POST /api/v1/compliance/10dlc/decode-rejection مرِّر code الخام، مع rejectionReason النص الحر إن كان لديك — النص الحر يوضّح الرموز التي تعطي أكثر من سبب:
الاستجابة (200 OK):
اقرأ أربعة حقول من البطاقة:
  • fix — الخطوة الإصلاحية ذات أعلى احتمال، بنفس الأسلوب الذي يستخدمه بانر رفض المعالج.
  • resubmit_allowed — الحكم الذي يحدد نداءك التالي. true: عدّل الحمولة وأعد إيداع نفس العلامة أو الحملة. false: السجل مُقفل؛ ابدأ تسجيلًا جديدًا.
  • category — دلّة ثابتة (eligibility، content، identity، throughput، format، dca، unknown) للتجميع في واجهتك.
  • field — خطوة المعالج التي ينطبق عليها الإصلاح (campaign.sample_message، brand.ein، …)، ليُرجَع المشغل إلى النموذج الصحيح بصيغة رابط عميق.
المُفكِّك محرك قواعد خالص — لا يخزّن شيئًا ولا ينشئ شيئًا، ويوحّد الرمز نيابة عنك: TCR-30883 وTwilio Error 30883 و ein_mismatch تصل كلها إلى إدخالاتها الكنونية. يُعيد الرمز غير المعروف بطاقة من فئة unknown ينقل شعبة fix إلى امتثال Devotel، حتى لا تُظهِر الواجهة التي تُعرض البطاقة لوحة فارغة.
شغّل المُفكِّك قبل تشغيل المعالجة. حين تُعيد بطاقة fix الصياغة لعينة رسالة أو وصف، شغّل الحمولة المُصحَّحة عبر مدقق ما قبل الإرسال قبل إعادة الإيداع — فهو يلتقط الرفض الثانوي الذي الإصلاح كثيرًا ما يقدمه.

​
مثال مُعمَل: ‘تعارض حالة الاستخدام’

استكشاف حالة حملة يُعيد:
تُسمّي سلسلة السبب السبب ولها لا رمز TCR. المُفكِّك يعمل بواحد منهما أو الآخر، فمرِّر ما لديك — النص الحر وحده:
الاستجابة — بطاقة 30898:
resubmit_allowed: true يقول عدّل وأعد الإيداع. الآن أعد إيداع الحملة المُصحَّحة على نفس العلامة — نفس النداء كالآيداع الأول، مُعادًا مثلًا بمثل:
توقع 1–5 أيام عمل مثل الإيداع الأول؛ استكشف نقطة الحالة أو راقب إشعار لوحة التحكم.

​
مثال ثانٍ مُعمَل: ‘عينة SHAFT’

هذه نفس الحلقة مع بطاقة من فئة المحتوى. سبب مثل "Sample 2 flagged: SHAFT sample" يفك إلى 30883 — انتهاك محتوى — مع resubmit_allowed: true وfield: "campaign.sample_message". أعد صياغة العينة المُبلغ عنها لتوصف الفئة المُعلنة وأسقط الصيغة المحظورة، ثم أعد إيداع الحملة مثلًا بمثل. النقطة في الحلقة: نداء مُفكِّك واحد، إيداع مُصحَّح واحد، ولا شيء من ذلك يعتمد على أي صيغة أرجعها TCR بالضبط.

​
إعادة التحقق مقابل إعادة الإيداع

إصلاحات المحتوى المرفوض تعني إعادة الإيداع. ودرجة التحقق المنخفضة عائق مختلف — لا كمية من التصحيح على حمولة حملة يصلحها، وهي تسقف كل حملة على العلامة، لا الواحدة تحت المراجعة فقط. الدرجة تحدد الحد، فالعلاج إعادة تحقق لا إعادة إيداع. POST /api/v1/compliance/10dlc/brands/:id/revet
الاستجابة (200 OK):
يسمي provider أي مسجّل يحمل العلامة؛ وstatus هي حالة العلامة المحدثة بمجرد بدء إعادة التحقق. قبل إعادة التحقق، أكمله سجل العلامة — EIN، واسم قانوني مطابق لسجلات IRS، وموقع، وبريد دعم على نطاقك — إعادة التحقق يعيد قياس نفس المعلومات، والسجل بلا تغيير يُعيد درجة بلا تغيير. يُحدِّد المُسجِّل بتقييد إعادة التحقق (مرة فور التسجيل، ثم مرة كل ثلاثة أشهر تقريبًا)، فنداء مقيد المعدل يُعيد 422 مع نص “انتظر حتى” من المُسجِّل — اقرأه، لا تعد المحاولة في حلقة.

​
تخطيط السعة: ما تمنحه الدرجة

نقطتان تحللان درجة التحقق إلى الحدود التي تعمل بها. GET /api/v1/compliance/10dlc/brands/:id/vetting يعيد النتيجة الخام:
vettingScore: null يعني أن EVP لا يزال يُعالج — اعرض “Pending” لا 0. GET /api/v1/compliance/10dlc/brands/:id/throughput يستمد الحدود المخصصة من شركات الاتصالات من تلك الدرجة:
الاستجابة (200 OK):
  • att.class — AT&T تخصص فئة سعة لكل حملة، D→C→B→A (15 → 75 → 240 → 600 رسائل في الدقيقة)، عند أرضيات درجة trust 0/25/50/75.
  • tmobile.tier — T-Mobile تخصص فئة سقف يومي لكل علامة (2k / 10k / 40k / 200k / غير محدودة) تغطي كل حملة ورقم على العلامة.
  • entity_type (باراميتر استعلام اختياري) — علامات المالك الفردي مسقوفة عند فئة 2k والفئة D في AT&T بغض النظر عن الدرجة؛ مرِّر نوع الكيان المسجل حتى يرى الاشتقاق الحالة الخاصة.
  • sent_today (باراميتر استعلام اختيارية) — أجزاء الرسائل التي جعلت في نافذة التداول 24 ساعة الحالية. عند تمريره، consumption تُبلغ عن الفراغ قبل منطقة تصفية الصامت: ok دون 80% من السقف، warning عند 80%، critical عند 95%، exceeded عند 100%.
الباراميترين اختياريتان؛ consumption يبقى null حتى تُزوّد sent_today.

​
إعادة تحقق، أو القبول بالفئة؟

استخدم حدودَي warning / critical كإشارة. حين ينقضي حجمك ضمن حركة العرض باستمرار في النطاق التحذيري، خطّط إعادة تحقق — فهي مقيدة المعدل، فلا تُحرقها إلا على تغيير مسار حقيقي. حين السقف هو السقف اليومي لا الفئة، يكون الضابط لكل علامة: إسناد أرقام أكثر إلى الحملة لا يرفعه، وترقية SOLE_PROPRIETOR إلى سجل علامة كامل يرفعه — ذلك تغيير نوع كيان، لا إعادة تحقق.

​
إعادة الإيداع، إعادة التحقق: ما كلفت كل منهما

يدفع TCR رسوم تحقق جديدة لكل إعادة إيداع وإعادة تحقق (عادة بضعة دولارات أمريكية)، ويعامل كل إعادة إيداع كمراجعة جديدة — توقيت مستقل عن محاولاتك السابقة.

​
انظر أيضًا