This documentation is currently under development. Certain sections are not yet complete and will be added shortly.
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Création de cartes déclenchée par un connecteur

Comprenez quand les connecteurs créent automatiquement des cartes et quelles données doivent exister pour les rendus ultérieurs.

Création de Carte déclenchée par le connecteur

Certaines intégrations créent des Cartes automatiquement à partir d’événements du système source. Au lieu qu’un frontend ou un SDK crée la Carte pendant un parcours d’inscription destiné à l’utilisateur, le connecteur crée la Carte lorsqu’un événement pertinent se produit dans le système en amont.

Ce modèle est utile lorsque le système source est déjà le système de référence pour les événements d’éligibilité ou de cycle de vie. La règle clé reste la même : la Carte doit être créée avec les bons identifiants externes, car les rendus ultérieurs dépendent de ces identifiants pour récupérer les données en direct.

Exemples concrets
  • Un événement CRM crée une Carte de fidélité lorsqu’un client rejoint un programme.

  • Un événement de billetterie crée une Carte lorsqu’une commande est confirmée.

  • Un système d’adhésion crée une Carte lorsqu’un abonnement actif démarre.

Quand ce modèle est utilisé

La création déclenchée par le connecteur est le bon modèle lorsque l’émission de la Carte doit suivre un événement système plutôt qu’une action utilisateur dans un frontend personnalisé.

Les exemples courants sont la création d’un client, la confirmation d’une commande, l’activation d’un abonnement ou tout autre événement en amont qui prouve qu’une Carte doit exister. Une fois la Carte créée, la distribution et l’installation peuvent avoir lieu plus tard via le canal choisi par le projet.

Si le projet a plutôt besoin d’un parcours de création destiné à l’utilisateur, utilisez Flux d’inscription.

Ce que le connecteur doit fournir

Au moment de la création, le connecteur doit fournir les identifiants nécessaires pour les recherches ultérieures.

Ces identifiants externes constituent le lien durable entre la Carte et l’enregistrement source. Sans eux, les rendus ultérieurs ne peuvent pas récupérer de manière fiable les données client ou transactionnelles.

Le connecteur peut également définir des valeurs au niveau de la Carte, comme des données supplémentaires, lorsque le projet nécessite des remplacements stockés qui ne proviennent pas d’une recherche en direct du connecteur.

Utilisez Données de Carte et synchronisation pour le modèle de données derrière ce flux.

Ce qui se passe après la création

Une fois que le connecteur a créé la Carte, le reste du cycle de vie suit le même modèle que pour toute autre Carte.

La plateforme ne copie pas les données source dans un stockage à long terme pour les garder synchronisées en arrière-plan. Les rendus ultérieurs récupèrent toujours les données en direct depuis les systèmes source. Si les données source changent, un déclencheur de rendu est toujours nécessaire avant que la Carte installée ne change.

Les déclencheurs courants sont l’installation dans le Wallet, l’aperçu et la mise à jour push.

Utilisez Comment une Carte est rendue pour le pipeline de rendu complet et Prise en main de l’API pour les mises à jour pilotées par l’API après la création.

Conséquences opérationnelles

Ce modèle de création change l’endroit où les erreurs apparaissent généralement.

Si une Carte n’est pas créée, le premier endroit à examiner est l’événement en amont et le chemin du connecteur qui le traite. Si la Carte existe mais que les rendus ultérieurs affichent des champs vides, le premier endroit à examiner est celui des identifiants externes stockés sur la Carte.

Comparer les modèles de création

Création déclenchée par le connecteur

Un événement système crée automatiquement la Carte. Cela fonctionne bien lorsque le système source décide déjà qui doit recevoir une Carte.

Création via flux d’inscription

Un frontend ou un flux hébergé crée la Carte pendant un parcours destiné à l’utilisateur. Cela fonctionne bien lorsque le projet contrôle directement l’inscription, l’enregistrement ou le paiement.

Dans les deux modèles, l’API est utilisée après la création pour les mises à jour, les notifications, les scans et d’autres opérations du cycle de vie. Utilisez Prise en main de l’API pour ces appels de gestion.

Liste de contrôle de validation

Un flux de création déclenché par le connecteur doit confirmer quatre choses.

  • L’événement source attendu se produit.

  • La Carte est créée exactement une fois pour cet événement.

  • Les bons identifiants externes sont stockés sur la nouvelle Carte.

  • Un rendu ultérieur peut récupérer les données source avec succès.

Les webhooks sont souvent utiles ici, car ils facilitent l’observation des événements du cycle de vie de la Carte, comme la création et l’installation de la Carte.

Utilisez Webhooks lorsqu’une visibilité sur le cycle de vie est nécessaire.

FAQ

La création déclenchée par le connecteur stocke-t-elle les données client dans The Wallet Crew ?

Non. Elle crée un enregistrement de Carte et stocke les identifiants ainsi que toutes les valeurs au niveau de la Carte qui doivent être conservées. Les données client restent dans les systèmes source.

Un connecteur peut-il à la fois créer une Carte et fournir plus tard des données au moment du rendu ?

Oui. Ce sont des moments distincts dans le cycle de vie. La création établit la Carte et les identifiants. Les rendus ultérieurs récupèrent à nouveau les données en direct.

Ce modèle est-il meilleur qu’un flux Cinto SDK ?

Aucun des deux modèles n’est universellement meilleur. Le bon choix dépend de l’endroit où se prend la décision d’émission et du système qui contrôle le parcours utilisateur.

Mis à jour