Rate Limiting (limitation de débit)

Le rate limiting restreint le nombre de requêtes API qu'un client peut effectuer dans une fenêtre de temps donnée. Il protège l'infrastructure de l'API contre la surcharge, garantit un usage équitable entre tous les clients et prévient les abus ou les boucles incontrôlées accidentelles.

Qu'est-ce que le rate limiting ?

Le rate limiting (limitation de débit) est un mécanisme de contrôle du trafic qui plafonne le nombre de requêtes API qu'un même client (identifié par sa clé API ou son adresse IP) peut effectuer dans une fenêtre de temps définie. Par exemple, une limite de 100 requêtes par minute signifie que la 101e requête dans cette minute est rejetée avec un statut HTTP 429 (Too Many Requests). Le client doit attendre la réinitialisation de la fenêtre avant d'envoyer de nouvelles requêtes.

Le rate limiting opère à plusieurs niveaux : par endpoint (l'envoi de messages peut avoir des limites plus strictes que la lecture de contacts), par compte (total des requêtes sur toutes les clés) et parfois par canal (WhatsApp impose ses propres limites, distinctes de la couche API). Comprendre ces niveaux vous aide à concevoir des applications qui respectent ces limites de façon fiable.

Pourquoi le rate limiting est-il important ?

Sans rate limiting, un seul script défectueux pourrait inonder l'API de millions de requêtes et dégrader les performances pour tout le monde. Les limites de débit remplissent trois fonctions : protection de l'infrastructure – elles évitent la surcharge des serveurs et maintiennent des temps de réponse constants pour tous les utilisateurs. Usage équitable – elles garantissent qu'aucun client ne monopolise les ressources partagées. Prévention des abus – elles empêchent les bots de spam et les clés API compromises de causer des dommages à grande échelle.

Pour les développeurs, le rate limiting agit aussi comme un filet de sécurité. Un bug dans une boucle de réessai pourrait envoyer des milliers de messages en double – les limites de débit l'interceptent avant que cela ne devienne un problème coûteux. Elles vous incitent à écrire un code robuste, avec une gestion d'erreurs appropriée, des stratégies de backoff et une gestion de file d'attente.

Exemple concret

Imaginez que vous développez une fonctionnalité de campagne qui envoie des messages WhatsApp à 10 000 contacts. Sans conscience des limites, votre code pourrait tenter de déclencher les 10 000 requêtes simultanément. L'API en rejetterait la plupart avec des erreurs 429, votre campagne échouerait partiellement et vous gaspilleriez des crédits en réessais.

La bonne approche : consultez les en-têtes de réponse pour les informations de limitation. SendSeven renvoie des en-têtes comme X-RateLimit-Limit (requêtes max), X-RateLimit-Remaining (requêtes restantes) et X-RateLimit-Reset (réinitialisation de la fenêtre). Utilisez-les pour cadencer vos requêtes. Implémentez un backoff exponentiel : si vous recevez un 429, attendez 1 seconde, puis 2, puis 4 – n'envoyez pas immédiatement de nouvelles requêtes à l'API.

Architecture basée sur une file d'attente : pour les envois à fort volume, utilisez une file de messages (Redis, RabbitMQ ou une simple file en mémoire). Placez les 10 000 destinataires dans la file, puis traitez-les à un rythme inférieur à la limite. Cette approche est résiliente, mesurable et évite les appels API gaspillés. La fonctionnalité de campagne de SendSeven (Reach) gère cela automatiquement.

Le rate limiting chez SendSeven

SendSeven applique les limites de débit par espace de travail, et non par clé API ; les endpoints de connexion et d'authentification sont comptés par adresse IP. Chaque limite porte sur une fenêtre glissante de 60 secondes, et votre intégration partage ce quota avec le tableau de bord. Les limites sont identiques dans toutes les formules. Chaque réponse contient les en-têtes X-RateLimit-Limit, X-RateLimit-Remaining et X-RateLimit-Reset, afin que votre application sache toujours où elle en est. En cas de dépassement, l'API renvoie une réponse 429 avec un en-tête Retry-After indiquant le nombre de secondes à attendre.

Pour les envois en masse, nous recommandons la fonctionnalité intégrée Reach (Campagnes) de SendSeven plutôt que des appels API individuels. Les campagnes sont traitées côté serveur : vous définissez la vitesse d'envoi et la taille des lots, et pour WhatsApp vous pouvez répartir un gros envoi sur plusieurs jours afin de protéger un nouveau numéro. Vous n'avez pas à gérer les limites de débit vous-même.

Les valeurs actuelles figurent dans la documentation API sur docs.sendseven.com. Bonne pratique : surveillez X-RateLimit-Remaining, ralentissez avant d'atteindre zéro et placez les requêtes dans une file d'attente côté client pour qu'une erreur 429 n'atteigne jamais vos utilisateurs.