Connectors

Connect, don't install. A connector lets the assistant read and act in a system your users already use — with one OAuth grant and nothing else to set up.

How it works

• You declare it. Your manifest lists the connectors your tool needs — the provider and the OAuth scopes. See the
  Nextmanifest reference →
  .
• The user grants it once. The first time your tool needs a connector, Stevai walks the user through a single OAuth grant. That's the only setup they ever do.
• Stevai brokers & stores it. The OAuth token is stored in Stevai's connection vault, encrypted at rest (AES‑256‑GCM). It is never given to your tool.
• Calls are mediated. When your tool calls ctx.connections.call(...), Stevai attaches the user's authorized token and enforces the granted scopes. You never handle the user's credentials.

Declare the connector

"connections": [
  { "id": "gmail", "provider": "google", "scopes": ["gmail.readonly"], "label": "Gmail" }
]

Use it — and prompt for the grant when needed

export default async function run(_input: unknown, ctx: ToolContext) {
  if (!ctx.connections.has("gmail")) {
    return { needsConnection: "gmail" }; // Stevai prompts the user for the one-time OAuth
  }
  const inbox = await ctx.connections.call("gmail", { method: "GET", path: "/messages?limit=20" });
  // ...use ctx.ai to reason over it. The token is never exposed to your tool.
}

The security model

Connectors are higher‑risk by nature — they reach out to real systems and act on real data — so a connector always gets a certified human review before it publishes. The token vault is zero‑knowledge‑aligned: encrypted with the same master key as identity, read only server‑side to attach to a mediated call, and wiped on revoke. The user owns the grant and can revoke it at any time; the developer never sees it.