Les Data connectors utilisent des APIs pour se connecter à des systèmes externes afin de récupérer et/ou mettre à jour des données existantes. C’est pourquoi il est important de garder quelques points à l’esprit lors de la configuration des Data connectors dans Intercom.

Si vous utilisez des APIs tierces (non développées en interne) avec les Data connectors dans Intercom, vous avez probablement peu ou pas de contrôle sur leur fonctionnement ou sur la réponse reçue d’une requête.

Cela dit, le guide ci-dessous reste une orientation utile, mais certaines sections peuvent ne pas s’appliquer entièrement à votre cas d’usage.

Nos ingénieurs ont compilé une liste de points à noter lors de la conception ou de la modification de vos APIs existantes pour fonctionner avec Fin et les Data connectors dans Intercom.

Nous recommandons vivement que vous activiez la sécurité du Messenger avec les JWTs. Sécuriser votre Messenger est le contrôle de sécurité le plus important à mettre en place pour votre intégration.

Cela vous permet également de signer plusieurs attributs via notre API JavaScript, afin d’envoyer en toute sécurité des données sur vos users via le Messenger au lieu d’utiliser une autre intégration, par exemple : REST API.

Pour bénéficier des avantages de l’envoi sécurisé de données, vous pouvez protéger vos attributs contre les mises à jour non sécurisées du Messenger et ainsi tout JWT envoyé, que nous considérons comme une source sécurisée, mettra à jour ce champ sur le user. Ceci est crucial pour les Data connectors, lorsque le Data connector affiche des données sensibles ou manipule des données.

Par exemple, si votre Data connector effectue une requête à l’API avec « GET /accounts/<account_id>/invoices », vous devez vous assurer que account_id est protégé afin que le user ne puisse pas simplement énumérer les account_ids pour collecter des données. Cependant, si votre Data connector est « GET /pizza-order-status/<order_id> », vous ne vous souciez peut-être pas de la fiabilité de « order_id » et vous ne vous souciez pas non plus de savoir si cette info a été affichée à la bonne personne.

De plus, vous devez vous assurer que l’attribut que votre Data connector utilise pour identifier de manière unique vos users (email, par exemple) est fiable. Cela signifie que vous devez savoir que vous faites confiance à la source des attributs d’identification de votre Data connector. Par exemple, si votre Data connector identifie le user par user_id, la vérification d’identité consiste à signer l’attribut user_id ou si votre Data connector identifie le user par email ou tout autre attribut, alors cet attribut est protégé et il n’est pas collecté auprès de l’End User sans une certaine vérification.

Cela empêche les acteurs malveillants, par exemple, de fournir l’adresse email de quelqu’un d’autre et d’accéder à un Data connector tel que « Obtenir les relevés bancaires par email », ce qui exposerait des données financières sensibles.

Dans la mesure du possible, nous vous suggérons de ne pas utiliser l’email comme identifiant principal pour récupérer les données de vos users, mais plutôt quelque chose de plus aléatoire comme un ID utilisateur unique et non devinable.

Pour effectuer la vérification d’identité sur les leads, notre équipe travaille actuellement sur une fonctionnalité de mot de passe à usage unique (OTP) qui vous aidera à vérifier l’identité d’une personne si elle contacte votre support en tant que lead. Si cette fonctionnalité vous intéresse, n’hésitez pas à contacter notre équipe Support via Messenger, ils seront ravis de vous aider à l’activer.

Vous devez également vous assurer que le user ne peut pas effectuer des Data connectors qu’il n’est pas autorisé à faire, par exemple annuler la commande de quelqu’un d’autre en connaissant l’ID de la commande. Cette logique n’est pas gérée dans Intercom et vous/votre équipe de sécurité devez réaliser une évaluation des risques et trouver des méthodes appropriées pour gérer l’authentification et l’autorisation.

Intercom supporte actuellement les tokens statiques, les tokens HTTP et OAuth (bêta fermée, contactez-nous via Messenger pour plus d’informations). Quel que soit le token utilisé, il est de votre responsabilité de vous assurer qu’il reste secret et qu’il soit mis à jour dès qu’il est divulgué quelque part. En bonne pratique, nous recommandons d’utiliser les tokens OAuth autant que possible.

Idéalement, l’API ne devrait retourner que les données nécessaires à votre Workflow. Cependant, cela peut être irréaliste et l’API pourrait retourner une bonne quantité de données qui ne sont en fait pas requises pour exécuter le Workflow où le Data connector est utilisé.

Si vous construisez des APIs de zéro pour être utilisées exclusivement avec les Data connectors et les Fin Workflows, vous pouvez soit :

Certaines considérations à inclure lors de la décision sur ce que et combien de données votre API retourne incluent :

De plus, vous devez toujours supprimer la possibilité pour les users de fournir des données mal formées ou simplement taper n’importe quoi.

Par exemple, vous ne devez pas demander au user de saisir son ID de compte, mais lui présenter ses IDs de compte (basés sur un identifiant connu et sécurisé) et lui permettre de choisir dans une liste déroulante. Plus d’informations sur la collecte de données auprès des users sont disponibles ici.