Créer et mettre à jour des utilisateurs (synchrone)

Utilisez cet endpoint pour enregistrer des événements personnalisés et des achats, et pour mettre à jour les attributs du profil utilisateur de manière synchrone. Cet endpoint fonctionne de la même manière que l’endpoint /users/track, qui met à jour les profils utilisateurs de manière asynchrone.

Important

Cet endpoint est actuellement en version bêta limitée. Bien que nous n’ajoutions pas de nouveaux clients à la version bêta pour le moment, n’hésitez pas à informer votre gestionnaire de compte Braze si vous pensez que cette fonctionnalité pourrait être utile pour votre intégration Braze.

Appels d’API synchrones et asynchrones

Lors d’un appel asynchrone, l’API renvoie le code d’état 201, qui indique que votre requête a bien été reçue, comprise et acceptée. Toutefois, cela ne signifie pas que votre requête a été entièrement exécutée.

Lors d’un appel synchrone, l’API renvoie le code d’état 201, qui indique que votre requête a bien été reçue, comprise, acceptée et exécutée. La réponse à l’appel affiche certains champs du profil utilisateur résultant de l’opération.

La limite de débit de cet endpoint est inférieure à celle de l’endpoint /users/track (voir Limite de débit). Chaque requête /users/track/sync ne peut contenir qu’un seul objet d’événement, un seul objet d’attribut ou un seul objet d’achat. Réservez cet endpoint aux mises à jour du profil utilisateur qui nécessitent un appel synchrone. Pour un déploiement sain, nous vous recommandons d’utiliser /users/track/sync et /users/track conjointement.

Par exemple, si vous envoyez des requêtes consécutives pour le même utilisateur sur une courte période, des conditions de concurrence peuvent survenir avec l’endpoint asynchrone /users/track. Avec l’endpoint /users/track/sync, en revanche, vous pouvez envoyer ces requêtes l’une après l’autre, chacune après avoir reçu une réponse 2XX.

Foire aux questions

Dois-je utiliser l’endpoint asynchrone ou synchrone ?

Pour la plupart des mises à jour de profil, l’endpoint /users/track est le plus adapté, grâce à sa limite de débit plus élevée et à la possibilité de regrouper les requêtes. Cependant, l’endpoint /users/track/sync est utile si vous rencontrez des conditions de concurrence dues à des requêtes rapides et consécutives pour le même utilisateur.

Le temps de réponse diffère-t-il de celui de l’endpoint /users/track ?

Avec un appel synchrone, l’API attend que Braze ait terminé la requête avant de renvoyer une réponse. Par conséquent, les requêtes synchrones prennent en moyenne plus de temps que les requêtes asynchrones vers /users/track. Pour la majorité des requêtes, vous pouvez vous attendre à une réponse en quelques secondes.

Puis-je envoyer plusieurs requêtes en même temps ?

Oui, à condition que les requêtes concernent des utilisateurs différents, ou que chaque requête mette à jour des attributs, des événements ou des achats différents pour un même utilisateur.

Si vous envoyez plusieurs requêtes pour un utilisateur concernant le même attribut, le même événement ou le même achat, Braze recommande d’attendre une réponse positive entre chaque requête afin d’éviter les conditions de concurrence.

Si vous constatez toujours un état de profil incohérent lorsque vous appelez /users/track pour le même utilisateur en succession rapide, basculez ces mises à jour vers /users/track/sync et envoyez une requête à la fois, en attendant chaque réponse 2XX avant d’envoyer la suivante. Cet ordonnancement est la méthode prise en charge pour éviter les conditions de concurrence de type lecture après écriture dans les boucles serrées ou avec des workers parallèles.

Pourquoi la valeur de la réponse ne correspond-elle pas à celle de ma requête initiale ?

Même si votre requête est terminée, il est possible que la valeur de votre attribut personnalisé n’ait pas été mise à jour. Cela peut se produire lorsque la mise à jour de votre attribut personnalisé dépasse le nombre maximal de caractères ou les limites de tableau, ou si l’utilisateur n’existe pas dans Braze et que vous avez défini _update_existing_only = true.

Dans ces cas, considérez la réponse comme une indication que, même si votre requête a bien été traitée, la mise à jour souhaitée n’a pas été effectuée. Pour résoudre le problème, référez-vous aux raisons mentionnées dans Pourquoi la valeur de la réponse ne correspond-elle pas à celle de ma requête initiale ?.

Vous pouvez télécharger le document OpenAPI et l’utiliser pour valider des schémas. Pour en savoir plus, consultez Utiliser les schémas OpenAPI pour valider les requêtes.