Dépannage
Pourquoi l’API renvoie-t-elle l’erreur 429 Rate limit exceeded ?
Gérez les réponses 429 de l’API Emailit. Découvrez les limites d’envoi par seconde et quotidiennes, les en-têtes de limite de débit et comment demander des limites plus élevées.
Cet article explique pourquoi POST /v2/emails renvoie 429 et comment cadencer vos envois pour l’éviter. Les mêmes limites s’appliquent au SMTP, où elles se traduisent par des réponses 452.
Symptômes
L’API répond 429 avec l’un de ces corps :
{
"error": "Rate limit exceeded",
"message": "Too many requests. Maximum 2 messages per second allowed.",
"limit": 2,
"current": 2,
"retry_after": 1
}{
"error": "Daily limit exceeded",
"message": "Daily sending limit of 5000 messages has been reached.",
"limit": 5000,
"current": 5000,
"retry_after": 41200
}Via SMTP, la commande MAIL FROM échoue avec 452 4.4.5 Messages per second limit exceeded ou 452 4.5.3 Daily message limit exceeded.
Cause
Chaque espace de travail a deux limites d’envoi, communes à toutes les clés API et au SMTP :
- Par seconde. Les nouveaux espaces de travail démarrent à 2 e-mails par seconde.
- Par jour. Les nouveaux espaces de travail démarrent à 5 000 e-mails par jour. Le compteur est réinitialisé à minuit UTC.
L’API compte chaque destinataire comme un e-mail : une requête avec trois adresses réparties entre to, cc et bcc en consomme donc trois. Les rafales issues de processus parallèles, les boucles de relance sans intervalle exponentiel et les tâches par lots qui démarrent en même temps en sont les causes habituelles.
Chaque réponse d’envoi inclut des en-têtes qui indiquent où vous en êtes :
| En-tête | Signification |
|---|---|
ratelimit-limit / ratelimit-remaining |
Limite par seconde et ce qu’il reste pour la seconde en cours |
ratelimit-daily-limit / ratelimit-daily-remaining |
Limite quotidienne et ce qu’il reste pour aujourd’hui |
ratelimit-daily-reset |
Secondes restantes jusqu’à minuit UTC |
retry-after |
Secondes à attendre avant de réessayer (uniquement sur 429) |
Solution
-
Patientez, puis réessayez. Respectez
retry-after(ouretry_afterdans le corps) avant d’envoyer de nouveau. Une requête429n’est ni envoyée ni débitée : la relancer est donc sans risque. Ajoutez un en-têteIdempotency-Keypour vous protéger des relances au niveau du réseau. -
Cadencez vos envois. Utilisez une file d’attente avec une limite de simultanéité correspondant à
ratelimit-limit, et relancez avec un intervalle exponentiel après un429au lieu de réessayer en boucle serrée. -
Étalez les gros envois. Si vous atteignez la limite quotidienne, programmez le reste avec
scheduled_ataprès minuit UTC, ou utilisez une campagne pour les e-mails marketing. -
Vérifiez vos limites actuelles. La carte Sending Limits de la page Dashboard affiche vos limites par seconde et par jour, ainsi que votre consommation du jour.
-
Demandez des limites plus élevées. Sélectionnez Request Increase sur la carte Sending Limits, puis indiquez les limites dont vous avez besoin, d’où viennent vos destinataires et pourquoi. L’équipe répond généralement sous 24 heures. Sur Pro et Business, les limites augmentent aussi automatiquement tant que votre santé d’envoi reste bonne.
Consultez Limites de débit pour la référence complète et Limites pour tous les quotas par forfait.
Le problème persiste ?
Contactez le support ou posez votre question sur Discord. Indiquez votre volume prévu par jour et par seconde, ainsi qu’un exemple de réponse 429.