OOMOL est une solution complète d'intégration d'apps open-source pour une couche de connexion fiable entre les agents IA et les backends produit.
GitHub, Gmail, Notion, Slack, Supabase, Airtable : vous ne devriez pas avoir à reconstruire l'authentification et les appels pour chacun. Ajoutez OpenConnector et votre produit peut utiliser une seule couche de connexion.
Parcourir les AppsL'autorisation, les identifiants, les paramètres, les appels et les enregistrements vivent dans un seul service open-source. Lancez-le vous-même, auditez le code et décidez comment chaque connexion peut être utilisée.
Connectez les apps que vos utilisateurs connaissent déjà et consacrez votre temps à l'expérience produit plutôt qu'à la pagination, aux paramètres, aux erreurs et aux scopes.
Les clés API, les tokens OAuth et les paramètres de connexion restent dans OpenConnector. Votre backend appelle avec des noms de connexion et des paramètres.
Les backends TypeScript, les outils MCP et les appels HTTP peuvent utiliser les mêmes comptes sans demander aux utilisateurs de s'autoriser à nouveau.
Choisissez une app, laissez l'utilisateur s'autoriser, passez un appel et consultez l'enregistrement. OpenConnector stocke les identifiants et effectue la requête externe.
Trouvez l'app et l'action, puis vérifiez les paramètres et les scopes.
Chaque connexion correspond à un compte réel. Après la configuration OAuth ou la clé API, les identifiants restent dans le service de connexion.
Utilisez le SDK, MCP ou HTTP. OpenConnector communique avec l'app externe et renvoie le résultat.
Les enregistrements d'appels, les sorties expurgées et les règles d'autorisation ou de blocage aident votre équipe à voir quels systèmes ont utilisé quelles connexions.
Le SDK TypeScript, le CLI oo, MCP et HTTP peuvent appeler les mêmes comptes connectés. Choisissez la méthode d'appel pour chaque cas d'usage sans répéter le travail d'autorisation ou d'identifiants.
Accédez aux apps connectées depuis les backends TypeScript et intégrez des intégrations dans votre produit.
Voir le SDKVérifiez les connexions, lisez les paramètres et vérifiez un appel depuis votre terminal.
Voir le CLILaissez les hôtes MCP utiliser les apps connectées tandis qu'OpenConnector conserve le contrôle des comptes et des permissions.
Lire les docsUtilisez HTTP brut ou lisez la description OpenAPI lorsque vous avez besoin de clients générés.
Lire les docsUtilisez l'hébergement OOMOL pour gérer l'autorisation, les identifiants et les appels lorsque vous souhaitez ajouter des intégrations rapidement. Déployez sur Cloudflare ou auto-hébergez OpenConnector lorsque votre équipe a besoin de contrôler le code, les données et les opérations.
Laissez OOMOL gérer l'autorisation, les identifiants et les appels pour réduire le travail opérationnel et lancer plus rapidement.
Utilisez Workers, D1, R2 et Static Assets pour un service léger géré par votre équipe.
Gardez le service de connexion, la console web et les données dans votre propre environnement lorsque vous avez besoin d'un contrôle total.
Réponses sur l'hébergement, le stockage des identifiants, les chemins d'accès, les permissions et l'état des connexions.
Les identifiants restent dans le service OpenConnector. Votre backend appelle les interfaces autorisées via le SDK, MCP ou HTTP en utilisant les noms de connexion et les paramètres.
Le SDK, le CLI oo, MCP, HTTP et OpenAPI peuvent tous utiliser les mêmes connexions. Choisissez le point d'entrée qui convient à votre produit.
Oui. Le même service de connexion peut servir les flux de travail des agents via le CLI oo ou MCP et les backends produit via le SDK ou HTTP. L'accès dépend toujours du compte, des scopes et des actions que vous exposez pour chaque cas d'usage.
Utilisez le SDK depuis un backend de confiance. Les pages du navigateur peuvent démarrer des flux d'autorisation côté utilisateur, mais les appels d'exécution impliquant des identifiants de projet, des tokens d'administration ou des identifiants de connexion sensibles doivent rester côté serveur.
Non. OpenConnector supporte OAuth, les clés API, les identifiants personnalisés et les fournisseurs sans authentification lorsque l'action du fournisseur supporte ce type de connexion. Les flux OAuth peuvent attendre l'autorisation, tandis que les connexions par clé API et identifiants personnalisés peuvent renvoyer un compte de manière synchrone.
Oui. Vérifiez les scopes du fournisseur, les schémas d'actions et les libellés de connexion avant d'exposer une action aux agents ou aux fonctionnalités produit. Dans les déploiements auto-hébergés, votre équipe contrôle également la politique de déploiement, le stockage, les journaux et les interfaces que vous publiez.
Utilisez OOMOL hébergé lorsque votre équipe souhaite moins de tâches opérationnelles autour des apps OAuth, du stockage des identifiants et de la disponibilité du service.
Votre équipe exécute le service OpenConnector et gère les apps OAuth, les clés API, la base de données d'exécution, la clé de chiffrement, le déploiement, les mises à jour, les journaux et les contrôles d'accès. Cette voie vous donne plus de contrôle opérationnel sur le code et les données.
Les comptes connectés indiquent leur état : actif, réautorisation nécessaire, erreur ou déconnecté. Votre produit peut vérifier l'état du compte avant d'appeler une action et guider les utilisateurs pour se reconnecter lorsque l'autorisation expire.
Non. Ces logos sont des exemples. OpenConnector peut se connecter à plus de 1000 apps et services à travers les SaaS, outils de développement, apps de productivité, systèmes de données et services d'IA.
