Documentation

Duct Documentation

Build one permissioned product surface for humans and agents. Start with the quickstart, then wire actions, auth, embedding, and API access in the language your system already uses.

SDK & CLI — start here

Most integrations begin with four commands. Run them from your product repo root (Node.js 20+).

$ npx @duct-sdk/sdk login
$ npx @duct-sdk/sdk init --manual
$ npx @duct-sdk/sdk push
$ npx @duct-sdk/sdk checkup

Full CLI reference →

@duct-sdk/sdk

Official npm package — CLI, typed manifest helpers, and framework adapters for Node.js 20+.

$ npm i @duct-sdk/sdk

Duct is not TypeScript-only

The published SDK is TypeScript/JavaScript because it ships the CLI and web adapters. Your backend can be Python, Go, Ruby, Java, PHP, .NET, or anything else that can expose HTTP endpoints and verify JWTs. Agents can call Duct through REST with curl, Python, JavaScript, or any HTTP client.

Recommended Path

What You Build

A Duct integration has four moving parts: a manifest that describes your product capabilities, a small widget embed, token endpoints for user-aware actions, and optional agent API calls for automation.

Common Questions

How does shell-to-shell work?

Open discovery via capability search. Your user's message triggers a network search; the user consents in-chat before any cross-shell action runs. No pre-configuration between companies required. See the Inter-Shell Protocol docs for details.

Can any shell call mine?

Only if you set registry_visibility: 'public' and intershell_enabled: true. By default shells are private. You can further restrict with allowedCallers to limit inbound calls to a specific list of shell IDs.

If I add side effects to an existing action, is fresh consent required?

Yes — always, on the next invocation. Changing sideEffects from false to true means the action now requires confirmation every time it runs. Prior read-only calls in the same chat do not count as consent. See manifest versions & side-effect changes.