Ratenbegrenzungen

MailLand erzwingt Ratenbegrenzungen auf mehreren Ebenen, um eine faire Nutzung und Plattformstabilität zu gewährleisten. Die Limits variieren je nach Stream-Typ (Transactional vs. Marketing), Authentifizierungsmethode und Planstufe.

API-AnfragelimitsLink zum Abschnitt kopieren

IP-basierte LimitsLink zum Abschnitt kopieren

Jede Anfrage unterliegt einer IP-basierten Ratenbegrenzung, die vor der Authentifizierung angewendet wird. Diese Limits schützen vor Missbrauch und DDoS-Angriffen.

Die (nicht-administrative) Benutzeranmeldung unterliegt nicht diesem IP-Fenster: siehe Anmelde-Ratenbegrenzung unten für die Sperre nach 5 Versuchen/15 Minuten, die dafür gilt.

Anmelde-RatenbegrenzungLink zum Abschnitt kopieren

Fehlgeschlagene Anmeldeversuche werden pro IP + E-Mail-Kombination erfasst:

Nach 5 fehlgeschlagenen Anmeldeversuchen innerhalb von 15 Minuten wird die IP + E-Mail-Kombination für 15 Minuten gesperrt. Eine erfolgreiche Anmeldung setzt den Zähler zurück.

API-Schlüssel-AuthentifizierungLink zum Abschnitt kopieren

Fehlgeschlagene API-Schlüssel-Authentifizierungsversuche werden in zwei Dimensionen erfasst:

Wenn eine der beiden Dimensionen ihre Schwelle überschreitet, wird die Authentifizierung vorübergehend blockiert.

E-Mail-VersandlimitsLink zum Abschnitt kopieren

E-Mail-Versandlimits werden pro Workspace durchgesetzt und variieren je nach Stream-Typ. Transaktionale E-Mails (Quittungen, Passwortzurücksetzungen) erhalten höhere Limits als Marketing-E-Mails (Newsletter, Kampagnen). Das Pro-Minute-Limit ist der Wert, der tatsächlich aus Ihrem Plan stammt (siehe Richtlinienübersicht); Pro-Sekunde und Pro-Stunde werden davon abgeleitet und nicht unabhängig festgelegt, und nur Tag/Monat verwenden feste Plattform-Standardwerte.

Transactional-StreamLink zum Abschnitt kopieren

Anfragen mit mehreren Empfängern. Jeder Empfänger zählt in jedem Zeitfenster. Eine transaktionale Anfrage (höchstens 5 Empfänger), deren Empfängerzahl über Ihrem Pro-Sekunde-Kontingent liegt, wird trotzdem angenommen, wenn in dieser Sekunde keine andere Anfrage angenommen wurde; jede weitere Anfrage in derselben Sekunde erhält 429 mit Retry-After: 1. Beispiel: Bei einem Plan mit 60 pro Minute (1 pro Sekunde) wird eine Anfrage an 3 Empfänger angenommen und eine weitere Anfrage in dieser Sekunde bis zur nächsten Sekunde abgelehnt. Die Limits pro Minute, Stunde, Tag und Monat, das Warm-up und Ihr Monatskontingent zählen weiterhin alle 3 Empfänger. SMTP wendet dieselbe Regel auf jede Nachricht an und zählt deren eindeutige RCPT TO-Adressen.

Marketing-StreamLink zum Abschnitt kopieren

Stream-PrioritätLink zum Abschnitt kopieren

Transaktionale E-Mails haben eine höhere Priorität (Priorität 1) als Marketing-E-Mails (Priorität 2). Bei Systemlast werden transaktionale E-Mails zuerst verarbeitet.

Batch-OperationenLink zum Abschnitt kopieren

Batch-Versandoperationen (z. B. POST /v1/transactional/send-batch) sind Marketing-exklusiv und überspringen die Pro-Sekunde-Ratenprüfung genauso wie jeder Marketing-Versand: unterliegen aber weiterhin den Pro-Minute-, Pro-Stunde-, Pro-Tag- und Pro-Monat-Limits.

Workspace-VersandlimitsLink zum Abschnitt kopieren

Die Verifizierungsstufe legt keine Volumenobergrenze fest: sie steuert, welche Funktionen verfügbar sind. Ihr tägliches/monatliches Versandvolumen stammt aus Ihrem Plan (siehe Richtlinienübersicht), nicht aus Ihrer Verifizierungsstufe.

Workspace-Limits werden vor den Stream-Ratenbegrenzungen geprüft. Sie können Ihre aktuellen Limits und die Nutzung auf der Seite Abrechnung einsehen, die von GET /v1/account/subscription/policy-summary gespeist wird.

IP-AufwärmungLink zum Abschnitt kopieren

Die Aufwärmung erfolgt pro Plan-Familie, nicht nach einem festen Zeitplan. Free-Pläne durchlaufen 6 Stufen zu je 5 Tagen (50 → 100 → 250 → 500 → 750 → 1.000/Tag) über insgesamt 30 Tage; Pro-Pläne durchlaufen 500 → 1.000 → 2.500 → 5.000 → 10.000 → 25.000/Tag über 14 Tage; Max-Pläne haben keine Aufwärmung. Den Aufwärmplan Ihres Plans finden Sie über die oben genannte Seite Abrechnung.

Ratenbegrenzungs-HeaderLink zum Abschnitt kopieren

Die meisten API-Antworten enthalten:

Ein IP-basiertes 429 fügt zusätzlich hinzu:

Umgang mit 429-AntwortenLink zum Abschnitt kopieren

Wenn Sie eine 429 Too Many Requests-Antwort erhalten, enthält der Body Details darüber, welches Limit überschritten wurde:

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

Für E-Mail-Versand-Ratenbegrenzungen:

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

Der obige message-Text ist ein Beispiel: er wird aus dem Entscheidungsgrund der Richtlinien-Engine generiert und ist keine garantierte wörtliche Zeichenkette. Prüfen Sie auf code, nicht auf message.

Retry-StrategieLink zum Abschnitt kopieren

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

Best PracticesLink zum Abschnitt kopieren

Nutzung überwachen. Prüfen Sie den X-RateLimit-Remaining-Header proaktiv, um Anfragen zu drosseln, bevor Sie Limits erreichen.

Exponentielles Backoff verwenden. Wenn Sie nach einem 429-Fehler erneut versuchen, respektieren Sie immer den Retry-After-Header. Falls dieser nicht vorhanden ist, verwenden Sie exponentielles Backoff ab 1 Sekunde.

Batch-Endpoints bevorzugen. Für Massen-Versand (Marketing) verwenden Sie POST /v1/transactional/send-batch anstatt POST /v1/transactional/send in einer Schleife aufzurufen. Batch-Endpoints überspringen Pro-Sekunde-Prüfungen, wie jeder Marketing-Versand, und sind effizienter.

Transactional und Marketing trennen. Verwenden Sie separate API-Anmeldedaten für transaktionale und Marketing-E-Mails. So wird sichergestellt, dass Marketing-Versand niemals die transaktionale Zustellung beeinträchtigt.

Versand über die Zeit verteilen. Für große Kampagnen regelt MailLand die Zustellung automatisch. Für API-gesteuerte Massen-Versendungen verteilen Sie Anfragen gleichmäßig, anstatt sie stoßweise zu senden.

Passwort-ZurücksetzungslimitsLink zum Abschnitt kopieren

Anfragen zum Zurücksetzen des Passworts haben separate Ratenbegrenzungen:

Nächste SchritteLink zum Abschnitt kopieren

• Fehlercodes: Vollständige Fehlercode-Referenz
• API-Schlüssel: API-Anmeldedaten erstellen und verwalten
• Abrechnung: Aktuelle Nutzung und Limits einsehen