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 votre espace de travail Fin.

Si vous utilisez des APIs tierces (non développées en interne) avec Data Connectors dans votre espace de travail Fin, vous avez probablement peu ou pas de contrôle sur leur fonctionnement ou sur la réponse que vous recevez d’une requête.

Cela dit, le guide ci-dessous contient toujours des instructions utiles, mais certaines sections peuvent ne pas être entièrement applicables à votre cas d’utilisation.

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 Data Connectors dans votre espace de travail Fin.

Nous recommandons fortement que vous activiez la sécurité Messenger avec 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 tout JWT envoyé, que nous considérons comme une source sécurisée, mettra toujours à 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 en utilisant « GET /accounts/<account_id>/invoices », vous voulez 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> », alors vous ne vous souciez peut-être pas de la fiabilité de « order_id » et vous ne vous souciez pas de savoir si vous avez affiché cette info à 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 de pouvoir, par exemple, fournir l’adresse email de quelqu’un d’autre et 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 user unique et non devinable.

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 par 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.

Nous supportons actuellement les tokens statiques, les tokens HTTP et OAuth. 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 pour votre Task/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 Connectors est utilisé.

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

Certaines considérations à inclure lors de la décision de ce que votre API retourne et en quelle quantité 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 à l’utilisateur 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.