حدود المعدل

يفرض MailLand حدود المعدل على مستويات متعددة لضمان الاستخدام العادل واستقرار المنصة. تختلف الحدود حسب نوع التدفق (تعاملي مقابل تسويقي) وطريقة المصادقة ومستوى الخطة.

حدود طلبات APIنسخ رابط القسم

الحدود المستندة إلى IPنسخ رابط القسم

يخضع كل طلب لتحديد المعدل المستند إلى IP، ويُطبّق قبل المصادقة. تحمي هذه الحدود من إساءة الاستخدام وهجمات DDoS.

تسجيل دخول المستخدم (غير المسؤول) لا يخضع لهذه النافذة المستندة إلى IP: راجع تحديد معدل تسجيل الدخول أدناه للاطلاع على الحظر بعد 5 محاولات/15 دقيقة الذي يُطبَّق عليه.

تحديد معدل تسجيل الدخولنسخ رابط القسم

تُتتبّع محاولات تسجيل الدخول الفاشلة لكل مزيج من IP وعنوان البريد الإلكتروني:

بعد 5 محاولات تسجيل دخول فاشلة خلال 15 دقيقة، يُحظر مزيج IP وعنوان البريد الإلكتروني لمدة 15 دقيقة. يؤدي تسجيل الدخول الناجح إلى إعادة تعيين العدّاد.

مصادقة API Keyنسخ رابط القسم

تُتتبّع محاولات مصادقة API key الفاشلة في بُعدين:

إذا تجاوز أي بُعد الحد المسموح به، تُحظر المصادقة مؤقتًا.

حدود إرسال البريد الإلكترونينسخ رابط القسم

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

التدفق التعاملينسخ رابط القسم

الطلبات متعددة المستلمين. يُحتسب كل مستلم في كل نافذة زمنية. يُقبل الطلب التعاملي (5 مستلمين كحد أقصى) الذي يتجاوز عدد مستلميه حدّك في الثانية إذا لم يُقبل أي طلب آخر في تلك الثانية؛ ويتلقى أي طلب آخر في الثانية نفسها 429 مع Retry-After: 1. على سبيل المثال، في خطة بمعدل 60 في الدقيقة (1 في الثانية)، يُقبل طلب واحد إلى 3 مستلمين، ويُرفض طلب آخر في تلك الثانية حتى الثانية التالية. تظل حدود الدقيقة والساعة واليوم والشهر والإحماء وحصتك الشهرية تحتسب المستلمين الثلاثة جميعًا. يطبّق SMTP القاعدة نفسها على كل رسالة، باحتساب عناوين RCPT TO الفريدة فيها.

التدفق التسويقينسخ رابط القسم

أولوية التدفقنسخ رابط القسم

تتمتع رسائل البريد التعاملية بأولوية أعلى (الأولوية 1) مقارنة برسائل البريد التسويقية (الأولوية 2). عندما يكون النظام تحت ضغط، تُعالج رسائل البريد التعاملية أولًا.

العمليات المجمّعةنسخ رابط القسم

عمليات الإرسال المجمّع (مثل POST /v1/transactional/send-batch) مخصصة للتسويق فقط، وتتخطى فحوصات المعدل لكل ثانية تمامًا كأي إرسال تسويقي: لكنها تظل خاضعة لحدود الدقيقة والساعة واليوم والشهر.

حدود إرسال مساحة العملنسخ رابط القسم

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

تُفحص حدود مساحة العمل قبل حدود معدل التدفق. يمكنك عرض حدودك واستخدامك الحاليين من صفحة الفوترة، المُغذّاة من ‏GET /v1/account/subscription/policy-summary.

إحماء IPنسخ رابط القسم

يعتمد الإحماء على عائلة الخطة، وليس على جدول زمني ثابت. تمر خطط Free بست مراحل مدة كل منها 5 أيام (50 ← 100 ← 250 ← 500 ← 750 ← 1,000 يوميًا) على مدى 30 يومًا إجمالًا؛ وتمر خطط Pro بالتسلسل 500 ← 1,000 ← 2,500 ← 5,000 ← 10,000 ← 25,000 يوميًا على مدى 14 يومًا؛ ولا يوجد إحماء لخطط Max. راجع جدول الإحماء الخاص بخطتك من صفحة الفوترة أعلاه.

رؤوس تحديد المعدلنسخ رابط القسم

تتضمن معظم استجابات API:

يضيف 429 المستند إلى IP ما يلي:

التعامل مع استجابات 429نسخ رابط القسم

عند تلقي استجابة 429 Too Many Requests، يحتوي النص على تفاصيل حول الحد الذي تم تجاوزه:

{
  "code": "IP_RATE_LIMIT_EXCEEDED",
  "message": "Too many requests from this IP. Retry after 45 seconds.",
  "details": {
    "limit": 300,
    "current": 301,
    "retryAfter": 45,
    "resetAt": "2026-02-18T12:35:00Z"
  }
}

لحدود معدل إرسال البريد الإلكتروني:

{
  "code": "RATE_LIMIT_EXCEEDED",
  "message": "Per-minute rate limit exceeded (transactional)"
}

نص message أعلاه مثال فقط: يُولَّد من سبب قرار محرك السياسات وليس نصًا حرفيًا مضمونًا. طابق على code، لا على message.

استراتيجية إعادة المحاولةنسخ رابط القسم

#!/bin/bash
MAX_RETRIES=3
ATTEMPT=0

while [ $ATTEMPT -le $MAX_RETRIES ]; do
  RESPONSE=$(curl -s -D - -o /tmp/body -w "%{http_code}" -X POST https://api.mail.land/v1/transactional/send \
    -H "X-API-Key: ml_pet_Ab3Kx9mN2pQ7rT4wL8yD..." \
    -H "Content-Type: application/json" \
    -d '{ "from": {"email": "[email protected]"}, "to": [{"email": "[email protected]"}], "subject": "Hello", "htmlContent": "<p>Hi</p>" }')

  HTTP_CODE=$(echo "$RESPONSE" | tail -n1)

  if [ "$HTTP_CODE" -ne 429 ]; then
    cat /tmp/body
    exit 0
  fi

  # Read the Retry-After header, not the response body - not every 429 has a `details` block.
  RETRY_AFTER=$(echo "$RESPONSE" | grep -i '^Retry-After:' | tr -d '\r' | cut -d' ' -f2)
  RETRY_AFTER=${RETRY_AFTER:-60}
  ATTEMPT=$((ATTEMPT + 1))
  echo "Rate limited. Retrying in ${RETRY_AFTER}s (attempt ${ATTEMPT}/${MAX_RETRIES})"
  sleep "$RETRY_AFTER"
done

echo "Max retries exceeded"
exit 1

أفضل الممارساتنسخ رابط القسم

راقب استخدامك. تحقق من رأس X-RateLimit-Remaining بشكل استباقي لتقييد الطلبات قبل الوصول إلى الحدود.

استخدم التراجع الأسي. عند إعادة المحاولة بعد استجابة 429، احترم دائمًا رأس Retry-After. إذا لم يكن موجودًا، استخدم التراجع الأسي بدءًا من ثانية واحدة.

استخدم نقاط النهاية المجمّعة. للإرسال التسويقي بكميات كبيرة، استخدم POST /v1/transactional/send-batch بدلًا من استدعاء POST /v1/transactional/send في حلقة. تتخطى نقاط النهاية المجمّعة فحوصات المعدل لكل ثانية، كأي إرسال تسويقي، وهي أكثر كفاءة.

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

وزّع الإرسال على مدار الوقت. للحملات الكبيرة، يقوم MailLand تلقائيًا بتنظيم وتيرة التسليم. بالنسبة لعمليات الإرسال المجمّع عبر API، وزّع الطلبات بالتساوي بدلًا من الإرسال على شكل دفعات مفاجئة.

حدود إعادة تعيين كلمة المرورنسخ رابط القسم

تمتلك طلبات إعادة تعيين كلمة المرور حدود معدل منفصلة:

الخطوات التاليةنسخ رابط القسم

• رموز الأخطاء: مرجع شامل لرموز الأخطاء
• مفاتيح API: إنشاء وإدارة بيانات اعتماد API
• الفوترة: عرض استخدامك وحدودك الحالية