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 sections suivantes pour connaître les limites de débit API par défaut des différents types de requêtes. Ces limites par défaut peuvent être augmentées sur demande. Contactez votre gestionnaire du succès des clients pour plus d’informations.

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

Type de requête Limite de débit API par défaut
/users/track Requêtes : Les limites de débit varient en fonction de votre contrat. Pour les clients dont la tarification inclut des points de donnée, Braze applique une limite de rafale de 3 000 requêtes par trois secondes. Pour tous les autres clients, les limites sont configurées selon les termes de votre contrat. Contactez le support Braze ou votre gestionnaire du succès des clients pour toute question sur vos limites.

Regroupement : Jusqu’à 75 objets au total combinés entre attributes, events et purchases par requête API. Les clients bénéficiant d’anciennes limites de débit peuvent inclure jusqu’à 75 objets par tableau indépendamment. Pour plus d’informations, consultez Regroupement des requêtes User Track.

Limites pour les utilisateurs actifs mensuels CY 24-25, MAU universels, MAU web et MAU mobiles : Consultez Limites des utilisateurs actifs mensuels CY 24-25.
/users/export/ids Si vous avez été intégré le 22 août 2024 ou après : 250 requêtes par minute.

Si vous avez été intégré avant le 22 août 2024 : 2 500 requêtes par minute.
/users/delete
/users/alias/new
/users/alias/update
/users/identify
/users/merge		 20 000 requêtes par minute, partagées entre les endpoints.
/users/external_id/rename 1 000 requêtes par minute.
/users/external_id/remove 1 000 requêtes par minute.
/events/list 1 000 requêtes par heure, partagées avec l’endpoint /purchases/product_list.
/purchases/product_list 1 000 requêtes par heure, partagées avec l’endpoint /events/list.
/campaigns/data_series 50 000 requêtes par minute.
/messages/send
/campaigns/trigger/send
/canvas/trigger/send
/campaigns/trigger/schedule/create
/canvas/trigger/schedule/create		 Pour les appels de diffusion (ciblant largement des Segments, des filtres ou une audience connectée), 250 requêtes par minute pour toutes les audiences, et 10 requêtes par minute par audience unique (la première limite atteinte s’applique).

Sinon, lorsque vous ciblez des destinataires individuels, la requête est incluse dans la limite de débit partagée de 250 000 requêtes par heure.
/sends/id/create 100 requêtes par jour.
/subscription/status/set 5 000 requêtes par minute.
/preference_center/v1/{preferenceCenterExternalId}/url/{userId}
/preference_center/v1/list
/preference_center/v1/{preferenceCenterExternalId}		 1 000 requêtes par minute.
/preference_center/v1
/preference_center/v1/{preferenceCenterExternalId}		 10 requêtes par minute.
/catalogs/{catalog_name}
/catalogs
/catalogs		 50 requêtes par minute partagées entre les endpoints.
/catalogs/{catalog_name}/items
/catalogs/{catalog_name}/items
/catalogs/{catalog_name}/items		 16 000 requêtes par minute partagées entre les endpoints.
/catalogs/{catalog_name}/items/{item_id}
/catalogs/{catalog_name}/items/{item_id}
/catalogs/{catalog_name}/items
/catalogs/{catalog_name}/items/{item_id}
/catalogs/{catalog_name}/items/{item_id}		 50 requêtes par minute partagées entre les endpoints.
/catalogs/{catalog_name}/fields/{field_name}
/catalogs/{catalog_name}/fields
/catalogs/{catalog_name}/selections/{selection_name}
/catalogs/{catalog_name}/selections		 50 requêtes par minute partagées entre les endpoints.
/scim/v2/Users/{id}
/scim/v2/Users?filter={[email protected]}
/scim/v2/Users/{id}
/scim/v2/Users/{id}}
/scim/v2/Users/		 5 000 requêtes par jour, par entreprise, partagées entre les endpoints.
/cdi/integrations 50 requêtes par minute.
/cdi/integrations/{integration_id}/sync 20 requêtes par minute.
/cdi/integrations/{integration_id}/job_sync_status 100 requêtes par minute.
/media_library/create 100 requêtes par heure.
/media_library/replace_file 100 requêtes par heure.

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

Les requêtes suivantes ont une limite de débit de 250 000 requêtes par heure, partagée entre elles.

Qu’est-ce qui constitue une même audience unique ?

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

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 Campaign ou le Canvas déclenché (le campaign_id ou le canvas_id dans votre requête API, si spécifié)
  • L’audience ciblée (les Segments ou filtres, ou pour les Campaigns API, le segment_id dans votre requête API)
  • Les filtres d’audience connectée (l’objet audience dans votre requête API, si spécifié)

Chaque combinaison unique de ces attributs compte comme une audience distincte, de sorte que la limite de débit supplémentaire pour chaque audience unique s’applique à chaque combinaison de manière indépendante.

Regroupement des requêtes API

Les API de Braze sont conçues pour prendre en charge le regroupement (batching). Grâce au regroupement, Braze peut ingérer autant de données que possible en un seul appel API, ce qui vous évite de devoir effectuer un grand nombre d’appels. Il est plus efficace pour Braze de traiter les données par lots que de les traiter appel par appel. Par exemple, le traitement de 1 000 appels API regroupés nécessite moins de ressources que le traitement de 75 000 appels individuels. Le regroupement est extrêmement important pour toute application susceptible de nécessiter plus de 75 000 appels par heure.

Regroupement des requêtes pour l’endpoint de création et de mise à jour des utilisateurs

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

Limites de débit héritées

Pour les clients soumis aux limites de débit héritées, chaque tableau (attributes, events et purchases) peut contenir jusqu’à 75 objets de manière indépendante, pour un maximum combiné pouvant atteindre 225 objets par requête.

Pour plus d’informations 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

Regroupement des requêtes vers les endpoints de communication

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

  • Jusqu’à 50 external_ids spécifiques, chacun avec des paramètres de message individuels
  • Un Segment de n’importe quelle taille créé dans le tableau de bord de Braze, spécifié par son segment_id
  • Des utilisateurs correspondant à des filtres d’audience supplémentaires de n’importe quelle taille, définis dans la requête en tant qu’objet d’audience connectée

Exemple de requête groupée

L’exemple suivant utilise external_id pour effectuer un seul appel API pour l’e-mail et le 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 la réponse :

Nom de l’en-tête Description
X-RateLimit-Limit Le nombre maximum de requêtes que vous pouvez effectuer dans un intervalle donné (votre limite de débit).
X-RateLimit-Remaining Le nombre de requêtes restantes dans la fenêtre de limite de débit actuelle.
X-RateLimit-Reset L’heure à laquelle la fenêtre de limite de débit actuelle est réinitialisée, en secondes epoch UTC.

Ces informations sont volontairement incluses dans l’en-tête de la réponse à la requête API plutôt que dans le tableau de bord de Braze. Cela permet à votre système de mieux réagir en temps réel lorsque vous interagissez avec notre API. Par exemple, si la valeur de X-RateLimit-Remaining descend en dessous d’un certain seuil, vous pourriez vouloir ralentir l’envoi pour vous assurer que tous les e-mails transactionnels sont bien envoyés. Ou, si elle atteint zéro, vous pourriez vouloir suspendre tous les envois jusqu’à ce que le délai spécifié dans X-RateLimit-Reset soit écoulé.

Si vous avez des questions sur les limites de l’API, contactez votre gestionnaire du succès des clients 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 à l’API Braze. Des problèmes surviennent lorsque certains endpoints dépendent du traitement réussi d’autres endpoints, et si les appels sont effectués trop tôt, cela peut générer des erreurs. Par exemple, si vous attribuez un alias à des utilisateurs via notre endpoint /user/alias/new, puis que vous utilisez cet alias pour envoyer un événement personnalisé via notre endpoint /users/track, combien de temps devez-vous attendre ?

Dans des conditions normales, le temps nécessaire pour atteindre la cohérence éventuelle de nos données est de 10 à 100 ms (1/10 de seconde). Cependant, dans certains cas, cette cohérence peut prendre plus de temps. C’est pourquoi nous vous recommandons de prévoir un délai de 5 minutes entre les appels successifs afin de minimiser la probabilité d’erreur.

Limites de taille du payload

Les requêtes de l’API Braze sont soumises à des limites de taille du payload, distinctes des limites de débit. La plupart des endpoints acceptent des corps de requête allant jusqu’à 4 Mo. Lorsqu’une requête dépasse la limite applicable, Braze peut la rejeter avec une erreur HTTP 413 Request Entity Too Large ou HTTP 400 Bad Request, selon l’endpoint.

L’endpoint /users/track/bulk a une limite de payload de 2 Mo et renvoie une erreur HTTP 400 lorsque le corps de la requête dépasse cette limite. Pour les limites et la gestion des erreurs propres à chaque endpoint, consultez Endpoints de données utilisateur.

Réinitialisation de la limite 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 pourriez effectuer 50 000 requêtes entre 22h00 et 22h59, puis 250 000 requêtes supplémentaires entre 23h00 et 23h59, car le compteur se réinitialise au début de chaque heure.
New Stuff!