Vinkius AI Connect

Vinkius Connect (@vinkius/connect) turns the AI application you're building into a connectivity platform for your own users. One backend API: each of your users gets their own connectors, their own credentials and their own AI capabilities, and your agents call them from any model runtime. Vinkius handles the connectivity, authentication, permissions, protocols and execution behind those capabilities. Your application identifies the user. That division of labor is the product.

Built for the people shipping AI

You are building a copilot, an agent platform, a vertical assistant. Your users need your AI to act in the real world: open the issue, send the message, query the database, file the ticket. Without a connectivity layer that means building every integration yourself: OAuth flows per provider, encrypted token storage, protocol handling, API churn, security reviews. Months of plumbing before your product does anything real, and an attack surface you own for the life of the company.

That work is the integration tax. Vinkius Connect removes it: the connectors are built and maintained, the credentials are handled with per-user isolation, and the capabilities your agent calls arrive through one backend API. You compete on your product. The plumbing is done.

The three decisions below are what make that possible, and they are why the platform stays invisible to your users while your business keeps the customer.

One account. Many users. Zero exposure.

Create one Application in the Vinkius Cloud dashboard. Under it, your backend provisions as many users as your product needs, and every one of them is addressed by your own external_id: alice_123, a database key, an opaque hash. Whatever your auth system already uses.

That design carries a consequence most integration platforms do not offer:

• Per-user isolation. Each user connects their own connectors and stores their own credentials. Two users can connect the same GitHub integration while keeping completely separate connection state, separate credentials and separate capabilities. Nothing crosses the boundary.
• Your real users are never exposed to Vinkius. The SDK requires no email, no name, no profile. Vinkius knows only the opaque identifier your backend passes and the non-secret metadata you choose to attach. Your customer relationship, your user base and your product data stay on your side: Vinkius is invisible infrastructure under your product, not another platform standing between you and your users.
• Credentials stay write-only. Your backend sets a user's connector credentials and can verify which fields are configured, but nobody (not your code, not the model, not the dashboard) reads them back.

For the security guarantees behind this, see Security; for the route-scoping rules, see Authentication and scope.

Thousands of connectors from day one

Anyone building something with AI can implement Vinkius and have the catalog from day one: GitHub, Slack, Notion, databases, internal APIs and more, already maintained and growing every day. You do not build integrations, you do not store tokens, you do not touch OAuth plumbing. Your users connect an account once, inside your product, and every agent turn just works from the first day you ship.

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, connection, and capability

vinkius.user('alice_123') and .connector('github') are handles. Creating them performs no request. Operations such as connect(), credentials.set(), capabilities() and execute() cross the network.

Two planes over one credential

The SDK is split into two planes over the same vk_app_sk_* credential:

• Control plane, provisioning and state: users, connectors, credentials, catalog.
• Execution plane, runtime: capabilities() and execute().

user.capabilities() is the primary contract: it returns the AI capabilities available to that user, as executable, framework-neutral objects. A connector is not a capability. A single connector can provide many capabilities:

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

User scope is part of the route

Every user operation is addressed by both your application credentials and the externalId passed by your backend. Two users can connect the same connector while keeping separate connection state and credentials.

Do not accept externalId as unrestricted client input. Resolve it from the session or verify that the caller is authorized to act for it before creating the handle. See Authentication and scope.

Capabilities are the execution boundary

A Capability contains a namespaced display name for model-facing lookup, a raw connector action name used for execution, a description and JSON Schema input contract, the connector and connection ID needed to route the request, and execute(args, { signal, idempotencyKey }):

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

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

An empty CapabilitySet is a normal result. Treat capability availability as runtime data rather than assuming every user has the same tools.

Adapters stay at the model boundary

Core capabilities do not depend on a model provider. Adapter subpaths map their names, descriptions and schemas into structural provider or framework shapes: OpenAI, Anthropic, Gemini, the Vercel AI SDK, LangChain, LlamaIndex, Cloudflare Workers AI and any OpenAI-compatible runtime. The adapter package has no runtime dependency on those external frameworks, so your application remains responsible for choosing and testing a compatible framework version. See Framework adapters.

Get started now

• npm: npmjs.com/package/@vinkius/connect
• GitHub: github.com/vinkius-labs/ai-connect-sdk, with runnable examples in the examples directory of the repository
• Issues: github.com/vinkius-labs/ai-connect-sdk/issues

Next steps

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