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 suivantes pour connaître les limites de débit API par défaut selon les différents types de requêtes. Ces limites par défaut peuvent être augmentées sur demande. Contactez votre gestionnaire de la satisfaction client 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 conformément aux conditions de votre contrat. Contactez le support Braze ou votre gestionnaire de la satisfaction client 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 soumis aux anciennes limites de débit peuvent inclure jusqu’à 75 objets par tableau de manière indépendante. 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 mobile : consultez Limites des utilisateurs actifs mensuels CY 24-25.
/users/export/ids Si vous avez intégré Braze à partir du 22 août 2024 : 250 requêtes par minute.

Si vous avez intégré Braze 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 toutes audiences confondues, et 10 requêtes par minute par audience unique (la première limite atteinte s’applique).

Dans le cas contraire, lorsque des destinataires individuels sont ciblés, 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/		 20 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 la 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 canvas_id dans votre requête API, s’il est spécifié)
  • L’audience ciblée (les Segments ou les 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, s’il est spécifié)

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

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 d’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 seul profil utilisateur peut être mis à jour par plusieurs objets.

Anciennes limites de débit

Pour les clients soumis aux anciennes limites de débit, chaque tableau (attributes, events et purchases) peut contenir jusqu’à 75 objets indépendamment, pour un maximum combiné de 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 envoyé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 messaging

Une seule requête vers les endpoints de messaging 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 regroupé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]"]
    }
  ]
}

Surveillance de vos limites de débit

Chaque requête API envoyée à Braze renvoie les informations suivantes dans les en-têtes de 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 actuelle de limitation du débit.
X-RateLimit-Reset L’heure à laquelle la fenêtre actuelle de limitation du débit se réinitialise, en secondes epoch UTC.

Ces informations sont intentionnellement 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 pouvez ralentir les envois pour vous assurer que tous les e-mails transactionnels sont bien délivrés. Ou, si elle atteint zéro, vous pouvez 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 de la satisfaction client 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 s’ils sont appelés trop tôt, des erreurs peuvent se produire. 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 à 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. Nous recommandons donc de prévoir un délai de 5 minutes entre les appels consécutifs 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 jusqu’à 4 Mo. Lorsqu’une requête dépasse la limite applicable, Braze peut la rejeter avec un code 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 un code HTTP 400 lorsque le corps de la requête dépasse cette limite. Pour les limites spécifiques à chaque endpoint et la gestion des erreurs, 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 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.
New Stuff!