Vinkius AI Connect

Vinkius Connect (@vinkius/connect) macht aus der KI-Anwendung, die Sie bauen, eine Konnektivitätsplattform für Ihre eigenen Nutzer. Eine einzige Backend-API: Jeder Ihrer Nutzer erhält seine eigenen Connectors, seine eigenen Credentials und seine eigenen KI-Capabilities, und Ihre Agenten rufen sie aus jeder beliebigen Model-Runtime auf. Vinkius übernimmt die Konnektivität, die Authentifizierung, die Berechtigungen, die Protokolle und die Ausführung hinter diesen Capabilities. Ihre Anwendung identifiziert den Nutzer. Diese Arbeitsteilung ist das Produkt.

Gebaut für alle, die KI-Produkte ausliefern

Sie bauen einen Copiloten, eine Agentenplattform, einen vertikalen Assistenten. Ihre Nutzer brauchen eine KI, die in der realen Welt handelt: das Issue öffnen, die Nachricht senden, die Datenbank abfragen, das Ticket anlegen. Ohne Konnektivitätsschicht bedeutet das, jede Integration selbst zu bauen: OAuth-Flows pro Anbieter, verschlüsselte Tokenspeicherung, Protokollbehandlung, ständige API-Änderungen, Security-Reviews. Monate Verdrahtungsarbeit, bevor Ihr Produkt etwas Reales leistet, und eine Angriffsfläche, die Sie für die gesamte Lebensdauer des Unternehmens tragen.

Diese Arbeit ist die Integrationssteuer. Vinkius Connect baut sie ab: Die Connectors sind gebaut und werden gepflegt, die Credentials werden mit Isolation pro Nutzer behandelt, und die Capabilities, die Ihr Agent aufruft, kommen über eine einzige Backend-API. Sie konkurrieren mit Ihrem Produkt. Die Grundlagen sind erledigt.

Die drei Entscheidungen weiter unten machen das möglich, und sie sind der Grund, warum die Plattform für Ihre Nutzer unsichtbar bleibt, während Ihr Unternehmen den Kunden behält.

Ein Konto. Viele Nutzer. Keine Offenlegung.

Erstellen Sie eine Application im Dashboard der Vinkius Cloud. Darunter provisioniert Ihr Backend so viele Nutzer, wie Ihr Produkt braucht, und jeder einzelne wird über Ihre eigene external_id adressiert: alice_123, ein Datenbankschlüssel, ein opaker Hash. Was auch immer Ihr Authentifizierungssystem bereits verwendet.

Dieses Design hat eine Konsequenz, die die meisten Integrationsplattformen nicht bieten:

• Isolation pro Nutzer. Jeder Nutzer verbindet seine eigenen Connectors und speichert seine eigenen Credentials. Zwei Nutzer können dieselbe GitHub-Integration verbinden und dabei völlig getrennten Verbindungsstatus, getrennte Credentials und getrennte Capabilities behalten. Nichts überschreitet die Grenze.
• Ihre echten Nutzer werden gegenüber Vinkius niemals offengelegt. Das SDK verlangt keine E-Mail, keinen Namen, kein Profil. Vinkius kennt nur den opaken Bezeichner, den Ihr Backend übergibt, und die nicht geheimen Metadaten, die Sie anhängen. Ihre Kundenbeziehung, Ihre Nutzbasis und Ihre Produktdaten bleiben bei Ihnen: Vinkius ist unsichtbare Infrastruktur unter Ihrem Produkt, nicht eine weitere Plattform zwischen Ihnen und Ihren Nutzern.
• Credentials bleiben rein schreibbar. Ihr Backend setzt die Connector-Credentials eines Nutzers und kann prüfen, welche Felder konfiguriert sind, aber niemand (nicht Ihr Code, nicht das Modell, nicht das Dashboard) liest sie zurück.

Für die Sicherheitsgarantien dahinter siehe Security; für die Regeln zum Routen-Gültigkeitsbereich siehe Authentication and scope.

Tausende von Connectors ab Tag eins

Jeder, der etwas mit KI baut, kann Vinkius implementieren und hat den Katalog ab Tag eins: GitHub, Slack, Notion, Datenbanken, interne APIs und mehr, bereits gepflegt und wächst mit jedem Tag. Sie bauen keine Integrationen, Sie speichern keine Tokens, Sie fassen die OAuth-Verdrahtung nicht an. Ihre Nutzer verbinden ein Konto genau einmal, direkt in Ihrem Produkt, und jeder Agent-Turn funktioniert einfach ab dem Tag, an dem Sie ausliefern.

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 })),
  };
}

Connector, Verbindung und Capability

vinkius.user('alice_123') und .connector('github') sind Handles. Deren Erstellung löst keine Anfrage aus. Operationen wie connect(), credentials.set(), capabilities() und execute() gehen über das Netzwerk.

Zwei Ebenen über einer einzigen Credential

Das SDK ist in zwei Ebenen über dieselbe vk_app_sk_*-Credential aufgeteilt:

• Kontrollebene, Provisionierung und Zustand: users, connectors, credentials, catalog.
• Ausführungsebene, Runtime: capabilities() und execute().

user.capabilities() ist der primäre Vertrag: Er gibt die KI-Capabilities zurück, die diesem Nutzer zur Verfügung stehen, als ausführbare, framework-neutrale Objekte. Ein Connector ist keine Capability. Ein einzelner Connector kann viele Capabilities bereitstellen:

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

Der Nutzerbereich ist Teil der Route

Jede Nutzeroperation wird sowohl über Ihre Anwendungs-Credentials als auch über den von Ihrem Backend übergebenen externalId adressiert. Zwei Nutzer können denselben Connector verbinden und dabei getrennten Verbindungsstatus und getrennte Credentials behalten.

Akzeptieren Sie externalId nicht als uneingeschränkte Client-Eingabe. Lösen Sie ihn aus der Sitzung auf oder prüfen Sie, ob der Aufrufer berechtigt ist, für ihn zu handeln, bevor Sie das Handle erstellen. Siehe Authentication and scope.

Capabilities sind die Ausführungsgrenze

Eine Capability enthält einen namespaced Anzeigenamen für die modellseitige Suche, einen rohen Connector-Aktionsnamen für die Ausführung, eine Beschreibung und einen JSON-Schema-Eingabevertrag, den Connector und die Verbindungs-ID, die zum Routen der Anfrage nötig sind, sowie execute(args, { signal, idempotencyKey }):

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

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

Ein leerer CapabilitySet ist ein normales Ergebnis. Behandeln Sie die Verfügbarkeit von Capabilities als Laufzeitdaten, statt anzunehmen, dass jeder Nutzer dieselben Tools hat.

Adapter bleiben an der Modellgrenze

Core-Capabilities hängen nicht von einem Modellanbieter ab. Adapter-Subpaths bilden ihre Namen, Beschreibungen und Schemas in strukturelle Anbieter- oder Framework-Formen ab: OpenAI, Anthropic, Gemini, das Vercel AI SDK, LangChain, LlamaIndex, Cloudflare Workers AI und jede OpenAI-kompatible Runtime. Das Adapter-Paket hat keine Laufzeitabhängigkeit von diesen externen Frameworks, daher bleibt Ihre Anwendung dafür verantwortlich, eine kompatible Framework-Version zu wählen und zu testen. Siehe Framework adapters.

Jetzt starten

• npm: npmjs.com/package/@vinkius/connect
• GitHub: github.com/vinkius-labs/ai-connect-sdk, mit lauffähigen Beispielen im examples-Verzeichnis des Repositorys
• Issues: github.com/vinkius-labs/ai-connect-sdk/issues

Nächste Schritte

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