Skip to content

Limites de débit

L’infrastructure API de Braze est conçue pour gérer des volumes élevés de données sur l’ensemble de notre base de clients. C’est pourquoi nous appliquons des limites de débit à l’API par espace de travail.

Une limite de débit correspond au nombre de requêtes que l’API peut recevoir sur une période donnée. De nombreux incidents de déni de service liés à la charge dans les grands systèmes sont involontaires — causés par des erreurs dans les logiciels ou les configurations — et non par des attaques malveillantes. Les limites de débit garantissent que de telles erreurs ne privent pas nos clients des ressources de l’API de Braze. Si trop de requêtes sont envoyées dans un délai donné, vous risquez de recevoir des réponses d’erreur avec un code d’état 429, indiquant que la limite de débit a été atteinte.

Limites de débit par type de requête

Consultez les informations ci-dessous pour connaître les limites de débit par défaut de l’API selon les différents types de requêtes. Ces limites par défaut peuvent être augmentées sur demande. Contactez votre Customer Success Manager pour plus d’informations.

Requêtes avec différentes limites de débit

Requêtes avec limites de débit partagées

Les requêtes suivantes partagent une limite de débit commune de 250 000 requêtes par heure.

Qu’est-ce qui est considéré comme la même audience unique ?

Cela s’applique aux trois endpoints suivants : /messages/send, /campaigns/trigger/send et /canvas/trigger/send.

Pour ces endpoints, les requêtes de diffusion sont considérées comme ciblant la même audience unique lorsque tous les éléments suivants correspondent :

  • La campagne ou le canvas déclenché (le campaign_id ou canvas_id dans votre requête API, si spécifié)
  • L’audience ciblée (les segments ou filtres, ou pour les campagnes API, le segment_id dans votre requête API)
  • Les filtres d’audience connectés (l’objet audience dans votre requête API, s’il est spécifié)

Chaque combinaison unique de ces attributs est considérée comme une audience distincte. La limite de débit supplémentaire pour chaque audience unique s’applique donc indépendamment à chaque combinaison.

Traitement des requêtes API par lot

Les API de Braze sont conçues pour prendre en charge le traitement par lot. Grâce à cette fonctionnalité, Braze peut ingérer un maximum de données en un seul appel API, ce qui vous évite de multiplier les appels. Il est bien plus efficace pour Braze de traiter les données par lots que de les traiter appel par appel. Par exemple, la gestion de 1 000 appels API par lots nécessite moins de ressources que la gestion de 75 000 appels individuels. Le traitement par lot est essentiel pour toute application susceptible de nécessiter plus de 75 000 appels par heure.

Mise en lot des requêtes pour l’endpoint de suivi des utilisateurs

Chaque requête /users/track peut contenir jusqu’à 75 objets au total, combinés entre attributes, events et purchases. Chaque objet peut mettre à jour un utilisateur. Un même profil utilisateur peut être mis à jour par plusieurs objets.

Anciennes limites de débit

Pour les clients bénéficiant d’anciennes limites de débit, chaque tableau (attributes, events et purchases) peut contenir jusqu’à 75 objets de manière indépendante, pour un maximum combiné de 225 objets par requête.

Pour en savoir plus sur les limites de débit de /users/track, consultez POST : Créer et mettre à jour des utilisateurs.

Les requêtes adressées à cet endpoint commencent généralement à être traitées dans l’ordre suivant :

  1. Attributs
  2. Événements
  3. Achats

Mise en lot des requêtes aux endpoints de messagerie

Une seule requête adressée aux endpoints de messagerie peut cibler l’un des éléments suivants :

  • Jusqu’à 50 external_ids spécifiques, chacun avec des paramètres de message individuels
  • Un segment de toute taille créé dans le tableau de bord de Braze, spécifié par son segment_id
  • Les utilisateurs correspondant à des filtres d’audience supplémentaires de toute taille, définis dans la requête sous forme d’objet d’audience connectée

Exemple de requête par lot

L’exemple suivant utilise external_id pour effectuer un seul appel API couvrant les e-mails et les SMS.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

curl --location --request POST 'https://rest.iad-01.braze.com/v2/subscription/status/set' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR-REST-API-KEY' \
--data-raw '{
  "subscription_groups":[
    {
      "subscription_group_id":"subscription_group_identifier",
      "subscription_state":"subscribed",
      "external_ids":["example-user","[email protected]"]
    },
    {
      "subscription_group_id":"subscription_group_identifier",
      "subscription_state":"subscribed",
      "external_ids":["example-user","[email protected]"]
    }
  ]
}

Surveiller vos limites de débit

Chaque requête API envoyée à Braze renvoie les informations suivantes dans les en-têtes de réponse :

Ces informations sont volontairement incluses dans l’en-tête de la réponse API plutôt que dans le tableau de bord de Braze. Votre système peut ainsi réagir en temps réel lors de ses interactions avec notre API. Par exemple, si la valeur de X-RateLimit-Remaining passe en dessous d’un certain seuil, vous pouvez ralentir les envois pour vous assurer que tous les e-mails transactionnels sont bien transmis. Si elle atteint zéro, vous pouvez suspendre tous les envois jusqu’à ce que le délai indiqué dans X-RateLimit-Reset soit écoulé.

Si vous avez des questions sur les limites de l’API, contactez votre Customer Success Manager ou ouvrez un ticket d’assistance.

Délai optimal entre les endpoints

Comprendre le délai optimal entre les endpoints est essentiel lorsque vous effectuez des appels consécutifs vers l’API de Braze. Des problèmes surviennent lorsqu’un endpoint dépend du traitement réussi d’un autre endpoint : s’il est appelé trop tôt, cela peut provoquer des erreurs. Par exemple, si vous attribuez un alias à un utilisateur via l’endpoint /user/alias/new, puis que vous utilisez cet alias pour envoyer un événement personnalisé via l’endpoint /users/track, combien de temps devez-vous attendre ?

Dans des conditions normales, la cohérence à terme de nos données s’établit en 10 à 100 ms (1/10 de seconde). Toutefois, dans certains cas, ce délai peut être plus long. Nous vous recommandons donc de prévoir un délai de 5 minutes entre les appels successifs afin de minimiser la probabilité d’erreur.

Réinitialisation des limites de débit

Les limites de débit se réinitialisent à chaque heure pleine, et non sur une fenêtre glissante. Par exemple, si la limite est de 250 000 requêtes par heure, vous pouvez effectuer 50 000 requêtes entre 22 h 00 et 22 h 59, puis 250 000 requêtes supplémentaires entre 23 h 00 et 23 h 59, car le compteur se réinitialise au début de chaque heure.
Github   Modifier cette page sur GitHub
New Stuff!