Limites de taux

MailLand applique des limites de taux à plusieurs niveaux pour garantir une utilisation équitable et la stabilité de la plateforme. Les limites varient selon le type de flux (transactionnel vs marketing), la méthode d'authentification et le niveau de forfait.

Limites de requêtes APICopier le lien de la section

Limites basées sur l'IPCopier le lien de la section

Chaque requête est soumise à une limitation de taux basée sur l'IP, appliquée avant l'authentification. Ces limites protègent contre les abus et les attaques DDoS.

La connexion utilisateur (non admin) n'est pas régie par cette fenêtre IP : voir Limitation de taux de connexion ci-dessous pour le verrouillage de 5 tentatives/15 minutes qui s'y applique.

Limitation de taux de connexionCopier le lien de la section

Les tentatives de connexion échouées sont suivies par combinaison IP + email :

Après 5 tentatives de connexion échouées en 15 minutes, la paire IP + email est verrouillée pendant 15 minutes. Une connexion réussie réinitialise le compteur.

Authentification par clé APICopier le lien de la section

Les tentatives d'authentification par clé API échouées sont suivies en deux dimensions :

Si l'une des dimensions dépasse son seuil, l'authentification est temporairement bloquée.

Limites d'envoi d'emailsCopier le lien de la section

Les limites d'envoi d'emails sont appliquées par espace de travail et varient selon le type de flux. Les emails transactionnels (reçus, réinitialisations de mot de passe) bénéficient de limites plus élevées que les emails marketing (newsletters, campagnes). La limite par minute est la valeur qui provient réellement de votre forfait (voir Résumé de la politique) ; les limites par seconde et par heure en sont dérivées, et ne sont pas définies indépendamment ; seules les limites par jour et par mois utilisent des valeurs par défaut fixes de la plateforme.

Flux transactionnelCopier le lien de la section

Requêtes à plusieurs destinataires. Chaque destinataire compte dans chaque fenêtre. Une requête transactionnelle (5 destinataires au plus) dont le nombre de destinataires dépasse votre limite par seconde est tout de même acceptée si aucune autre requête n'a été acceptée dans cette seconde ; toute autre requête dans la même seconde reçoit 429 avec Retry-After: 1. Par exemple, avec un forfait de 60 par minute (1 par seconde), une requête vers 3 destinataires est acceptée et une autre requête dans cette seconde est refusée jusqu'à la seconde suivante. Les limites par minute, heure, jour et mois, le préchauffage et votre quota mensuel comptent toujours les 3 destinataires. SMTP applique la même règle à chaque message, en comptant ses adresses RCPT TO uniques.

Flux marketingCopier le lien de la section

Priorité des fluxCopier le lien de la section

Les emails transactionnels ont une priorité plus élevée (priorité 1) que les emails marketing (priorité 2). Lorsque le système est sous charge, les emails transactionnels sont traités en premier.

Opérations par lotCopier le lien de la section

Les opérations d'envoi par lot (par ex. POST /v1/transactional/send-batch) sont réservées au marketing et ignorent les vérifications de taux par seconde comme tout envoi marketing, mais restent soumises aux limites par minute, par heure, par jour et par mois.

Limites d'envoi de l'espace de travailCopier le lien de la section

Le niveau de vérification ne définit pas de plafond de volume : il détermine quelles fonctionnalités sont disponibles. Votre volume d'envoi quotidien/mensuel provient de votre forfait (voir Résumé de la politique), pas de votre niveau de vérification.

Les limites de l'espace de travail sont vérifiées avant les limites de taux des flux. Vous pouvez consulter vos limites et votre utilisation actuelles sur la page Facturation, alimentée par GET /v1/account/subscription/policy-summary.

Préchauffage IPCopier le lien de la section

Le préchauffage dépend de la famille de forfait, ce n'est pas un calendrier fixe. Les forfaits Free suivent 6 paliers de 5 jours chacun (50 → 100 → 250 → 500 → 750 → 1 000/jour) sur 30 jours au total ; les forfaits Pro suivent 500 → 1 000 → 2 500 → 5 000 → 10 000 → 25 000/jour sur 14 jours ; les forfaits Max n'ont pas de préchauffage. Consultez le calendrier de préchauffage de votre forfait sur la page Facturation ci-dessus.

En-têtes de limitation de tauxCopier le lien de la section

La plupart des réponses API incluent :

Un 429 basé sur l'IP ajoute en plus :

Gestion des réponses 429Copier le lien de la section

Lorsque vous recevez une réponse 429 Too Many Requests, le corps contient des détails sur la limite dépassée :

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

Pour les limites de taux d'envoi d'emails :

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

Le texte du message ci-dessus est un exemple : il est généré à partir du motif de décision du moteur de politique et n'est pas une chaîne littérale garantie. Faites correspondre sur code, et non sur message.

Stratégie de nouvelle tentativeCopier le lien de la section

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

Bonnes pratiquesCopier le lien de la section

Surveillez votre utilisation. Vérifiez l'en-tête X-RateLimit-Remaining de manière proactive pour limiter les requêtes avant d'atteindre les limites.

Utilisez le backoff exponentiel. Lors d'une nouvelle tentative après un 429, respectez toujours l'en-tête Retry-After. S'il n'est pas présent, utilisez un backoff exponentiel commençant à 1 seconde.

Préférez les endpoints par lot. Pour les envois à haut volume (marketing), utilisez POST /v1/transactional/send-batch au lieu d'appeler POST /v1/transactional/send en boucle. Les endpoints par lot évitent les vérifications par seconde, comme tout envoi marketing, et sont plus efficaces.

Séparez transactionnel et marketing. Utilisez des identifiants API distincts pour les emails transactionnels et marketing. Cela garantit que l'envoi marketing n'impacte jamais la livraison transactionnelle.

Répartissez l'envoi dans le temps. Pour les grandes campagnes, MailLand régule automatiquement le rythme de livraison. Pour les envois en masse via l'API, répartissez les requêtes uniformément plutôt que d'envoyer par rafales.

Limites de réinitialisation de mot de passeCopier le lien de la section

Les requêtes de réinitialisation de mot de passe ont des limites de taux distinctes :

Prochaines étapesCopier le lien de la section

• Codes d'erreur : référence complète des codes d'erreur
• Clés API : créer et gérer les identifiants API
• Facturation : consulter votre utilisation et vos limites actuelles