Parcourir la documentation

Concepts fondamentaux

Les trois produits Connector partagent les fournisseurs, les opérations et les schémas, mais utilisent des modèles différents d’isolation des comptes et de permissions. Identifiez d’abord le produit, puis interprétez ses ressources de connexion, de compte connecté, de Team ou de Project.

ProduitModèle de compte et d’isolationExécution dans
OOMOL Connector (Hosted)Connexions dans un scope personnel ou de TeamL’hébergement OOMOL
Connector for SaaSProjects, utilisateurs externes et comptes connectésL’hébergement OOMOL
OpenConnectorUn runtime et des connexions gérés par l’opérateurVotre infrastructure

Concepts partagés par les trois produits

Apps et fournisseurs

Une App est le service que l’utilisateur voit et choisit de connecter, comme Gmail, GitHub ou Slack.

Un fournisseur ou service est l’intégration Connector correspondante. Il définit l’authentification, les opérations, les schémas et la manière dont Connector interroge l’API en amont. Le nom de l’App et celui du fournisseur correspondent généralement, mais le premier désigne le service présenté à l’utilisateur et le second la limite d’implémentation de Connector.

Opérations et outils

Une opération est une fonction appelable exposée par un fournisseur. Son action ID combine généralement un service et une opération, comme gmail.search_threads. Chaque opération possède un schéma d’entrée et définit les données renvoyées par un appel.

Un outil est la surface d’appel par laquelle un Agent, le CLI ou un client MCP voit une opération. Un SDK exécute généralement une opération directement, tandis qu’un Agent découvre et appelle les opérations disponibles sous forme d’outils.

Avant l’exécution, confirmez :

  • le compte utilisé par l’opération ;
  • les paramètres qui seront envoyés ;
  • si l’opération lit, écrit ou supprime des données ;
  • si l’identité actuelle peut utiliser la ressource de compte correspondante.

Agents et Skills

Un Agent choisit un outil, fournit les paramètres et utilise le résultat pour poursuivre une tâche. OOMOL fournit les capacités autorisées des Apps employées pendant ce travail.

Un Skill est un ensemble réutilisable d’instructions de tâche. Il indique à l’Agent quels outils utiliser, dans quel ordre, quelles contraintes préserver et comment organiser le résultat. L’exécution utilise l’identité et les outils disponibles de l’Agent, tandis que Connector stocke les identifiants de l’App.

OOMOL Connector (hébergé)

Connexion

Une connexion est une instance de connexion à un compte d’App dans un scope personnel ou de Team. Elle possède son propre nom et son propre ID de connexion, et elle est associée à l’autorisation du compte, à son état et aux paramètres de permissions.

Le même compte d’App peut être connecté plusieurs fois. Chaque connexion peut configurer séparément :

  • Action access : les opérations autorisées par la connexion ;
  • Member access : les membres de la Team qui peuvent utiliser la connexion.

Les opérations qu’un membre peut appeler correspondent à l’union des opérations autorisées par toutes les connexions auxquelles il a accès.

Team

Une Team est le scope de locataire Team pour Hosted Connector. La Team active détermine les connexions visibles par l’appelant et les opérations qu’il peut y utiliser.

Les clients CLI, MCP et SDK doivent sélectionner explicitement une Team afin qu’une modification ultérieure de la Team par défaut ne sélectionne pas la mauvaise connexion. Le forfait Team est facturé par siège ; consultez les informations actuelles dans la page Billing de Console.

Accès effectif

Un appel ne peut s’exécuter qu’à l’intersection de ces limites :

Provider authorization
  ∩ connection Action access
  ∩ Team Member access
  ∩ CLI, MCP, or SDK caller identity
  = actions the caller can execute

Consultez Contrôle d’accès et Gestion des Teams pour les détails de configuration.

Parcours d’un appel Hosted Connector

User connects an App
  → a connection is created
  → Agent or trusted backend selects an action and connection
  → Hosted Connector checks access and loads credentials
  → Provider API
  → result and execution metadata return to the caller

Connector pour SaaS

Connector for SaaS permet aux utilisateurs de votre produit de connecter leurs propres comptes tiers. Il utilise un modèle de ressources multi-tenant distinct :

RessourceRôle
ProjectIsole la configuration, les clés, les comptes connectés, les enregistrements d’exécution et l’utilisation d’une intégration de produit
Provider configDéfinit l’authentification d’un fournisseur dans un Project
External user IDAssocie les ressources OOMOL à un utilisateur de votre produit
Compte connectéReprésente un compte fournisseur autorisé par un utilisateur externe
Clé API du ProjectAuthentifie les requêtes du Project provenant d’un backend de confiance

Un compte connecté représente un compte fournisseur autorisé par un utilisateur externe dans un Project. Le backend le sélectionne lors de l’exécution d’une opération pour cet utilisateur du produit.

Parcours d’un appel SaaS

Product user completes Provider authorization
  → connected account is linked to an external user ID
  → your backend uses a Project API key
  → ProjectConnector selects the user, connected account, and action
  → Hosted Connector executes the call
  → Provider API

Votre produit authentifie ses propres utilisateurs et maintient une association d’utilisateurs externes stable et difficile à deviner. Consultez Connector for SaaS pour le modèle de ressources et le flux d’intégration.

OpenConnector

OpenConnector est le runtime et la passerelle open source que vous déployez dans votre propre infrastructure.

  • Le runtime charge les fournisseurs, gère les connexions, sélectionne les identifiants, applique les politiques et appelle les API des fournisseurs.
  • La passerelle est la surface d’accès exposée par le runtime aux clients MCP, HTTP, OpenAPI et SDK.
  • Un jeton runtime contrôle l’accès d’un client au runtime et à ses capacités.

OpenConnector place le runtime, les connexions et la politique d’accès dans l’infrastructure que vous gérez. Les appelants utilisent ses opérations via MCP, HTTP, OpenAPI ou le SDK.

Parcours d’un appel OpenConnector

You configure a Provider and connection
  → Agent or application selects an action and connection
  → OpenConnector runtime checks the token and policy
  → runtime loads credentials and calls the Provider API
  → result returns to the caller

L’opérateur est responsable du chiffrement des identifiants, des jetons, du stockage, du réseau, des journaux, des sauvegardes et des mises à niveau. Consultez OpenConnector pour la description complète de cette limite.

Limite des identifiants

Les jetons OAuth bruts des fournisseurs, les clés API et les identifiants personnalisés ne doivent pas être exposés aux Agents, aux Skills, aux clients de navigateur ou aux utilisateurs du produit :

  • OOMOL stocke et renouvelle les identifiants dans sa limite hébergée pour Hosted Connector et Connector for SaaS ;
  • l’opérateur d’OpenConnector protège les identifiants dans sa propre infrastructure ;
  • Connector charge les identifiants lors de l’exécution d’une opération ou d’une requête proxy prise en charge, et ne renvoie que le résultat à l’appelant.

Choisir le terme approprié

ScénarioTerme à utiliser
Un particulier ou une Team connecte un compte d’Appconnexion
Un utilisateur d’un produit SaaS connecte son propre comptecompte connecté + utilisateur externe
La limite d’isolation d’une intégration SaaSProject
Limiter l’utilisation d’un compte et des opérations dans une TeamMember access et Action access de la connexion
Une entrée appelable présentée à un Agentoutil
Une opération définie par Connectoropération
Un service d’exécution auto-hébergéruntime / passerelle OpenConnector

Après avoir choisi un produit, poursuivez avec sa vue d’ensemble et son guide d’intégration. Consultez la référence du SDK TypeScript pour les méthodes et types exacts.