Vinkius AI Connect

Vinkius Connect (@vinkius/connect) transforme l'application d'IA que vous êtes en train de construire en une plateforme de connectivité pour vos propres utilisateurs. Une seule API de backend : chacun de vos utilisateurs dispose de ses propres connecteurs, de ses propres identifiants et de ses propres capacités d'IA, et vos agents les appellent depuis n'importe quel runtime de modèle. Vinkius gère la connectivité, l'authentification, les permissions, les protocoles et l'exécution derrière ces capacités. Votre application identifie l'utilisateur. Cette division du travail, c'est le produit.

Conçu pour celles et ceux qui lancent des produits d'IA

Vous construisez un copilote, une plateforme d'agents, un assistant vertical. Vos utilisateurs ont besoin que votre IA agisse dans le monde réel : ouvrir l'issue, envoyer le message, interroger la base de données, créer le ticket. Sans couche de connectivité, cela signifie construire chaque intégration vous-même : flux OAuth par fournisseur, stockage chiffré des jetons, gestion des protocoles, remaniements d'API permanents, revues de sécurité. Des mois de plomberie avant que votre produit ne fasse quelque chose de réel, et une surface d'attaque dont vous restez responsable pendant toute la vie de l'entreprise.

Ce travail, c'est la taxe d'intégration. Vinkius Connect l'élimine : les connecteurs sont déjà construits et maintenus, les identifiants sont gérés avec une isolation par utilisateur, et les capacités que votre agent appelle arrivent via une seule API de backend. Vous misez sur votre produit. La plomberie est faite.

Les trois décisions ci-dessous sont ce qui rend cela possible, et elles expliquent pourquoi la plateforme reste invisible pour vos utilisateurs pendant que votre entreprise conserve le client.

Un compte. De nombreux utilisateurs. Zéro exposition.

Créez une Application dans le tableau de bord Vinkius Cloud. En dessous, votre backend provisionne autant d'utilisateurs que votre produit en nécessite, et chacun est adressé par votre propre external_id : alice_123, une clé de base de données, un hachage opaque. Ce que votre système d'authentification utilise déjà.

Cette conception a une conséquence que la plupart des plateformes d'intégration ne proposent pas :

• Isolation par utilisateur. Chaque utilisateur connecte ses propres connecteurs et stocke ses propres identifiants. Deux utilisateurs peuvent connecter la même intégration GitHub en conservant un état de connexion, des identifiants et des capacités totalement distincts. Rien ne franchit la frontière.
• Vos utilisateurs réels ne sont jamais exposés à Vinkius. Le SDK n'exige ni e-mail, ni nom, ni profil. Vinkius ne connaît que l'identifiant opaque transmis par votre backend et les métadonnées non secrètes que vous choisissez d'attacher. Votre relation client, votre base d'utilisateurs et les données de votre produit restent de votre côté : Vinkius est une infrastructure invisible sous votre produit, pas une plateforme de plus entre vous et vos utilisateurs.
• Les identifiants restent en écriture seule. Votre backend définit les identifiants de connecteur d'un utilisateur et peut vérifier quels champs sont configurés, mais personne (ni votre code, ni le modèle, ni le tableau de bord) ne les relit.

Pour les garanties de sécurité derrière tout cela, consultez Security ; pour les règles de portée des routes, consultez Authentication and scope.

Des milliers de connecteurs dès le premier jour

Toute personne construisant quelque chose avec l'IA peut implémenter Vinkius et disposer du catalogue dès le premier jour : GitHub, Slack, Notion, bases de données, API internes et plus encore, déjà maintenus et qui grandissent chaque jour. Vous ne construisez pas d'intégrations, vous ne stockez pas de jetons, vous ne touchez pas à la plomberie OAuth. Vos utilisateurs connectent un compte une seule fois, dans votre produit, et chaque tour d'agent fonctionne simplement dès le premier jour de votre mise en production.

import { Vinkius } from '@vinkius/connect';

const vinkius = new Vinkius({
  appId: process.env.VINKIUS_APP_ID!,
  apiKey: process.env.VINKIUS_APP_KEY!,
});

async function configureAndListActions(
  externalId: string,
  credentials: Record<string, string>,
) {
  const user = vinkius.user(externalId);
  const connector = user.connector('github');

  const schema = await connector.credentials.schema();
  await connector.connect();
  const credentialState = await connector.credentials.set(credentials);
  const capabilities = await user.capabilities({ include: ['github'] });

  return {
    schema,
    configured: credentialState.configured,
    actions: capabilities.map(({ name, description }) => ({ name, description })),
  };
}

Connecteur, connexion et capacité

vinkius.user('alice_123') et .connector('github') sont des objets intermédiaires. Leur création n'effectue aucune requête. Les opérations telles que connect(), credentials.set(), capabilities() et execute() communiquent avec le réseau.

Deux plans sur un seul identifiant

Le SDK est divisé en deux plans sur le même identifiant vk_app_sk_* :

• Plan de contrôle, provisionnement et état : users, connectors, credentials, catalog.
• Plan d'exécution, runtime : capabilities() et execute().

user.capabilities() est le contrat principal : il renvoie les capacités d'IA disponibles pour cet utilisateur, sous forme d'objets exécutables et indépendants du framework. Un connecteur n'est pas une capacité. Un seul connecteur peut fournir de nombreuses capacités :

GitHub connector
       │
       ├── list repositories
       ├── create issue
       ├── create pull request
       ├── review code
       └── search code

const capabilities = await vinkius.user('alice_123').capabilities();
// the capabilities available to this user

La portée utilisateur fait partie de la route

Chaque opération utilisateur est adressée à la fois par les identifiants de votre application et par l'externalId transmis par votre backend. Deux utilisateurs peuvent connecter le même connecteur tout en conservant des états de connexion et des données d'authentification distincts.

N'acceptez pas externalId comme une entrée client sans restriction. Déduisez-le de la session ou vérifiez que l'appelant est autorisé à agir en son nom avant de créer l'objet. Consultez Authentication and scope.

Les capacités constituent la frontière d'exécution

Une Capability contient un nom d'affichage avec espace de noms pour la recherche côté modèle, un nom d'action brut du connecteur utilisé pour l'exécution, une description et un contrat d'entrée JSON Schema, le connecteur et l'identifiant de connexion nécessaires au routage de la requête, et execute(args, { signal, idempotencyKey }) :

const capabilities = await vinkius.user('alice_123').capabilities();

for (const capability of capabilities) {
  console.log(capability.name, capability.inputSchema);
}

Un CapabilitySet vide est un résultat normal. Considérez la disponibilité des capacités comme une donnée d'exécution au lieu de supposer que tous les utilisateurs disposent des mêmes outils.

Les adaptateurs restent à la frontière avec le modèle

Les capacités principales ne dépendent d'aucun fournisseur de modèle. Les sous-chemins d'adaptateur transforment leurs noms, descriptions et schémas en structures de fournisseur ou de framework : OpenAI, Anthropic, Gemini, le Vercel AI SDK, LangChain, LlamaIndex, Cloudflare Workers AI et tout runtime compatible avec OpenAI. Le paquet d'adaptateurs n'a aucune dépendance d'exécution envers ces frameworks externes ; votre application reste donc responsable du choix et de la vérification d'une version compatible. Consultez Framework adapters.

Commencez maintenant

• npm: npmjs.com/package/@vinkius/connect
• GitHub: github.com/vinkius-labs/ai-connect-sdk, avec des exemples exécutables dans le répertoire examples du dépôt
• Issues: github.com/vinkius-labs/ai-connect-sdk/issues

Étapes suivantes

• Install and configure the client
• Run the connect-to-execute quickstart
• Discover what the platform does behind every call