محدودیت‌های نرخ

MailLand محدودیت‌های نرخ را در چندین سطح اعمال می‌کند تا استفاده منصفانه و پایداری پلتفرم را تضمین نماید. محدودیت‌ها بر اساس نوع جریان (تراکنشی در مقابل بازاریابی)، روش احراز هویت و سطح پلن متفاوت هستند.

محدودیت‌های درخواست APIکپی پیوند بخش

محدودیت‌های مبتنی بر IPکپی پیوند بخش

هر درخواست مشمول محدودیت نرخ مبتنی بر IP است که پیش از احراز هویت اعمال می‌شود. این محدودیت‌ها در برابر سوءاستفاده و حملات DDoS محافظت می‌کنند.

ورود کاربر (غیر ادمین) مشمول این پنجرهٔ مبتنی بر IP نیست؛ برای قفل‌شدنِ پس از ۵ تلاش در ۱۵ دقیقه که برای آن اعمال می‌شود، به بخش محدودیت نرخ ورود در ادامه مراجعه کنید.

محدودیت نرخ ورودکپی پیوند بخش

تلاش‌های ناموفق ورود به ازای هر ترکیب IP + ایمیل پیگیری می‌شوند:

پس از 5 تلاش ناموفق ورود در بازه 15 دقیقه، جفت IP + ایمیل به مدت 15 دقیقه قفل می‌شود. ورود موفق شمارنده را بازنشانی می‌کند.

احراز هویت API Keyکپی پیوند بخش

تلاش‌های ناموفق احراز هویت API key در دو بُعد پیگیری می‌شوند:

اگر هر یک از بُعدها از آستانه خود فراتر رود، احراز هویت به‌طور موقت مسدود می‌شود.

محدودیت‌های ارسال ایمیلکپی پیوند بخش

محدودیت‌های ارسال ایمیل به ازای هر فضای کاری اعمال می‌شوند و بر اساس نوع جریان متفاوت هستند. ایمیل‌های تراکنشی (رسیدها، بازنشانی رمز عبور) محدودیت‌های بالاتری نسبت به ایمیل‌های بازاریابی (خبرنامه‌ها، کمپین‌ها) دارند. مقدار در دقیقه همان مقداری است که واقعاً از پلن شما می‌آید (به خلاصهٔ سیاست‌ها مراجعه کنید)؛ مقدارهای در ثانیه و در ساعت از آن مشتق می‌شوند و به‌طور مستقل تنظیم نمی‌شوند، و تنها محدودیت‌های روزانه و ماهانه از مقدارهای پیش‌فرض ثابت پلتفرم استفاده می‌کنند.

جریان تراکنشیکپی پیوند بخش

درخواست‌های چندگیرنده‌ای. هر گیرنده در همهٔ پنجره‌های زمانی شمرده می‌شود. یک درخواست تراکنشی (حداکثر ۵ گیرنده) که تعداد گیرندگانش از سهمیهٔ در ثانیهٔ شما بیشتر است، اگر در همان ثانیه درخواست دیگری پذیرفته نشده باشد، باز هم پذیرفته می‌شود؛ درخواست دیگر در همان ثانیه پاسخ 429 با Retry-After: 1 می‌گیرد. برای مثال، در پلنی با ۶۰ در دقیقه (۱ در ثانیه)، یک درخواست به ۳ گیرنده پذیرفته می‌شود و درخواست دیگر در همان ثانیه تا ثانیهٔ بعد رد می‌شود. محدودیت‌های دقیقه، ساعت، روز و ماه، گرم‌سازی و سهمیهٔ ماهانهٔ شما همچنان هر ۳ گیرنده را می‌شمارند. SMTP همین قاعده را برای هر پیام اعمال می‌کند و نشانی‌های یکتای RCPT TO آن را می‌شمارد.

جریان بازاریابیکپی پیوند بخش

اولویت جریانکپی پیوند بخش

ایمیل‌های تراکنشی اولویت بالاتری (اولویت ۱) نسبت به ایمیل‌های بازاریابی (اولویت ۲) دارند. هنگامی که سیستم تحت بار است، ایمیل‌های تراکنشی ابتدا پردازش می‌شوند.

عملیات دسته‌ایکپی پیوند بخش

عملیات ارسال دسته‌ای (مانند POST /v1/transactional/send-batch) مخصوص بازاریابی هستند و درست مانند هر ارسال بازاریابی دیگری، بررسی‌های نرخ بر ثانیه را دور می‌زنند؛ اما همچنان مشمول محدودیت‌های بر دقیقه، بر ساعت، بر روز و بر ماه هستند.

محدودیت‌های ارسال فضای کاریکپی پیوند بخش

سطح تأیید سقفی برای حجم ارسال تعیین نمی‌کند؛ بلکه مشخص می‌کند کدام قابلیت‌ها در دسترس هستند. حجم ارسال روزانه/ماهانهٔ شما از پلن شما می‌آید (به خلاصهٔ سیاست‌ها مراجعه کنید)، نه از سطح تأیید شما.

محدودیت‌های فضای کاری پیش از محدودیت‌های نرخ جریان بررسی می‌شوند. می‌توانید محدودیت‌ها و مصرف فعلی خود را از صفحهٔ صورتحساب مشاهده کنید که از ‏GET /v1/account/subscription/policy-summary تغذیه می‌شود.

گرم‌سازی IPکپی پیوند بخش

گرم‌سازی بر اساس خانوادهٔ پلن تعیین می‌شود، نه یک برنامهٔ زمانی ثابت. پلن‌های Free شش مرحلهٔ پنج‌روزه را طی می‌کنند (۵۰ ← ۱۰۰ ← ۲۵۰ ← ۵۰۰ ← ۷۵۰ ← ۱٬۰۰۰ در روز) که در مجموع ۳۰ روز طول می‌کشد؛ پلن‌های Pro این مسیر را طی می‌کنند: ۵۰۰ ← ۱٬۰۰۰ ← ۲٬۵۰۰ ← ۵٬۰۰۰ ← ۱۰٬۰۰۰ ← ۲۵٬۰۰۰ در روز، طی ۱۴ روز؛ پلن‌های 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 را رعایت کنید. در صورت عدم وجود، از تأخیر نمایی با شروع از 1 ثانیه استفاده کنید.

از endpointهای دسته‌ای استفاده کنید. برای ارسال بازاریابی با حجم بالا، به جای فراخوانی POST /v1/transactional/send در یک حلقه، از POST /v1/transactional/send-batch استفاده کنید. endpointهای دسته‌ای، درست مانند هر ارسال بازاریابی، بررسی‌های بر ثانیه را دور می‌زنند و کارآمدتر هستند.

تراکنشی و بازاریابی را جدا کنید. از اعتبارنامه‌های API جداگانه برای ایمیل‌های تراکنشی و بازاریابی استفاده کنید. این تضمین می‌کند که ارسال بازاریابی هرگز بر تحویل تراکنشی تأثیر نمی‌گذارد.

ارسال را در طول زمان توزیع کنید. برای کمپین‌های بزرگ، MailLand به‌طور خودکار تحویل را آهنگ‌بندی می‌کند. برای ارسال‌های انبوه مبتنی بر API، درخواست‌ها را به‌صورت یکنواخت توزیع کنید به جای ارسال دسته‌ای.

محدودیت‌های بازنشانی رمز عبورکپی پیوند بخش

درخواست‌های بازنشانی رمز عبور محدودیت‌های نرخ جداگانه‌ای دارند:

مراحل بعدیکپی پیوند بخش

• کدهای خطا: مرجع کامل کدهای خطا
• API Keyها: ایجاد و مدیریت اعتبارنامه‌های API
• صورتحساب: مشاهده مصرف و محدودیت‌های فعلی