SDKs and CLI
Official TypeScript and Python SDKs plus the Weavz CLI for public API and agent workspace workflows.
SDKs and CLI
Weavz gives you official TypeScript and Python SDKs for backend integration work, plus a CLI for terminals, SSH sessions, containers, cloud IDEs, and coding agents.
For AI-native SaaS products, use the SDKs from your backend to create workspaces, add workspace integrations, register end users, generate connect URLs, create MCP servers, and mint scoped MCP bearer tokens for your agent harness. Use direct actions.execute() calls for backend-owned workflows, smoke tests, and non-MCP product flows.
Use the CLI when a developer, operator, or coding agent needs to sign in, inspect the current workspace, add or connect apps, search actions, validate inputs, execute a single action, or run Code Mode scripts through the hosted Weavz MCP connector.
| Tool | Use it for |
|---|---|
| TypeScript SDK | Node.js and TypeScript backends, framework adapters, compile-time integration/action names, and generated action input types |
| Python SDK | Python backends, agent frameworks, script-based workflows, and generated Pydantic action input validation |
| Weavz CLI | Interactive terminals, SSH sessions, containers, cloud IDEs, and coding agents that need workspace context, app management, direct action runs, or Code Mode execution |
Choose the Right Path
| Need | Best fit |
|---|---|
| Provision customers, tenants, end users, connect links, MCP servers, API keys, partials, approvals, and triggers from your product backend | REST API, TypeScript SDK, or Python SDK |
| Validate and execute known actions from backend jobs or product workflows | TypeScript SDK, Python SDK, or REST API |
| Give a custom agent harness a workspace-scoped MCP endpoint and per-user bearer token | SDK/API setup plus your MCP client runtime |
| Let a user or coding agent operate a Weavz workspace from a terminal | Weavz CLI |
| Connect Claude, ChatGPT, Codex, Cursor, or another hosted MCP client directly | Add to AI Client or Weavz MCP App |
Generated Integration Catalog
Both SDKs include generated integration action input coverage from the same integration registry used by the API and docs.
| Need | TypeScript | Python | Runtime API |
|---|---|---|---|
| List known integrations | integrationNames | INTEGRATION_ACTIONS.keys() | GET /api/v1/integrations |
| List actions for an integration | integrationActions.slack | get_action_names("slack") | GET /api/v1/integrations?name=slack |
| Type or validate action input | ActionInput<"slack", "send_channel_message"> | SlackSendChannelMessageInput or validate_action_input(...) | integration.actions[actionName].props metadata |
| Resolve dynamic dropdowns | typed client.integrations.resolveOptions(...) | client.integrations.resolve_options(...) | POST /api/v1/integrations/{name}/properties/options |
Use the generated SDK helpers when the integration/action is known at build time. Use the runtime Integrations API when you are building dynamic catalogs, configuration UIs, or supporting integrations released after your SDK version.
Shared Naming Model
The SDKs use the same conceptual fields as the API:
| Concept | REST / TypeScript | Python |
|---|---|---|
| Catalog integration slug | integrationName | integration_name |
| Workspace integration create alias | alias | integration_alias on workspace methods |
| Execution selector alias | integrationAlias | integration_alias |
| Exact configured integration selector | workspaceIntegrationId | workspace_integration_id |
| Connection selector | connectionExternalId | connection_external_id |
| End-user selector | endUserId | end_user_id |
Review Identifier Model and Integration Selectors before wiring multi-tenant or repeated-integration flows.