Hız Sınırları

MailLand, adil kullanım ve platform kararlılığını sağlamak için birden fazla düzeyde hız sınırlaması uygular. Sınırlar akış türüne (işlemsel ve pazarlama), kimlik doğrulama yöntemine ve plan kademesine göre değişir.

API İstek SınırlarıBölüm bağlantısını kopyala

IP Tabanlı SınırlarBölüm bağlantısını kopyala

Her istek, kimlik doğrulamasından önce uygulanan IP tabanlı hız sınırlamasına tabidir. Bu sınırlar, kötüye kullanım ve DDoS saldırılarına karşı koruma sağlar.

(Yönetici olmayan) kullanıcı girişi bu IP penceresine tabi değildir: buna uygulanan 5 deneme/15 dakikalık kilitleme için aşağıdaki Giriş Hız Sınırlaması bölümüne bakın.

Giriş Hız SınırlamasıBölüm bağlantısını kopyala

Başarısız giriş denemeleri IP + e-posta kombinasyonu bazında izlenir:

15 dakika içinde 5 başarısız giriş denemesinin ardından, IP + e-posta çifti 15 dakika süreyle kilitlenir. Başarılı giriş sayacı sıfırlar.

API Key Kimlik DoğrulamaBölüm bağlantısını kopyala

Başarısız API key kimlik doğrulama denemeleri iki boyutta izlenir:

Her iki boyuttan biri eşiğini aşarsa, kimlik doğrulama geçici olarak engellenir.

E-posta Gönderim SınırlarıBölüm bağlantısını kopyala

E-posta gönderim sınırları çalışma alanı başına uygulanır ve akış türüne göre değişir. İşlemsel e-postalar (faturalar, şifre sıfırlama) pazarlama e-postalarından (bültenler, kampanyalar) daha yüksek sınırlara sahiptir. Dakika başına değer, gerçekten planınızdan gelen değerdir (Politika Özeti'ne bakın); saniye başına ve saat başına değerler bundan türetilir, bağımsız olarak ayarlanmaz; yalnızca gün/ay için sabit platform varsayılanları kullanılır.

İşlemsel AkışBölüm bağlantısını kopyala

Birden çok alıcılı istekler. Her alıcı her zaman penceresinde sayılır. Alıcı sayısı saniye başına sınırınızı aşan işlemsel bir istek (en fazla 5 alıcı), o saniyede başka bir istek kabul edilmemişse yine de kabul edilir; aynı saniyedeki diğer istekler Retry-After: 1 ile 429 alır. Örneğin dakikada 60 (saniyede 1) olan bir planda 3 alıcılı bir istek kabul edilir, o saniyedeki başka bir istek ise bir sonraki saniyeye kadar reddedilir. Dakika, saat, gün ve ay sınırları, ısınma ve aylık kotanız 3 alıcının tamamını saymaya devam eder. SMTP aynı kuralı her mesaja uygular ve mesajın benzersiz RCPT TO adreslerini sayar.

Pazarlama AkışıBölüm bağlantısını kopyala

Akış ÖnceliğiBölüm bağlantısını kopyala

İşlemsel e-postalar, pazarlama e-postalarından (öncelik 2) daha yüksek önceliğe (öncelik 1) sahiptir. Sistem yük altındayken işlemsel e-postalar öncelikli olarak işlenir.

Toplu İşlemlerBölüm bağlantısını kopyala

Toplu gönderim işlemleri (ör. POST /v1/transactional/send-batch) yalnızca pazarlama içindir ve her pazarlama gönderimi gibi saniye başına hız kontrollerini atlar, ancak dakika başına, saat başına, gün başına ve ay başına sınırlara tabi olmaya devam eder.

Çalışma Alanı Gönderim SınırlarıBölüm bağlantısını kopyala

Doğrulama düzeyi bir hacim sınırı belirlemez, hangi özelliklerin kullanılabilir olduğunu belirler. Günlük/aylık gönderim hacminiz planınızdan gelir (Politika Özeti'ne bakın), doğrulama düzeyinizden değil.

Çalışma alanı sınırları, akış hız sınırlarından önce kontrol edilir. Mevcut sınırlarınızı ve kullanımınızı, GET /v1/account/subscription/policy-summary ile beslenen Faturalandırma sayfasında görüntüleyebilirsiniz.

IP IsındırmaBölüm bağlantısını kopyala

Isındırma plan ailesine göre değişir, sabit bir takvim değildir. Free planlar, her biri 5 gün süren 6 aşamadan geçer (50 → 100 → 250 → 500 → 750 → 1.000/gün), toplamda 30 gün; Pro planlar 14 gün boyunca 500 → 1.000 → 2.500 → 5.000 → 10.000 → 25.000/gün ilerler; Max planlarda ısındırma yoktur. Planınızın ısındırma takvimini yukarıdaki Faturalandırma sayfasından görebilirsiniz.

Hız Sınırı BaşlıklarıBölüm bağlantısını kopyala

Çoğu API yanıtı şunları içerir:

IP tabanlı bir 429 ayrıca şunu ekler:

429 Yanıtlarını YönetmeBölüm bağlantısını kopyala

429 Too Many Requests yanıtı aldığınızda, gövde hangi sınırın aşıldığına dair detaylar içerir:

{
  "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"
  }
}

E-posta gönderim hız sınırları için:

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

Yukarıdaki message metni bir örnektir: politika motorunun karar gerekçesinden üretilir ve garantili sabit bir dize değildir. message yerine code üzerinden eşleştirin.

Yeniden Deneme StratejisiBölüm bağlantısını kopyala

#!/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

En İyi UygulamalarBölüm bağlantısını kopyala

Kullanımınızı izleyin. Sınırlara ulaşmadan önce istekleri kısmak için X-RateLimit-Remaining başlığını proaktif olarak kontrol edin.

Üstel geri çekilme kullanın. 429 yanıtından sonra yeniden denerken her zaman Retry-After başlığına uyun. Başlık mevcut değilse, 1 saniyeden başlayarak üstel geri çekilme uygulayın.

Toplu endpoint'leri tercih edin. Yüksek hacimli (pazarlama) gönderimler için POST /v1/transactional/send işlemini döngüde çağırmak yerine POST /v1/transactional/send-batch kullanın. Toplu endpoint'ler her pazarlama gönderimi gibi saniye başına kontrolleri atlar ve daha verimlidir.

İşlemsel ve pazarlamayı ayırın. İşlemsel ve pazarlama e-postaları için ayrı API kimlik bilgileri kullanın. Bu, pazarlama gönderimlerinin işlemsel teslimatı hiçbir zaman etkilememesini sağlar.

Gönderimi zamana yayın. Büyük kampanyalar için MailLand teslimatı otomatik olarak hızlandırır. API tabanlı toplu gönderimler için istekleri ani yükler halinde göndermek yerine eşit şekilde dağıtın.

Şifre Sıfırlama SınırlarıBölüm bağlantısını kopyala

Şifre sıfırlama isteklerinin ayrı hız sınırları vardır:

Sonraki AdımlarBölüm bağlantısını kopyala

• Hata Kodları: kapsamlı hata kodu referansı
• API Key'ler: API kimlik bilgilerini oluşturun ve yönetin
• Faturalandırma: mevcut kullanımınızı ve sınırlarınızı görüntüleyin