Créer et mettre à jour des utilisateurs

Utilisez cet endpoint pour enregistrer des événements personnalisés et des achats, et pour mettre à jour les attributs du profil utilisateur.

Remarque

Chaque attribut personnalisé envoyé dans une requête à /users/track consomme un point de donnée. Pour plus d’informations, consultez Points de donnée.

Braze traite les données transmises par l’API telles quelles. Vous ne devez transmettre que les deltas (données modifiées) afin de minimiser la consommation inutile de points de données.

Besoin de mettre à jour des utilisateurs en masse ?

Utilisez l’endpoint /users/track/bulk pour envoyer des lots plus importants et réduire le volume de requêtes.

Conditions préalables

Pour utiliser cet endpoint, vous aurez besoin d’une clé API avec l’autorisation users.track.

Les clients qui utilisent l’API pour des appels de serveur à serveur devront peut-être ajouter rest.iad-01.braze.com à leur liste d’autorisations s’ils sont derrière un pare-feu.

Limite de débit

Les limites de débit de cet endpoint 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 toutes les trois secondes. Pour tous les autres clients, les limites sont configurées selon les termes de votre contrat. Les limites actuelles de votre compte sont disponibles dans le tableau de bord sous Paramètres > API et identifiants > Tableau de bord d’utilisation de l’API.

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.

Pour les clients ayant acheté le forfait Monthly Active Users CY 24-25, Universal MAU, Web MAU ou Mobile MAU, des limites de débit supplémentaires s’appliquent. Pour plus d’informations, consultez Limites Monthly Active Users CY 24-25.

Pour plus d’informations, consultez Limites de débit de l’API. Contactez votre gestionnaire du succès des clients pour demander une augmentation.

Corps de la requête

1
2

Content-Type: application/json
Authorization: Bearer YOUR_REST_API_KEY

1
2
3
4
5
6

{
  "attributes": (optional, array of attributes object),
  "events": (optional, array of event object),
  "purchases": (optional, array of purchase object),
  "group_id": (optional, string)
}

Paramètres de la requête

Important

Pour chaque composant de la requête listé dans le tableau suivant, vous devez inclure l’un des éléments suivants : external_id, user_alias, braze_id, email ou phone.

Résolution des identifiants

Chaque objet de la requête doit contenir au moins un identifiant. Le tableau suivant décrit comment Braze détermine quel identifiant utiliser pour la recherche du profil utilisateur.

Lorsqu’un identifiant primaire est présent, les valeurs email ou phone dans le même objet de requête sont traitées comme des attributs de profil, et non comme des identifiants pour la recherche d’utilisateur. Par exemple, si une requête inclut à la fois un external_id et un email :

• Braze recherche le profil utilisateur par external_id.
• La valeur email est définie (ou mise à jour) en tant qu’attribut sur le profil résolu.

Important

L’inclusion d’un identifiant primaire qui ne correspond à aucun profil existant peut créer un profil en double, même si les valeurs email ou phone de la même requête correspondent à un profil existant. Pour plus d’informations, consultez Comment éviter la création de profils utilisateurs en double ?.

Exemples de requêtes

Mise à jour d’un profil utilisateur par adresse e-mail

Vous pouvez mettre à jour un profil utilisateur par adresse e-mail en utilisant l’endpoint /users/track.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

curl --location --request POST 'https://rest.iad-01.braze.com/users/track' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_REST_API_KEY' \
--data-raw '{
    "attributes": [
        {
            "email": "[email protected]",
            "string_attribute": "fruit",
            "boolean_attribute_1": true,
            "integer_attribute": 26,
            "array_attribute": [
                "banana",
                "apple"
            ]
        }
    ],
    "events": [
        {
            "email": "[email protected]",
            "app_id": "your_app_identifier",
            "name": "rented_movie",
            "time": "2022-12-06T19:20:45+01:00",
            "properties": {
                "release": {
                    "studio": "FilmStudio",
                    "year": "2022"
                },
                "cast": [
                    {
                        "name": "Actor1"
                    },
                    {
                        "name": "Actor2"
                    }
                ]
            }
        },
        {
            "user_alias": {
                "alias_name": "device123",
                "alias_label": "my_device_identifier"
            },
            "app_id": "your_app_identifier",
            "name": "rented_movie",
            "time": "2013-07-16T19:20:50+01:00"
        }
    ],
    "purchases": [
        {
            "email": "[email protected]",
            "app_id": "your_app_identifier",
            "product_id": "product_name",
            "currency": "USD",
            "price": 12.12,
            "quantity": 6,
            "time": "2017-05-12T18:47:12Z",
            "properties": {
                "color": "red",
                "monogram": "ABC",
                "checkout_duration": 180,
                "size": "Large",
                "brand": "Backpack Locker"
            }
        }
    ]
}'

Mise à jour d’un profil utilisateur par numéro de téléphone

Vous pouvez mettre à jour un profil utilisateur par numéro de téléphone en utilisant l’endpoint /users/track. Cet endpoint ne fonctionne que si vous indiquez un numéro de téléphone valide.

Important

Si vous incluez à la fois email et phone dans une requête, Braze utilise l’e-mail comme identifiant.

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/users/track' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_REST_API_KEY' \
--data-raw '{
    "attributes": [
        {
            "phone": "+15043277269",
            "string_attribute": "fruit",
            "boolean_attribute_1": true,
            "integer_attribute": 25,
            "array_attribute": [
                "banana",
                "apple"
            ]
        }
    ],
}'

Définir les groupes d’abonnement

Cet exemple montre comment créer un utilisateur et définir son groupe d’abonnement dans l’objet attributs de l’utilisateur.

La mise à jour de l’état de l’abonnement avec cet endpoint met à jour l’utilisateur spécifié par son external_id (par exemple User1) et met à jour l’état de l’abonnement de tous les utilisateurs ayant le même e-mail que cet utilisateur (User1).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

curl --location --request POST 'https://rest.iad-01.braze.com/users/track' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_REST_API_KEY' \
--data-raw '{
  "attributes": [
  {
    "external_id": "user_identifier",
    "email": "[email protected]",
    "email_subscribe": "subscribed",
    "subscription_groups": [{
      "subscription_group_id": "subscription_group_identifier_1",
      "subscription_state": "unsubscribed"
      },
      {
        "subscription_group_id": "subscription_group_identifier_2",
        "subscription_state": "subscribed"
        },
        {
          "subscription_group_id": "subscription_group_identifier_3",
          "subscription_state": "subscribed",
          "use_double_opt_in_logic": true
        }
      ]
    }
  ]
}'

Remarque

Pour les groupes d’abonnement SMS, lorsque vous définissez le subscription_state d’un groupe sur subscribed, vous pouvez inclure le paramètre facultatif use_double_opt_in_logic défini sur true dans cet objet de groupe d’abonnement afin de faire entrer l’utilisateur dans le workflow de double opt-in SMS. Si ce paramètre est omis ou défini sur false lorsque subscription_state est subscribed, l’utilisateur est abonné sans passer par le workflow de double opt-in. Ce paramètre n’est pas appliqué lorsque subscription_state est défini sur d’autres valeurs, telles que unsubscribed.

Exemple de requête pour créer un utilisateur alias uniquement

Vous pouvez utiliser l’endpoint /users/track pour créer un utilisateur alias uniquement en attribuant à la clé _update_existing_only la valeur false dans le corps de la requête. Si vous omettez cette valeur, Braze ne crée pas le profil utilisateur alias uniquement. L’utilisation d’un utilisateur alias uniquement garantit l’existence d’un profil avec cet alias. C’est particulièrement utile lors de la création d’une intégration, car cela empêche Braze de créer des profils utilisateurs en double.

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

curl --location --request POST 'https://rest.iad-01.braze.com/users/track' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_REST_API_KEY' \
--data-raw '{
    "attributes": [
        {
            "_update_existing_only": false,
            "user_alias": {
                "alias_name": "example_name",
                "alias_label": "example_label"
            },
            "email": "[email protected]"
        }
    ],
}'

Exemple de requête avec un identifiant de groupe pour le suivi de l’état

Cet exemple met à jour le niveau de fidélité d’un utilisateur et inclut un group_id afin que vous puissiez vérifier quand Braze a terminé le traitement de la requête. Pour vérifier l’état, appelez l’endpoint /users/track/status avec le même group_id. Pour plus d’informations, consultez Suivi de l’état de traitement des requêtes.

1
2
3
4
5
6
7
8
9
10
11
12

curl --location --request POST 'https://rest.iad-01.braze.com/users/track' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR_REST_API_KEY' \
--data-raw '{
    "group_id": "loyalty_backfill_2026-09-23",
    "attributes": [
        {
            "external_id": "user_identifier",
            "loyalty_tier": "gold"
        }
    ]
}'

Réponses

Lorsque vous utilisez l’une des requêtes API mentionnées ci-dessus, vous devriez recevoir l’une des trois réponses générales suivantes : un message de réussite, un message de réussite avec des erreurs non fatales ou un message avec des erreurs fatales.

Message de réussite

Les messages de réussite reçoivent la réponse suivante :

1
2
3
4
5
6

{
  "message": "success",
  "attributes_processed": (optional, integer), if attributes are included in the request, this returns an integer of the number of external_ids with attributes that Braze queued for processing,
  "events_processed": (optional, integer), if events are included in the request, this returns an integer of the number of events that Braze queued for processing,
  "purchases_processed": (optional, integer), if purchases are included in the request, this returns an integer of the number of purchases that Braze queued for processing,
}

Message de réussite avec des erreurs non fatales

Si votre message aboutit mais comporte des erreurs non fatales, telles qu’un objet d’événement non valide parmi une longue liste d’événements, vous recevez la réponse suivante :

1
2
3
4
5
6
7
8

{
  "message": "success",
  "errors": [
    {
      <minor error message>
    }
  ]
}

En cas de réussite, Braze traite quand même toutes les données qui ne sont pas affectées par une erreur dans le tableau errors.

Message avec des erreurs fatales

Si votre message comporte une erreur fatale, vous recevez la réponse suivante :

1
2
3
4
5
6
7
8

{
  "message": <fatal error message>,
  "errors": [
    {
      <fatal error message>
    }
  ]
}

Codes de réponse des erreurs fatales

Pour connaître les codes d’état et les messages d’erreur associés que Braze renvoie si votre requête rencontre une erreur fatale, reportez-vous à la section Erreurs fatales et réponses.

Si vous recevez l’erreur « provided external_id is blacklisted and disallowed », il se peut que votre requête ait inclus un « utilisateur fictif ». Pour plus d’informations, consultez la section Filtrage du spam.

Erreurs spécifiques à l’endpoint

Les erreurs suivantes sont spécifiques à l’endpoint /users/track et sont renvoyées dans le tableau errors de la réponse. Utilisez-les pour résoudre les problèmes liés aux objets individuels d’une requête.

Suivi de l’état de traitement des requêtes

Important

Le suivi de l’état de traitement des requêtes est en bêta. Si vous souhaitez participer à la bêta, contactez votre gestionnaire de compte Braze.

Braze traite les requêtes /users/track de manière asynchrone. Une réponse réussie signifie que Braze a reçu votre requête et l’a mise en file d’attente pour traitement, mais les données peuvent ne pas encore être sur le profil utilisateur. Pour confirmer la fin du traitement, ajoutez un group_id à vos requêtes et vérifiez l’état du groupe avec l’endpoint /users/track/status.

Utilisez le suivi de l’état de traitement des requêtes pour :

• Confirmer que les mises à jour d’attributs ou d’abonnements sont sur un profil avant de déclencher un Canvas ou une Campaign qui en dépend
• Confirmer qu’un remplissage ou une importation est terminé avant d’envoyer des messages aux utilisateurs concernés
• Conserver un enregistrement attestant que les mises à jour hautement prioritaires, telles que les modifications de consentement, ont bien été traitées

Fonctionnement

1. Choisissez un group_id pour un ensemble de requêtes associées. Par exemple, utilisez un group_id pour chaque requête dans un remplissage, ou un group_id unique pour une seule requête que vous souhaitez confirmer.
2. Incluez le group_id au niveau supérieur du corps de chaque requête /users/track. Braze comptabilise chaque requête acceptée dans le groupe.
3. Appelez l’endpoint /users/track/status avec le group_id. Lorsque le status du groupe est completed, Braze a terminé le traitement de toutes les requêtes du groupe.

Si vous envoyez une autre requête avec le même group_id après que le groupe est completed, l’état du groupe repasse à processing jusqu’à ce que Braze ait terminé le traitement de la nouvelle requête.

Braze suit l’état de chaque groupe dans son ensemble. Un groupe est completed lorsque Braze a terminé le traitement de toutes les requêtes du groupe, y compris les requêtes où Braze a rejeté certains objets. Braze liste les objets rejetés dans le tableau errors de chaque réponse /users/track.

Le suivi de l’état n’est disponible que pour l’endpoint /users/track. Braze ne suit pas l’état des requêtes envoyées à l’endpoint /users/track/bulk ou à l’endpoint /users/track/sync.

Exigences relatives à l’identifiant de groupe

Un group_id doit contenir entre 1 et 128 caractères et ne peut inclure que des lettres, des chiffres, des points (.), des tirets bas (_), des tildes (~) et des tirets (-).

Les identifiants de groupe sont limités à un espace de travail. Le même group_id dans deux espaces de travail différents fait référence à deux groupes distincts.

Utilisez un nouveau group_id pour chaque ensemble de requêtes que vous souhaitez suivre. La réutilisation d’un group_id ajoute des requêtes au groupe existant et ne prolonge pas sa période de rétention.

Limites et rétention

Erreurs de suivi de l’état

Braze ne peut pas suivre l’état d’une requête dans certains cas, par exemple lorsque votre espace de travail a atteint son nombre maximal de groupes actifs. Dans ce cas, la réponse /users/track est toujours réussie et Braze traite quand même les attributs, événements et achats de la requête. La réponse inclut une entrée dans le tableau errors décrivant pourquoi Braze ne suit pas la requête :

1
2
3
4
5
6
7
8

{
  "message": "success",
  "errors": [
    {
      "type": "request_status_group_full"
    }
  ]
}

Foire aux questions

Important

N’envoyez pas d’e-mails transactionnels légalement obligatoires aux passerelles SMS, car il y a de fortes chances que ces e-mails ne soient pas délivrés.

Bien que les e-mails envoyés en utilisant un numéro de téléphone et le domaine de passerelle du fournisseur (connu sous le nom de MM3) puissent être reçus sous forme de message SMS (texte), certains de nos fournisseurs d’e-mail ne prennent pas en charge ce comportement. Par exemple, si vous envoyez un e-mail à un numéro de téléphone T-Mobile (tel que « [email protected] »), votre message SMS sera envoyé à la personne qui possède ce numéro de téléphone sur le réseau T-Mobile.

Gardez à l’esprit que même si ces e-mails ne sont pas délivrés à la passerelle SMS, ils seront tout de même comptabilisés dans votre facturation d’e-mails. Pour éviter d’envoyer des e-mails à des passerelles non prises en charge, consultez la liste des noms de domaine des passerelles non prises en charge.

Que se passe-t-il lorsque plusieurs profils avec la même adresse e-mail sont trouvés ?

Si le external_id existe, Braze donne la priorité au profil le plus récemment mis à jour possédant un ID externe. Si le external_id n’existe pas, Braze donne la priorité au profil le plus récemment mis à jour.

Que se passe-t-il si aucun profil n’existe avec l’adresse e-mail ?

Braze crée un profil et un utilisateur e-mail uniquement, et définit le champ e-mail à [email protected], comme indiqué dans l’exemple de requête de mise à jour d’un profil utilisateur par adresse e-mail. Braze ne crée pas d’alias.

Comment utiliser /users/track pour importer des données utilisateur héritées ?

Vous pouvez soumettre des données via l’API de Braze pour un utilisateur qui n’a pas encore utilisé votre application mobile afin de générer un profil utilisateur. Si l’utilisateur utilise ensuite l’application, toutes les informations suivant son identification via le SDK sont fusionnées avec le profil utilisateur existant créé via l’appel API. Tout comportement utilisateur enregistré de manière anonyme par le SDK avant l’identification est perdu lors de la fusion avec le profil utilisateur existant généré par l’API.

L’outil de segmentation inclut ces utilisateurs, qu’ils aient interagi ou non avec l’application. Si vous souhaitez exclure les utilisateurs téléchargés via l’API utilisateur qui n’ont pas encore utilisé l’application, ajoutez le filtre Session Count > 0.

Comment éviter la création de profils utilisateurs en double ?

Des profils en double peuvent apparaître lorsqu’une requête inclut un identifiant primaire (tel que external_id) qui ne correspond à aucun profil existant, accompagné d’une valeur email ou phone qui correspond à un profil existant. Étant donné que les identifiants primaires sont utilisés pour la recherche d’utilisateur, Braze crée un nouveau profil pour le external_id non reconnu au lieu de mettre à jour le profil existant basé uniquement sur l’e-mail ou le téléphone.

Pour éviter les doublons :

• Lorsque vous faites passer des utilisateurs de profils basés uniquement sur l’e-mail ou le téléphone à des profils identifiés, utilisez l’endpoint /users/identify pour attribuer un external_id au profil existant, plutôt que d’envoyer les deux à /users/track.
• Si des doublons existent déjà, fusionnez-les à l’aide de l’endpoint /users/merge.

Comment /users/track gère-t-il les événements en double ?

Chaque objet d’événement du tableau d’événements représente une occurrence unique d’un événement personnalisé par un utilisateur à un moment donné. Chaque événement ingéré dans Braze possède donc son propre ID d’événement, ce qui signifie que les événements « dupliqués » sont traités comme des événements distincts et uniques.

Comment /users/track gère-t-il les attributs personnalisés imbriqués non valides ?

Lorsqu’un attribut personnalisé imbriqué contient des valeurs non valides (telles que des formats d’heure incorrects ou des valeurs nulles), Braze abandonne le traitement de toutes les mises à jour d’attributs personnalisés imbriqués de la requête. Cela s’applique à toutes les structures imbriquées au sein de cet attribut spécifique. Pour garantir un traitement réussi, vérifiez que toutes les valeurs des attributs personnalisés imbriqués sont valides avant l’envoi.

Les requêtes envoyées à /users/track sont-elles garanties d’être traitées dans l’ordre ?

Lorsque vous effectuez plusieurs appels API distincts à /users/track en succession rapide, Braze ne peut pas garantir que les requêtes sont traitées dans l’ordre exact où elles ont été envoyées ou reçues. En effet, Braze utilise un traitement asynchrone pour maximiser la vitesse et la flexibilité.

Par exemple, si vous envoyez plusieurs requêtes de mise à jour pour le même utilisateur en l’espace de quelques secondes — certaines avec des valeurs d’attribut nulles et d’autres avec des valeurs valides — les requêtes contenant des valeurs nulles peuvent être traitées après les requêtes contenant des valeurs valides, même si elles ont été envoyées plus tôt. Cela peut entraîner des valeurs d’attribut qui semblent revenir en arrière ou ne pas refléter la mise à jour la plus récemment envoyée.

Pour éviter les conditions de concurrence lors de la mise à jour des données utilisateur :

• Regroupez les mises à jour dans une seule requête : incluez toutes les mises à jour d’attributs pour un utilisateur dans un seul appel API plutôt que d’effectuer des appels consécutifs séparés.
• Ajoutez des délais entre les requêtes : si vous devez effectuer des appels séparés pour le même utilisateur, ajoutez un délai (quelques secondes) entre les requêtes pour permettre à la première requête de terminer son traitement avant l’envoi de la suivante.
• Évitez les mises à jour simultanées du même champ : si deux requêtes mettent à jour le même attribut avec des valeurs différentes, envoyez ces mises à jour dans une seule requête ou séparez-les par un délai pour réduire le risque de résultats dans le désordre.
• Confirmez le traitement avant la requête suivante (bêta) : incluez un group_id dans la première requête, puis attendez que l’endpoint /users/track/status renvoie completed avant d’envoyer la requête dépendante. Pour plus d’informations, consultez Suivi de l’état de traitement des requêtes.

Pour plus d’informations sur les conditions de concurrence et les bonnes pratiques, consultez Conditions de concurrence.

Comment savoir quand Braze a terminé le traitement de ma requête ?

Incluez un group_id dans vos requêtes /users/track, puis appelez l’endpoint /users/track/status avec ce group_id. Lorsque le status du groupe est completed, Braze a terminé le traitement de toutes les requêtes du groupe. Cette fonctionnalité est en bêta. Pour plus d’informations, consultez Suivi de l’état de traitement des requêtes.

À quelle fréquence dois-je vérifier l’état d’un groupe ?

Interrogez l’endpoint /users/track/status à intervalle régulier, par exemple toutes les quelques secondes, et arrêtez lorsque le status du groupe est completed. Maintenez votre fréquence d’interrogation dans la limite de débit de l’endpoint, soit 1 500 requêtes par minute par espace de travail.

Pourquoi mon groupe est-il toujours en cours de traitement ?

Un groupe reste en processing jusqu’à ce que Braze ait terminé le traitement de chaque requête acceptée dans le groupe. Si une requête échoue pendant le traitement, Braze la relance, et le groupe reste en processing jusqu’à ce que la relance aboutisse. Si vous ajoutez des requêtes à un groupe après qu’il est completed, son état repasse à processing. Dans de rares cas, un groupe peut rester en processing jusqu’à la fin de sa période de rétention. Si un groupe reste en processing beaucoup plus longtemps que votre temps de traitement habituel, contactez l’assistance Braze.

Pourquoi /users/track/status renvoie-t-il un tableau results vide ?

Le tableau results est vide lorsque Braze ne trouve pas le groupe dans votre espace de travail. Cela se produit lorsque la période de rétention de 24 heures du groupe est terminée, lorsque le group_id ne correspond pas à celui de vos requêtes, ou lorsque vous avez envoyé les requêtes à un espace de travail différent. Cela se produit également lorsque Braze n’a suivi aucune requête pour ce group_id. Vérifiez chaque réponse /users/track pour les erreurs de suivi de l’état.

Pourquoi la réponse de /users/track est-elle plus lente que prévu ?

Les appels /users/track réussis sont généralement acceptés rapidement, mais Braze traite toujours les mises à jour d’attributs, d’événements et d’achats de manière asynchrone. La latence perçue peut augmenter lorsque les payloads sont volumineux ou lorsque le routage réseau vers votre endpoint REST est lent. Si vous avez besoin d’un accusé de réception synchrone par utilisateur ou d’un ordonnancement plus strict entre les appels, consultez /users/track/sync (bêta limitée).

Comment les limites de débit affectent-elles /users/track ?

Lorsque vous approchez de votre limite de débit, vous recevez des réponses 429. Pour les réponses non 429 sur les contrats pris en charge, vous pouvez utiliser les en-têtes de réponse X-RateLimit-* décrits dans En-têtes de limite de débit pour les utilisateurs actifs mensuels CY 24-25, Universal MAU, Web MAU et Mobile MAU pour voir combien de temps il reste dans votre fenêtre actuelle.

Pourquoi est-ce que je reçois une erreur 400 Bad Request avec une erreur de syntaxe ou d’analyse ?

Une erreur HTTP 400 avec une erreur de syntaxe ou d’analyse signifie généralement que le corps de la requête n’est pas un JSON valide. Les causes courantes incluent les virgules en fin de ligne, les commentaires dans le JSON, les chaînes entre guillemets simples, une accolade ouvrante { supplémentaire avant le payload, ou l’envoi d’un corps non JSON alors que l’en-tête Content-Type est application/json. Validez vos payloads avec un linter JSON avant l’envoi, confirmez que votre client HTTP encode les objets en JSON (plutôt que de concaténer des chaînes brutes) et vérifiez que le corps est encodé en UTF-8. Pour les autres réponses 400 (par exemple, les limites de taille du payload et les limites d’objets par requête), reportez-vous à Erreurs fatales et réponses et au tableau Erreurs spécifiques à l’endpoint sur cette page.

Utilisateurs actifs mensuels CY 24-25, MAU universel, MAU web et MAU mobile

Pour les clients bénéficiant d’une nouvelle tarification, les limites de débit sont appliquées au niveau de l’entreprise. Les clients peuvent définir des limites de débit par espace de travail pour les limites horaires, mais les limites de rafale restent partagées entre tous les espaces de travail.

Pour les clients qui ont acheté des utilisateurs actifs mensuels CY 24-25, Universal MAU, Web MAU ou Mobile MAU, Braze applique des limites de débit différentes sur son endpoint /users/track :

• Les limites de débit horaires sont fixées en fonction de l’activité d’ingestion de données prévue sur votre compte, qui peut correspondre au nombre d’utilisateurs actifs par mois que vous avez achetés, au secteur d’activité, à la saisonnalité ou à d’autres facteurs.
• En plus de la limite horaire, Braze applique une limite de rafale sur le nombre de requêtes pouvant être envoyées toutes les trois secondes.
• Chaque requête peut regrouper jusqu’à 75 mises à jour combinées portant sur des attributs, des événements ou des objets d’achat.

Les limites actuelles basées sur l’ingestion prévue sont disponibles dans le tableau de bord sous Paramètres > API et identifiants > Tableau de bord de l’utilisation de l’API. Nous pouvons modifier les limites de débit pour protéger la stabilité du système ou permettre une augmentation du débit de données sur votre compte. N’hésitez pas à contacter l’assistance Braze ou votre gestionnaire du succès des clients pour toute question concernant la limite de requêtes horaire ou par seconde et les besoins de votre entreprise.

En-têtes de limite de débit pour les utilisateurs actifs mensuels CY 24-25, Universal MAU, Web MAU et Mobile MAU

Toutes les réponses non limitées par le débit (c’est-à-dire non 429) contiennent les en-têtes de réponse HTTP suivants, qui indiquent au client l’état de la fenêtre de limite de débit horaire. Utilisez ces en-têtes pour gérer votre fréquence de requêtes :

Notez que les en-têtes RateLimit-Limit, RateLimit-Remaining et RateLimit-Reset ne sont pas renvoyés lorsque vous rencontrez une erreur HTTP 429. Dans ce cas, ces en-têtes sont remplacés par un en-tête X-Ratelimit-Retry-After qui renvoie un nombre entier indiquant le nombre de secondes à attendre avant de pouvoir recommencer à envoyer des requêtes.