Aller au contenu
Docs

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.

Mis à jour le 1 oct. 2026

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 :

JSON
{
  "error": "Rate limit exceeded",
  "message": "Too many requests. Maximum 2 messages per second allowed.",
  "limit": 2,
  "current": 2,
  "retry_after": 1
}
JSON
{
  "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

  1. Patientez, puis réessayez. Respectez retry-after (ou retry_after dans le corps) avant d’envoyer de nouveau. Une requête 429 n’est ni envoyée ni débitée : la relancer est donc sans risque. Ajoutez un en-tête Idempotency-Key pour vous protéger des relances au niveau du réseau.

  2. 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 un 429 au lieu de réessayer en boucle serrée.

  3. Étalez les gros envois. Si vous atteignez la limite quotidienne, programmez le reste avec scheduled_at après minuit UTC, ou utilisez une campagne pour les e-mails marketing.

  4. 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.

  5. 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.

Cette page vous a-t-elle été utile ?

Merci pour votre retour.

Merci, nous lisons chaque message.