Endpoints des objets de données

Utilisez ces endpoints pour lister les types d’objets de données, gérer les enregistrements d’objets de données, et gérer les relations entre objets et utilisateurs.

Important

Les objets de données sont actuellement en accès anticipé. Votre espace de travail doit être activé avant que les permissions de clé API des objets de données n’apparaissent dans Paramètres > Clés API.

Endpoints de type

• 

  GET : Lister les types d'objets de données
• 

  GET : Obtenir un type d'objet de données
• 

  GET : Lister les types de relations utilisateur
• 

  GET : Lister les types de relations objet

Endpoints d'objet

• 

  GET : Lister les objets de données
• 

  GET : Obtenir un objet de données
• 

  POST : Créer un objet de données
• 

  PUT : Remplacer un objet de données
• 

  PATCH : Mettre à jour un objet de données
• 

  DELETE : Supprimer un objet de données

Endpoints de relations objet

• 

  GET : Lister les relations objet
• 

  POST : Créer une relation objet
• 

  PUT : Remplacer une relation objet
• 

  PATCH : Mettre à jour une relation objet
• 

  DELETE : Supprimer une relation objet

Endpoints de relations utilisateur

• 

  GET : Lister les relations utilisateur
• 

  POST : Créer une relation utilisateur
• 

  PUT : Remplacer une relation utilisateur
• 

  PATCH : Mettre à jour une relation utilisateur
• 

  DELETE : Supprimer une relation utilisateur

URL de base et authentification

Utilisez votre endpoint REST d’espace de travail et envoyez Authorization: Bearer YOUR_REST_API_KEY. Cette section explique où les endpoints des objets de données sont hébergés et comment les requêtes sont authentifiées.

• Pour les hôtes d’endpoint, consultez l’aperçu de l’API Braze.
• Tous les payloads de requête et de réponse sont au format JSON.
• Les requêtes sont limitées à l’espace de travail propriétaire de la clé API.
• Si la clé dispose d’une liste d’adresses IP autorisées, les adresses IP non autorisées renvoient 403.

Permissions de clé API

Cette section associe chaque endpoint à la permission requise afin que vous puissiez limiter la portée de vos clés API en toute sécurité.

Remarque

La lecture des relations entre objets utilise data_objects.read. Il n’existe pas de permission data_objects.object_relationships.read.

Limites de débit

Cette section explique les quotas de requêtes par défaut et les en-têtes de réponse pour le trafic en lecture et en écriture.

Chaque réponse inclut X-RateLimit-Limit, X-RateLimit-Remaining et X-RateLimit-Reset.

Pour les requêtes limitées, Braze renvoie 429 et un payload d’erreur avec id et message.

1
2
3
4
5
6
7
8

{
  "errors": [
    {
      "id": "rate-limit-exceeded",
      "message": "You have exceeded your limit of 50 requests per minute."
    }
  ]
}

Limites du produit

Cette section répertorie les limites appliquées par Braze aux objets de données et ce à quoi vous pouvez vous attendre lorsque vous en atteignez une.

Limites de nombre

Ces limites s’appliquent à l’ensemble de votre entreprise, sauf indication contraire. Votre équipe de compte Braze peut ajuster les valeurs par défaut pour votre entreprise.

Limites de champs et de valeurs

Ces limites sont fixes pour toutes les entreprises.

Ce qui se passe lorsque vous atteignez une limite

Une requête qui dépasserait une limite de nombre renvoie 422 avec un id d’erreur qui identifie la limite :

1
2
3
4
5
6
7
8

{
  "errors": [
    {
      "id": "data-object-record-limit-exceeded",
      "message": "This company has reached its data object record limit"
    }
  ]
}

Vos enregistrements et relations existants restent en place — seule la requête qui dépasserait la limite est rejetée. Pour libérer de l’espace sous une limite, supprimez les enregistrements dont vous n’avez plus besoin ou retirez les relations que vous n’utilisez plus. Pour augmenter une limite de nombre, contactez votre équipe de compte Braze.

Les requêtes qui échouent à la validation, comme un object_id ou une valeur d’attribut trop long(ue), renvoient 400. Les requêtes dépassant la limite de débit renvoient 429.

Concepts clés

Cette section définit les identifiants clés utilisés dans tous les endpoints des objets de données.

• type_name : Le nom machine du type d’objet de données, unique au sein d’un espace de travail.
• object_id : Votre identifiant d’objet, unique au sein d’un type.
• braze_id : L’ID utilisateur Braze utilisé sur les endpoints de relations utilisateur.
• attributes : Objet ou données relationnelles indexés par nom de champ, validés par rapport au schéma configuré.

Fonctionnement des relations

Cette section explique les types de relations, les arêtes de relations et le comportement de anchor avant que vous n’utilisiez les pages de référence des endpoints.

Modèle de relations en un coup d’œil

Utilisez ce diagramme pour voir comment les types, les enregistrements et les relations s’articulent, et ce que leur liaison permet de faire dans Braze. Vous définissez les types dans le tableau de bord, puis vous créez les enregistrements et les liens entre eux via ces endpoints.

%%{init: {"flowchart": {"wrappingWidth": 400}} }%%
flowchart LR
  subgraph define["Set up in the dashboard"]
    objtype["Data object types define<br/>the fields a record has"]
    reltype["Relationship types determine<br/>which links are allowed"]
  end

  subgraph write["Write with the API"]
    person["A person you<br/>send messages to"]
    record["A business record<br/>they belong to"]
    related["Another record<br/>connected to it"]
    person -- "A user relationship links<br/>a person to a record" --> record
    record -- "An object relationship links<br/>one record to another" --> related
  end

  subgraph unlock["What it unlocks"]
    segment["Segment people by the<br/>records they belong to"]
    liquid["Personalize messages with<br/>data from those records"]
  end

  define -- "decides what you<br/>are allowed to link" --> write
  write -- "makes these<br/>possible" --> unlock

Les types et les arêtes sont distincts

• Les types de relations définissent quels liens sont valides et sont gérés dans le tableau de bord.
• Les arêtes de relations sont les liens réels entre les enregistrements, et elles sont créées, mises à jour et supprimées via ces endpoints d’API.
• Avant d’écrire des relations, listez les valeurs rel_kind valides avec :
  • GET /data_objects/types/{type_name}/user_relationship_types
  • GET /data_objects/types/{type_name}/object_relationship_types

Pourquoi les relations entre objets nécessitent related_type_name

• rel_kind n’est pas globalement unique pour toutes les paires de types d’objets. Par exemple, rel_kind peut être subaccount pour une paire de types d’objets et partner_account pour une autre.
• Les écritures de relations entre objets nécessitent donc à la fois rel_kind et related_type_name pour identifier le type de relation visé ainsi que l’autre type d’objet dans l’association.
• Si related_type_name ne correspond pas au type de relation pour ce rel_kind, la requête renvoie 400.

anchor contrôle la direction de la relation

Les relations entre objets sont directionnelles. L’objet de l’URL est interprété en fonction de anchor.

Créer la même arête depuis la perspective d’ancrage opposée cible toujours une seule relation sous-jacente. Un second appel de création pour la même arête renvoie 409 (duplicate-object-relationship).

Asymétrie des chemins pour les relations utilisateur

Les lectures et écritures de relations utilisateur utilisent intentionnellement des chemins d’endpoints différents :

• Lecture : GET /data_objects/objects/{type_name}/{object_id}/user_relationships
• Écriture : POST|PUT|PATCH|DELETE /data_objects/objects/{type_name}/{object_id}/users

Les attributs de relation sont distincts des attributs d’objet

• Les endpoints de relations renvoient les attributs au niveau de l’arête dans le champ attributes de premier niveau.
• Les attributs d’objet restent imbriqués sous to_data_object ou from_data_object.
• PUT remplace les attributes de la relation, et PATCH fusionne les attributes de la relation.

Exemple détaillé

Cet exemple illustre un workflow courant de gestion de compte :

1. Créer account/acct-123.
2. Créer account/acct-456 en tant que compte enfant.
3. Lier un utilisateur à acct-123 avec rel_kind: account_user.
4. Lier acct-123 à acct-456 avec rel_kind: subaccount.

Pour relire les liens :

• GET /data_objects/objects/account/acct-123/user_relationships pour les utilisateurs liés
• GET /data_objects/objects/account/acct-123/object_relationships pour les liens d’objets sortants
• GET /data_objects/objects/account/acct-456/object_relationships?anchor=target pour les liens d’objets entrants

Remarque

Les endpoints DELETE pour les relations entre objets et les relations utilisateur nécessitent un corps de requête JSON.

Pagination et actualisation des données

Cette section couvre le comportement de pagination des listes et le délai de visibilité attendu des données après une écriture.

• Les endpoints de liste prennent en charge limit et offset.
• limit est défini par défaut à 100 et est limité entre 1 et 250.
• offset est défini par défaut à 0, et les valeurs négatives sont ramenées à 0.
• Les écritures sont immédiatement visibles pour les lectures et la personnalisation Liquid.
• L’appartenance à un Segment basée sur les objets de données peut être décalée d’une heure au maximum, car les filtres calculés sont actualisés toutes les heures.

Comportement en cas d’erreur

Cette section résume les codes de statut et les réponses d’erreur utilisés dans les endpoints des objets de données.

• 404, 409, 422 et 429 renvoient un tableau errors avec id et message.
• 400, 401 et 403 renvoient une seule chaîne error.
• 422 signifie que la requête dépasserait une limite produit. Les valeurs limites par défaut varient selon le contrat de l’entreprise.