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 au niveau de la clé API. Les limites actuelles dépendent de votre formule – les formules supérieures bénéficient d'un débit plus élevé. Toutes les réponses incluent des en-têtes de limitation afin que votre application connaisse toujours son statut. Lorsque vous atteignez une limite, l'API renvoie une réponse 429 claire avec un en-tête Retry-After indiquant le nombre de secondes à attendre.

Pour la messagerie en masse, nous recommandons d'utiliser la fonctionnalité intégrée Reach (Campagnes) de SendSeven plutôt que des appels API individuels. Les campagnes sont traitées côté serveur avec un débit optimisé, un cadencement automatique par canal (respectant les propres limites de WhatsApp) et un rapport de livraison – aucune gestion des limites de débit n'est nécessaire de votre côté.

La documentation complète sur les limites de débit, y compris les limites par endpoint et des exemples de code pour implémenter des stratégies de backoff, est disponible sur docs.sendseven.com.