Files
composiohq__composio/ts
sdkrelease[bot] 9764ce33ff Release: update version (#3616)
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to next, this PR will
be updated.


# Releases
## @composio/core@0.12.0

### Minor Changes

- a0bef5d: Bump `@composio/client` to `0.1.0-alpha.74`.
- dfd7a08: Add per-request cancellation to public SDK methods via a new
`ComposioRequestOptions` (`{ signal?: AbortSignal }`) trailing argument,
plus a typed `ComposioRequestCancelledError` for detecting
caller-initiated aborts.

Without this, a slow `tools.get` or `tools.execute` had no way to be
cancelled — a 100s search would block the calling agent indefinitely.
The new shape:

  ```typescript
  try {
    const tools = await composio.tools.get(
      'user_1',
      { search: 'send email', limit: 50 },
      { signal: AbortSignal.timeout(5_000) }
    );
  } catch (err) {
    if (err instanceof ComposioRequestCancelledError) {
      return;
    }
    throw err;
  }
  ```

The signal is forwarded to the underlying `@composio/client` fetch. Any
abort error (`APIUserAbortError`, `AbortError`, or
`DOMException(name='AbortError')`) coming back is normalized to
`ComposioRequestCancelledError` so callers can `instanceof`-detect
cancellation without unwrapping nested causes. Catch-and-wrap paths in
`tools.execute` / `tools.getRawComposioToolBySlug` / `toolkits.get`
re-throw the cancellation error rather than remapping it to
`ComposioToolExecutionError` / `ComposioToolNotFoundError` /
`ComposioToolkitFetchError`.

  Wired through on:
- **Tools**: `get`, `getRawComposioTools`, `getRawComposioToolBySlug`,
`getRawToolRouterSessionTools`, `execute`, `executeSessionTool`,
`getToolsEnum`, `getInput`, `proxyExecute`
  - **Toolkits**: `get`, `listCategories`
- **AuthConfigs**: `list`, `create`, `get`, `update`, `delete`,
`updateStatus`, `enable`, `disable`
- **ConnectedAccounts**: `list`, `get`, `delete`, `refresh`,
`updateStatus`, `enable`, `disable`, `update`
- **Triggers**: `listActive`, `create`, `update`, `delete`, `enable`,
`disable`, `listTypes`, `getType`, `listEnum`
  - **MCP**: `create`, `list`, `get`, `delete`, `update`, `generate`
- **ToolRouter** (`composio.create` / `composio.use`,
`composio.toolRouter.create` / `.use`) — long-running session-creation
paths
- **ToolRouterSession**: `authorize`, `toolkits`, `search`, `execute`,
`proxyExecute`, `update`

  ### Custom-tool cooperative cancellation

Native tool execution is cancelled by the SDK (the underlying `fetch` is
aborted). Custom tools are different — the SDK can't preempt
user-supplied JavaScript. Two affordances are added so callers get
sensible behavior anyway:

1. **Pre-execute signal check**: if `signal.aborted` is true before the
user's `execute` runs, the SDK throws `ComposioRequestCancelledError`
and never invokes user code.
2. **Cooperative signal forwarding**: the same `AbortSignal` is exposed
via `SessionContext.signal` for Tool Router custom tools. Long-running
implementations can wire `ctx.signal` into their own `fetch` (or any
abortable IO) to abort mid-execution; the resulting `AbortError` is
normalized to `ComposioRequestCancelledError` by the SDK.

  ```typescript
  import { experimental_createTool } from '@composio/core';

const longRunningFetch = experimental_createTool('LONG_RUNNING_FETCH', {
    name: 'Long-running fetch',
    description: 'Fetches a URL with cooperative cancellation',
    inputParams: z.object({ url: z.string() }),
    execute: async (input, ctx) => {
// Pass ctx.signal into fetch so a session.execute(...) abort cancels
      // the in-flight HTTP request mid-flight.
      const resp = await fetch(input.url, { signal: ctx.signal });
      return { result: await resp.json() };
    },
  });
  ```

- 025a657: Drop CommonJS entrypoints and publish the TypeScript SDK
packages as ESM-only packages. This is a breaking change within the
existing 0.x release line: consumers must use Node.js 22.22.3 or newer.
CommonJS callers can only rely on Node's native `require(esm)` interop,
and the SDK no longer ships custom CommonJS compatibility machinery or
`.cjs` artifacts.
- 4b76dbf: Remove the deprecated `uuid` field from the auth config
retrieve/list response type.

The platform has removed the deprecated V1/V2 UUID-mirror field from V3
API responses (it was a mirror of the canonical nanoid `id`). The SDK no
longer reads or re-exposes `uuid` on `AuthConfigRetrieveResponse` (and
therefore on the items of `AuthConfigListResponse`).

This is technically a breaking change to the SDK response type:
consumers should use `id` instead of `uuid`. The `expectedInputFields`
field is unaffected — it remains a top-level field on the API response.

### Patch Changes

- 552859a: Expose `search` and `showDisabled` filters on
`authConfigs.list()`.
- 23f9053: Replace `chalk` with `picocolors` for colored error and log
output. The two render identically, but `picocolors` is a fraction of
the size (~0.8 kB gzipped vs chalk's much larger footprint), shrinking
the bundled package.
- 507318d: Add a provider-agnostic JSON-schema property-key sanitizer:
`sanitizeSchemaPropertyKeys(schema, policy)`,
`restoreOriginalKeys(value, mapping)`, `mappingHasRenames(mapping)`, and
the `KeyMapping` / `KeySanitizationPolicy` types.

Some providers constrain the characters and length of tool
`input_schema` property keys and reject the whole request on a single
violation. This utility rewrites offending keys to conforming aliases
(recursing through `properties`, array `items`/`prefixItems`, the
composition keywords `allOf`/`anyOf`/`oneOf` and
`not`/`if`/`then`/`else`, plus
`additionalProperties`/`patternProperties`/`$defs`/`contains`) and
records a schema-shaped reverse mapping so the original parameter names
can be restored before execution. The _constraint_ is injected as a
`KeySanitizationPolicy`, so the traversal, collision handling, prototype
safety, and depth cap stay provider-agnostic. The `@composio/anthropic`
provider now consumes it.

- 6a4cb54: Preserve root `$defs` / `definitions` blocks on tool
parameter schemas and dereference them in the Node file modifier, so
auto file upload/download detection works when `file_uploadable` or
`file_downloadable` is hidden behind an internal `$ref`.
- cbbad15: Improve Zod compatibility at the SDK schema boundary. Custom
tools now convert both `zod/v3` and Zod v4 schemas to JSON Schema
correctly instead of degrading Zod v4 object schemas to empty schemas.
`@composio/core` now exposes `jsonSchemaToZodShape` via
`@composio/core/utils/json-schema`, and the Claude Agent SDK provider
uses that core subpath instead of converting to a full Zod object and
casting `.shape` out of it.
- Updated dependencies [025a657]
  - @composio/json-schema-to-zod@0.2.0
## @composio/json-schema-to-zod@0.2.0

### Minor Changes

- 025a657: Drop CommonJS entrypoints and publish the TypeScript SDK
packages as ESM-only packages. This is a breaking change within the
existing 0.x release line: consumers must use Node.js 22.22.3 or newer.
CommonJS callers can only rely on Node's native `require(esm)` interop,
and the SDK no longer ships custom CommonJS compatibility machinery or
`.cjs` artifacts.
## @composio/anthropic@0.10.0

### Minor Changes

- 025a657: Drop CommonJS entrypoints and publish the TypeScript SDK
packages as ESM-only packages. This is a breaking change within the
existing 0.x release line: consumers must use Node.js 22.22.3 or newer.
CommonJS callers can only rely on Node's native `require(esm)` interop,
and the SDK no longer ships custom CommonJS compatibility machinery or
`.cjs` artifacts.

### Patch Changes

- 507318d: Harden the Anthropic tool property-key sanitizer:

- **Broader schema coverage.** Illegal keys are now sanitized wherever
they appear in a tool schema — under the composition keywords
(`allOf`/`anyOf`/`oneOf`, `not`/`if`/`then`/`else`), `prefixItems`
tuples, `additionalProperties`/`patternProperties`, and
`$defs`/`definitions` — not just top-level `properties` and array
`items`. Previously a single illegal key under one of these would still
400 the entire request. Renames inside composition keywords are restored
correctly (they fold into the value level they share).
- **`$ref` keys restored.** `wrapTool` now dereferences internal
`$ref`/`$defs` (leniently — a dangling ref degrades to a permissive
schema instead of throwing) before sanitizing, so keys reachable only
through a reference are both made compliant and restored. Only genuinely
dynamic positions (`additionalProperties`, `patternProperties`,
`contains`) remain rewrite-only.
- **Shared core implementation.** The traversal/restoration mechanism
now lives in `@composio/core` (`sanitizeSchemaPropertyKeys` /
`restoreOriginalKeys`); this provider supplies only the Anthropic key
constraint as a policy, reusing core's prototype-pollution guard and
depth cap.
- **Prototype-safe key restoration.** Reverse-mapping lookups and the
rebuilt argument object are now prototype-free, so a tool call whose
arguments use a key matching an `Object.prototype` member (`__proto__`,
`constructor`, `toString`, `hasOwnProperty`, …) no longer throws or
silently corrupts the payload sent to the backend. `Object.prototype` is
never mutated.
- **Depth cap.** Schema sanitization and key restoration now bound
recursion (matching core's JSON-schema walker) so a pathologically deep
schema or argument object fails with a clear error instead of
overflowing the stack.
- **Empty / all-illegal keys.** A property key that is empty (or made
entirely of stripped characters) now becomes a deterministic non-empty
alias instead of an empty string, which would itself have violated
Anthropic's `{1,64}` length bound.
- **Collision loop.** Replaced a latent non-terminating fixed point in
the alias collision resolver with a counter that always makes progress.
- **Observability.** The provider now emits `debug` logs when it
rewrites a tool's schema keys and when it restores them at execution
time, and the wrap-then-execute (same provider instance) contract for
key restoration is documented.

- c90ae95: Sanitize tool `input_schema` property keys that violate
Anthropic's `^[a-zA-Z0-9_.-]{1,64}$` constraint before sending tools to
the Messages API, then restore the original names when the tool is
executed.

A single non-conforming key previously made Anthropic reject the entire
`tools` array with HTTP 400, taking down every other tool in the same
request. This commonly happened with OneDrive's Microsoft Graph OData
parameters (`$top`, `$filter`, `@microsoft.graph.conflictBehavior`) and
with over-long flattened keys from tools such as Zoom. Offending keys
are now rewritten to conforming aliases (`$` → `dollar_`, `@` → `at_`,
any other illegal character → `_`, keys longer than 64 characters
truncated with a deterministic suffix), recursing through nested object
`properties` and array `items` schemas. The original parameter names are
restored before the call reaches the Composio backend, so the model sees
`dollar_top` while the backend still receives `$top`. Schemas whose keys
already conform are left unchanged.
## @composio/claude-agent-sdk@0.10.0

### Minor Changes

- 025a657: Drop CommonJS entrypoints and publish the TypeScript SDK
packages as ESM-only packages. This is a breaking change within the
existing 0.x release line: consumers must use Node.js 22.22.3 or newer.
CommonJS callers can only rely on Node's native `require(esm)` interop,
and the SDK no longer ships custom CommonJS compatibility machinery or
`.cjs` artifacts.

### Patch Changes

- cbbad15: Improve Zod compatibility at the SDK schema boundary. Custom
tools now convert both `zod/v3` and Zod v4 schemas to JSON Schema
correctly instead of degrading Zod v4 object schemas to empty schemas.
`@composio/core` now exposes `jsonSchemaToZodShape` via
`@composio/core/utils/json-schema`, and the Claude Agent SDK provider
uses that core subpath instead of converting to a full Zod object and
casting `.shape` out of it.
## @composio/cloudflare@0.10.0

### Minor Changes

- 025a657: Drop CommonJS entrypoints and publish the TypeScript SDK
packages as ESM-only packages. This is a breaking change within the
existing 0.x release line: consumers must use Node.js 22.22.3 or newer.
CommonJS callers can only rely on Node's native `require(esm)` interop,
and the SDK no longer ships custom CommonJS compatibility machinery or
`.cjs` artifacts.
## @composio/google@0.10.0

### Minor Changes

- 025a657: Drop CommonJS entrypoints and publish the TypeScript SDK
packages as ESM-only packages. This is a breaking change within the
existing 0.x release line: consumers must use Node.js 22.22.3 or newer.
CommonJS callers can only rely on Node's native `require(esm)` interop,
and the SDK no longer ships custom CommonJS compatibility machinery or
`.cjs` artifacts.
## @composio/langchain@0.10.0

### Minor Changes

- 025a657: Drop CommonJS entrypoints and publish the TypeScript SDK
packages as ESM-only packages. This is a breaking change within the
existing 0.x release line: consumers must use Node.js 22.22.3 or newer.
CommonJS callers can only rely on Node's native `require(esm)` interop,
and the SDK no longer ships custom CommonJS compatibility machinery or
`.cjs` artifacts.
## @composio/llamaindex@0.10.0

### Minor Changes

- 025a657: Drop CommonJS entrypoints and publish the TypeScript SDK
packages as ESM-only packages. This is a breaking change within the
existing 0.x release line: consumers must use Node.js 22.22.3 or newer.
CommonJS callers can only rely on Node's native `require(esm)` interop,
and the SDK no longer ships custom CommonJS compatibility machinery or
`.cjs` artifacts.
## @composio/mastra@0.10.0

### Minor Changes

- 025a657: Drop CommonJS entrypoints and publish the TypeScript SDK
packages as ESM-only packages. This is a breaking change within the
existing 0.x release line: consumers must use Node.js 22.22.3 or newer.
CommonJS callers can only rely on Node's native `require(esm)` interop,
and the SDK no longer ships custom CommonJS compatibility machinery or
`.cjs` artifacts.

### Patch Changes

- aaabf5e: Relax the Mastra provider output schema so real third-party
API responses are no longer rejected by Mastra's output validation
(which dropped the data and substituted an error). Before compilation
the output schema is made lenient: every typed node becomes nullable,
objects allow extra keys (`additionalProperties: true`), `enum`/`const`
are widened to also admit `null`, and `required` is dropped (APIs omit
unset fields rather than returning `null` for them). All of these only
widen what validates, so previously-valid output is unaffected.
## @composio/openai@0.10.0

### Minor Changes

- 025a657: Drop CommonJS entrypoints and publish the TypeScript SDK
packages as ESM-only packages. This is a breaking change within the
existing 0.x release line: consumers must use Node.js 22.22.3 or newer.
CommonJS callers can only rely on Node's native `require(esm)` interop,
and the SDK no longer ships custom CommonJS compatibility machinery or
`.cjs` artifacts.
## @composio/openai-agents@0.10.0

### Minor Changes

- 025a657: Drop CommonJS entrypoints and publish the TypeScript SDK
packages as ESM-only packages. This is a breaking change within the
existing 0.x release line: consumers must use Node.js 22.22.3 or newer.
CommonJS callers can only rely on Node's native `require(esm)` interop,
and the SDK no longer ships custom CommonJS compatibility machinery or
`.cjs` artifacts.
## @composio/vercel@0.10.0

### Minor Changes

- 025a657: Drop CommonJS entrypoints and publish the TypeScript SDK
packages as ESM-only packages. This is a breaking change within the
existing 0.x release line: consumers must use Node.js 22.22.3 or newer.
CommonJS callers can only rely on Node's native `require(esm)` interop,
and the SDK no longer ships custom CommonJS compatibility machinery or
`.cjs` artifacts.
## @composio/ts-builders@0.2.0

### Minor Changes

- 025a657: Drop CommonJS entrypoints and publish the TypeScript SDK
packages as ESM-only packages. This is a breaking change within the
existing 0.x release line: consumers must use Node.js 22.22.3 or newer.
CommonJS callers can only rely on Node's native `require(esm)` interop,
and the SDK no longer ships custom CommonJS compatibility machinery or
`.cjs` artifacts.
## @composio/cli@0.3.0

### Minor Changes

- a0bef5d: Bump `@composio/client` to `0.1.0-alpha.74`.
- 025a657: Drop CommonJS entrypoints and publish the TypeScript SDK
packages as ESM-only packages. This is a breaking change within the
existing 0.x release line: consumers must use Node.js 22.22.3 or newer.
CommonJS callers can only rely on Node's native `require(esm)` interop,
and the SDK no longer ships custom CommonJS compatibility machinery or
`.cjs` artifacts.

### Patch Changes

- 5f004ff: Drop `COMPOSIO_UPSERT_RECIPE` and `COMPOSIO_GET_RECIPE` from
the CLI meta-tool list. These slugs were removed from `@composio/client`
(alpha.74), so listing them broke the type-checked CLI build.
- 23f9053: Remove the unused `ansis` dependency from the CLI. Colored
output is already handled by `picocolors`, so `ansis` was a dead
production dependency that shipped with the package.
- 446c6f6: Fix virtual TypeScript file resolution used by CLI type
generation so in-memory imports resolve consistently during
transpilation and validation.
- Updated dependencies [552859a]
- Updated dependencies [a0bef5d]
- Updated dependencies [23f9053]
- Updated dependencies [dfd7a08]
- Updated dependencies [507318d]
- Updated dependencies [025a657]
- Updated dependencies [6a4cb54]
- Updated dependencies [4b76dbf]
- Updated dependencies [cbbad15]
  - @composio/core@0.12.0
  - @composio/json-schema-to-zod@0.2.0
  - @composio/ts-builders@0.2.0
  - @composio/cli-keyring@0.2.0
  - @composio/cli-local-tools@0.1.0
## @composio/cli-keyring@0.2.0

### Minor Changes

- 025a657: Drop CommonJS entrypoints and publish the TypeScript SDK
packages as ESM-only packages. This is a breaking change within the
existing 0.x release line: consumers must use Node.js 22.22.3 or newer.
CommonJS callers can only rely on Node's native `require(esm)` interop,
and the SDK no longer ships custom CommonJS compatibility machinery or
`.cjs` artifacts.
## @composio/cli-local-tools@0.1.0

### Minor Changes

- 025a657: Drop CommonJS entrypoints and publish the TypeScript SDK
packages as ESM-only packages. This is a breaking change within the
existing 0.x release line: consumers must use Node.js 22.22.3 or newer.
CommonJS callers can only rely on Node's native `require(esm)` interop,
and the SDK no longer ships custom CommonJS compatibility machinery or
`.cjs` artifacts.

### Patch Changes

- Updated dependencies [552859a]
- Updated dependencies [a0bef5d]
- Updated dependencies [23f9053]
- Updated dependencies [dfd7a08]
- Updated dependencies [507318d]
- Updated dependencies [025a657]
- Updated dependencies [6a4cb54]
- Updated dependencies [4b76dbf]
- Updated dependencies [cbbad15]
  - @composio/core@0.12.0

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
2026-06-25 04:38:11 +04:00
..
2026-06-25 04:38:11 +04:00

Composio SDK v3

The Composio SDK is a powerful toolkit that enables you to integrate third-party tools and services into your applications. It helps you connect to various services (toolkits), execute tools, and manage user connections seamlessly.

Features

  • Execute tools from various services (GitHub, Gmail, Slack, etc.)
  • Manage user connections to external services
  • Create session-scoped custom tools with your own logic
  • Integrate with AI providers like OpenAI
  • Powerful middleware and modifier support
  • Extensive error handling

Documentation

The SDK is thoroughly documented in the docs directory:

API Reference

Provider Documentation

Advanced Topics

Internal Documentation

For SDK maintainers and contributors:

Installation

# Using npm
npm install @composio/core

# Using yarn
yarn add @composio/core

# Using pnpm
pnpm add @composio/core

Quick Start

import { Composio } from '@composio/core';

// Initialize the SDK
const composio = new Composio({
  apiKey: 'your-api-key',
});

// Get tools from a specific toolkit
const tools = await composio.tools.get('default', {
  toolkits: ['github'],
});

// Get a specific tool
const specificTool = await composio.tools.get('default', 'GITHUB_GET_REPOS');

// Execute a tool
const result = await composio.tools.execute('GITHUB_GET_REPO', {
  userId: 'default',
  arguments: {
    owner: 'composio',
    repo: 'sdk',
  },
});

console.log(result.data);

OpenAI Integration

import { Composio } from '@composio/core';
import OpenAI from 'openai';

// Initialize Composio and OpenAI
const composio = new Composio({
  apiKey: 'your-composio-api-key',
});

const openai = new OpenAI({
  apiKey: 'your-openai-api-key',
});

// Get GitHub tools
const tools = await composio.tools.get('default', {
  toolkits: ['github'],
});


// Create a chat completion with the tools
const completion = await openai.chat.completions.create({
  model: 'gpt-4',
  messages: [
    { role: 'system', content: 'You are a helpful assistant with access to GitHub tools.' },
    { role: 'user', content: 'Find information about the Composio SDK repository' },
  ],
  tools, // Pass the tools to OpenAI
});

// If the model wants to use a tool
if (completion.choices[0].message.tool_calls) {
  const toolCall = completion.choices[0].message.tool_calls[0];
  const args = JSON.parse(toolCall.function.arguments);

  // Execute the tool
  const result = await composio.tools.execute(toolCall.function.name, {
    userId: 'default',
    arguments: args,
  });

  console.log(result.data);
}

Creating Custom Tools

import { Composio, experimental_createTool } from '@composio/core';
import { z } from 'zod';

const composio = new Composio({ apiKey: process.env.COMPOSIO_API_KEY });

const weatherForecast = experimental_createTool('WEATHER_FORECAST', {
  name: 'Weather Forecast',
  description: 'Get the weather forecast for a location',
  inputParams: z.object({
    location: z.string().describe('The location to get the forecast for'),
    days: z.number().optional().default(3).describe('Number of days for the forecast'),
  }),
  execute: async (input) => {
    const { location, days = 3 } = input;
    const forecast = await getWeatherForecast(location, days);
    return { forecast };
  },
});

const session = await composio.create('default', {
  experimental: { customTools: [weatherForecast] },
});

const result = await session.execute('WEATHER_FORECAST', {
  location: 'San Francisco, CA',
});

Project Structure

composio/
├── packages/                  # Main packages directory
│   ├── core/                  # Core SDK package
│   └── providers/             # Provider implementations
├── examples/                  # Example implementations
│   ├── connected-accounts/    # Connected accounts examples
│   ├── langchain/            # LangChain integration examples
│   ├── openai/               # OpenAI integration examples
│   ├── modifiers/            # Modifiers examples
│   ├── toolkits/             # Toolkits examples
│   └── vercel/               # Vercel AI examples
├── docs/                      # Documentation
├── scripts/                   # Development and build scripts
└── .github/                   # GitHub configuration

Development Setup

  1. Prerequisites

    • Node.js (Latest LTS version recommended)
    • pnpm (v10.8.0 or later)
    • bun for productivity (optional)
  2. Clone and Install

    git clone https://github.com/ComposioHQ/sdk-v3-ts.git
    cd composio
    pnpm install
    
  3. Build

    pnpm build
    
  4. Development Commands

    # Lint code
    pnpm lint
    
    # Fix linting issues
    pnpm lint:fix
    
    # Format code
    pnpm format
    
    # Create a new provider
    pnpm create:provider <provider-name> [--agentic]
    
    # Create a new example
    pnpm create:example <example-name>
    
    # Check peer dependencies
    pnpm check:peer-deps
    
    # Update peer dependencies
    pnpm update:peer-deps
    

Creating a New Example

  1. Use the create:example script:

    pnpm create:example my-example
    
  2. The script will create a new example in examples/my-example with:

    • package.json with minimal dependencies (@composio/core and dotenv)
    • tsconfig.json for TypeScript configuration
    • .env.example and .env files for environment variables
    • src/index.ts with basic Composio SDK setup
    • README.md with setup and usage instructions
    • Dependencies automatically installed
  3. Next steps after creation:

    • Edit .env and add your COMPOSIO_API_KEY
    • Customize src/index.ts with your example logic
    • Add any additional dependencies as needed
    • Run with pnpm start or pnpm dev (with file watching)

Creating a New Provider

  1. Use the create:provider script:

    pnpm create:provider my-provider [--agentic]
    
  2. The script will create a new provider in packages/providers/my-provider with:

    • Basic provider implementation
    • TypeScript configuration
    • Package configuration
    • README template
  3. Implement the required methods in src/index.ts:

    • For non-agentic providers: wrapTool and wrapTools
    • For agentic providers: wrapTool, wrapTools, and execution handlers

Release Process

For detailed information about both automated and manual release processes, please refer to our Release Process Documentation.

Environment Variables

  • COMPOSIO_API_KEY: Your Composio API key
  • COMPOSIO_BASE_URL: Custom API base URL (optional)
  • COMPOSIO_LOG_LEVEL: Logging level (silent, error, warn, info, debug)
  • COMPOSIO_DISABLE_TELEMETRY: Disable telemetry when set to "true"
  • COMPOSIO_TOOLKIT_VERSION_<TOOLKIT_NAME>: Specific version for a toolkit (e.g., COMPOSIO_TOOLKIT_VERSION_GITHUB=20250902_00)
  • DEVELOPMENT: Development mode flag
  • CI: CI environment flag

Contributing

We welcome contributions! Please see our Contributing Guide for more details.

License

ISC License

Support

For support, please visit our Documentation or join our Discord Community.