Changelog

Latest updates and announcements

Tool Router Improvements and New Features

Version Information

TypeScript/JavaScript

  • Package: @composio/core and provider packages
  • Version: 0.3.4 to 0.4.0

Python

  • Package: composio-core and provider packages
  • Version: 0.10.4 to 0.10.5

New Features

1. Wait for Connections Property

Added waitForConnections (TypeScript) / wait_for_connections (Python) property to manage connections configuration. This allows tool router sessions to wait for users to complete authentication before proceeding to the next step.

TypeScript:

const const session: ToolRouterSession<unknown, unknown, OpenAIProvider>session = await const composio: Composio<OpenAIProvider>composio.Composio<OpenAIProvider>.toolRouter: ToolRouter<unknown, unknown, OpenAIProvider>
Experimental feature, use with caution
@experimental
toolRouter
.ToolRouter<unknown, unknown, OpenAIProvider>.create(userId: string, config?: ToolRouterCreateSessionConfig): Promise<ToolRouterSession<unknown, unknown, OpenAIProvider>>
Creates a new tool router session for a user.
@paramuserId The user id to create the session for@paramconfig The config for the tool router session@returnsThe tool router session@example```typescript import { Composio } from '@composio/core'; const composio = new Composio(); const userId = 'user_123'; const session = await composio.experimental.create(userId, { toolkits: ['gmail'], manageConnections: true, tools: { gmail: { disabled: ['gmail_send_email'] } }, tags: ['readOnlyHint'] }); console.log(session.sessionId); console.log(session.mcp.url); // Get tools formatted for your framework (requires provider) const tools = await session.tools(); // Check toolkit connection states const toolkits = await session.toolkits(); ```
create
(const userId: "user_123"userId, {
manageConnections?: boolean | {
    callbackUrl?: string | undefined;
    enable?: boolean | undefined;
    waitForConnections?: boolean | undefined;
} | undefined
manageConnections
: {
enable?: boolean | undefinedenable: true, callbackUrl?: string | undefinedcallbackUrl: 'https://example.com/callback', waitForConnections?: boolean | undefinedwaitForConnections: true // NEW } });

Python:

session = tool_router.create(
    user_id="user_123",
    manage_connections={
        "enable": True,
        "callback_url": "https://example.com/callback",
        "wait_for_connections": True  # NEW
    }
)

2. Session-Specific Modifier Types

Introduced new modifier types for better session-based tool execution: SessionExecuteMetaModifiers and SessionMetaToolOptions.

TypeScript:

const const tools: OpenAiToolCollectiontools = await const session: ToolRouterSession<unknown, unknown, OpenAIProvider>session.ToolRouterSession<unknown, unknown, OpenAIProvider>.tools: (modifiers?: SessionMetaToolOptions) => Promise<OpenAiToolCollection>
Get the tools available in the session, formatted for your AI framework. Requires a provider to be configured in the Composio constructor.
tools
({
modifySchema?: TransformToolSchemaModifier | undefined
Function to transform tool schemas before they're exposed to consumers. This allows customizing input/output parameters, descriptions, and other metadata.
modifySchema
: ({ toolSlug: stringtoolSlug, toolkitSlug: stringtoolkitSlug,
schema: {
    slug: string;
    name: string;
    description?: string | undefined;
    inputParameters?: {
        type: "object";
        properties: Record<string, any>;
        description?: string | undefined;
        anyOf?: any[] | undefined;
        oneOf?: any[] | undefined;
        allOf?: any[] | undefined;
        not?: any;
        required?: string[] | undefined;
        title?: string | undefined;
        default?: any;
        nullable?: boolean | undefined;
        additionalProperties?: boolean | undefined;
    } | undefined;
    outputParameters?: {
        type: "object";
        properties: Record<string, any>;
        description?: string | undefined;
        anyOf?: any[] | undefined;
        oneOf?: any[] | undefined;
        allOf?: any[] | undefined;
        not?: any;
        required?: string[] | undefined;
        title?: string | undefined;
        default?: any;
        nullable?: boolean | undefined;
        additionalProperties?: boolean | undefined;
    } | undefined;
    ... 6 more ...;
    isNoAuth?: boolean | undefined;
}
schema
}) =>
schema: {
    slug: string;
    name: string;
    description?: string | undefined;
    inputParameters?: {
        type: "object";
        properties: Record<string, any>;
        description?: string | undefined;
        anyOf?: any[] | undefined;
        oneOf?: any[] | undefined;
        allOf?: any[] | undefined;
        not?: any;
        required?: string[] | undefined;
        title?: string | undefined;
        default?: any;
        nullable?: boolean | undefined;
        additionalProperties?: boolean | undefined;
    } | undefined;
    outputParameters?: {
        type: "object";
        properties: Record<string, any>;
        description?: string | undefined;
        anyOf?: any[] | undefined;
        oneOf?: any[] | undefined;
        allOf?: any[] | undefined;
        not?: any;
        required?: string[] | undefined;
        title?: string | undefined;
        default?: any;
        nullable?: boolean | undefined;
        additionalProperties?: boolean | undefined;
    } | undefined;
    ... 6 more ...;
    isNoAuth?: boolean | undefined;
}
schema
,
beforeExecute?: beforeExecuteMetaModifier | undefined
Function to intercept and modify meta tool execution parameters before the tool is executed. This allows customizing the request based on session-specific needs.
beforeExecute
: ({ toolSlug: stringtoolSlug, toolkitSlug: stringtoolkitSlug, sessionId: stringsessionId, params: Record<string, unknown>params }) => params: Record<string, unknown>params,
afterExecute?: afterExecuteMetaModifier | undefined
Function to intercept and modify meta tool execution responses after the tool has executed. This allows transforming the response or implementing custom session-specific handling.
afterExecute
: ({ toolSlug: stringtoolSlug, toolkitSlug: stringtoolkitSlug, sessionId: stringsessionId,
result: {
    error: string | null;
    data: Record<string, unknown>;
    successful: boolean;
    logId?: string | undefined;
    sessionInfo?: unknown;
}
result
}) =>
result: {
    error: string | null;
    data: Record<string, unknown>;
    successful: boolean;
    logId?: string | undefined;
    sessionInfo?: unknown;
}
result
});

Python:

from composio.core.models import before_execute_meta, after_execute_meta

@before_execute_meta
def before_modifier(tool, toolkit, session_id, params):
    return params

@after_execute_meta
def after_modifier(tool, toolkit, session_id, response):
    return response

tools = session.tools(modifiers=[before_modifier, after_modifier])

3. Dedicated Method for Tool Router Meta Tools

Added getRawToolRouterMetaTools (TypeScript) / get_raw_tool_router_meta_tools (Python) method in the Tools class for fetching meta tools directly from a tool router session.

TypeScript:

const const metaTools: ToolListmetaTools = await const composio: Composio<OpenAIProvider>composio.Composio<OpenAIProvider>.tools: Tools<unknown, unknown, OpenAIProvider>
List, retrieve, and execute tools
tools
.Tools<unknown, unknown, OpenAIProvider>.getRawToolRouterMetaTools(sessionId: string, options?: SchemaModifierOptions): Promise<ToolList>
Fetches the meta tools for a tool router session. This method fetches the meta tools from the Composio API and transforms them to the expected format. It provides access to the underlying meta tool data without provider-specific wrapping.
@paramsessionId The session id to get the meta tools for@paramoptions Optional configuration for tool retrieval@paramoptions.modifySchema - Function to transform the tool schema@returnsThe list of meta tools@example```typescript const metaTools = await composio.tools.getRawToolRouterMetaTools('session_123'); console.log(metaTools); ```
getRawToolRouterMetaTools
('session_123', {
modifySchema: TransformToolSchemaModifiermodifySchema: ({ toolSlug: stringtoolSlug, toolkitSlug: stringtoolkitSlug,
schema: {
    slug: string;
    name: string;
    description?: string | undefined;
    inputParameters?: {
        type: "object";
        properties: Record<string, any>;
        description?: string | undefined;
        anyOf?: any[] | undefined;
        oneOf?: any[] | undefined;
        allOf?: any[] | undefined;
        not?: any;
        required?: string[] | undefined;
        title?: string | undefined;
        default?: any;
        nullable?: boolean | undefined;
        additionalProperties?: boolean | undefined;
    } | undefined;
    outputParameters?: {
        type: "object";
        properties: Record<string, any>;
        description?: string | undefined;
        anyOf?: any[] | undefined;
        oneOf?: any[] | undefined;
        allOf?: any[] | undefined;
        not?: any;
        required?: string[] | undefined;
        title?: string | undefined;
        default?: any;
        nullable?: boolean | undefined;
        additionalProperties?: boolean | undefined;
    } | undefined;
    ... 6 more ...;
    isNoAuth?: boolean | undefined;
}
schema
}) => {
// Customize schema return
schema: {
    slug: string;
    name: string;
    description?: string | undefined;
    inputParameters?: {
        type: "object";
        properties: Record<string, any>;
        description?: string | undefined;
        anyOf?: any[] | undefined;
        oneOf?: any[] | undefined;
        allOf?: any[] | undefined;
        not?: any;
        required?: string[] | undefined;
        title?: string | undefined;
        default?: any;
        nullable?: boolean | undefined;
        additionalProperties?: boolean | undefined;
    } | undefined;
    outputParameters?: {
        type: "object";
        properties: Record<string, any>;
        description?: string | undefined;
        anyOf?: any[] | undefined;
        oneOf?: any[] | undefined;
        allOf?: any[] | undefined;
        not?: any;
        required?: string[] | undefined;
        title?: string | undefined;
        default?: any;
        nullable?: boolean | undefined;
        additionalProperties?: boolean | undefined;
    } | undefined;
    ... 6 more ...;
    isNoAuth?: boolean | undefined;
}
schema
;
} });

Python:

meta_tools = tools_model.get_raw_tool_router_meta_tools(
    session_id="session_123",
    modifiers=[schema_modifier]
)

Internal Improvements

1. Performance Optimization

Eliminated unnecessary tool fetching during tool router execution, resulting in faster tool execution with fewer API calls.

2. Improved Architecture

Tool router sessions now fetch tools directly from the session API endpoint instead of using tool slugs, providing better consistency and reliability.

3. Simplified Implementation

Removed redundant tool schema fetching in execution paths, using a hardcoded 'composio' toolkit slug for meta tools.

Backward Compatibility

This release is fully backward compatible:

  • All existing code continues to work without modifications
  • New properties are optional with sensible defaults
  • New modifier types can be adopted incrementally
  • Internal changes have no impact on public APIs
  • No migration required

Impact Summary

ChangeRuntime BreakingTypeScript BreakingMigration Required
wait_for_connections propertyNoNoNo
Session-specific modifiersNoNoNo
getRawToolRouterMetaTools methodNoNoNo
Tool router uses session APINoNoNo
Optimized tool executionNoNoNo

All changes follow semantic versioning principles and maintain full backward compatibility.

Tool Enum Name Shortening

Shortened tool enum names across 181 actions to ensure compatibility with all AI agent frameworks.

Why This Change?

Some agent frameworks have a 64-character limit on tool/function names. Several tool enums exceeded this limit, causing compatibility issues.

No Action Required

This change will not break your integration if you are using latest toolkit versions or fetching tools dynamically. The SDK automatically resolves the correct tool names.

Migration

If you're referencing any affected tool enums by their old names, update to the new shortened names.

Optional API Key Enforcement for MCP Servers

We've introduced a new project-level security setting that allows you to require API key authentication for all MCP server requests. This opt-in feature gives you fine-grained control over who can access your MCP endpoints.

Opt-in today, default soon: This feature is currently opt-in. Starting March 1, 2026, it will be enabled by default for new organizations. We recommend enabling it now to prepare your integrations.

What's New

A new "Require API Key for MCP" toggle is now available in your Project Settings. When enabled, all requests to your MCP servers must include a valid Composio API key in the request headers.

SettingDefaultImpact
require_mcp_api_keyfalseOpt-in; no changes to existing behavior

How It Works

When the setting is disabled (default):

  • MCP servers work without API key authentication
  • Existing integrations continue to function unchanged

When the setting is enabled:

  • All MCP requests must include the x-api-key header with a valid Composio API key
  • Requests without a valid API key receive 401 Unauthorized
  • Only API keys belonging to the same project are accepted

Request Examples

Without API key (when enforcement is enabled):

curl -X POST "https://mcp.composio.dev/{your_mcp_server_url}" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize"}'

# Response: 401 Unauthorized

With API key:

curl -X POST "https://mcp.composio.dev/{your_mcp_server_url}" \
  -H "Content-Type: application/json" \
  -H "x-api-key: ak_your_api_key" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize"}'

# Response: 200 OK

Enabling the Setting

Via Dashboard

  1. Navigate to Project Settings
  2. Go to the Project Configuration tab
  3. Find the "Require API Key for MCP" toggle
  4. Enable the toggle

Via API

Update your project configuration using the API:

curl -X PATCH "https://backend.composio.dev/api/v3/org/project/config" \
  -H "Content-Type: application/json" \
  -H "x-api-key: ak_your_api_key" \
  -d '{"require_mcp_api_key": true}'

Response:

{
  "require_mcp_api_key": true,
  "is_2FA_enabled": true,
  "mask_secret_keys_in_connected_account": true,
  "log_visibility_setting": "show_all"
}

Via Code

Python
import requests

response = requests.patch(
    "https://backend.composio.dev/api/v3/org/project/config",
    headers={
        "Content-Type": "application/json",
        "x-api-key": "ak_your_api_key"
    },
    json={"require_mcp_api_key": True}
)

print(response.json())
TypeScript
const const response: Responseresponse = await function fetch(input: string | URL | Request, init?: RequestInit): Promise<Response> (+1 overload)
[MDN Reference](https://developer.mozilla.org/docs/Web/API/Window/fetch)
fetch
(
"https://backend.composio.dev/api/v3/org/project/config", { RequestInit.method?: string | undefined
A string to set request's method.
method
: "PATCH",
RequestInit.headers?: HeadersInit | undefined
A Headers object, an object literal, or an array of two-item arrays to set request's headers.
headers
: {
"Content-Type": "application/json", "x-api-key": "ak_your_api_key" }, RequestInit.body?: BodyInit | null | undefined
A BodyInit object or null to set request's body.
body
: var JSON: JSON
An intrinsic object that provides functions to convert JavaScript values to and from the JavaScript Object Notation (JSON) format.
JSON
.JSON.stringify(value: any, replacer?: (this: any, key: string, value: any) => any, space?: string | number): string (+1 overload)
Converts a JavaScript value to a JavaScript Object Notation (JSON) string.
@paramvalue A JavaScript value, usually an object or array, to be converted.@paramreplacer A function that transforms the results.@paramspace Adds indentation, white space, and line break characters to the return-value JSON text to make it easier to read.@throws{TypeError} If a circular reference or a BigInt value is found.
stringify
({ require_mcp_api_key: booleanrequire_mcp_api_key: true })
} ); var console: Console
The `console` module provides a simple debugging console that is similar to the JavaScript console mechanism provided by web browsers. The module exports two specific components: * A `Console` class with methods such as `console.log()`, `console.error()` and `console.warn()` that can be used to write to any Node.js stream. * A global `console` instance configured to write to [`process.stdout`](https://nodejs.org/docs/latest-v24.x/api/process.html#processstdout) and [`process.stderr`](https://nodejs.org/docs/latest-v24.x/api/process.html#processstderr). The global `console` can be used without importing the `node:console` module. _**Warning**_: The global console object's methods are neither consistently synchronous like the browser APIs they resemble, nor are they consistently asynchronous like all other Node.js streams. See the [`note on process I/O`](https://nodejs.org/docs/latest-v24.x/api/process.html#a-note-on-process-io) for more information. Example using the global `console`: ```js console.log('hello world'); // Prints: hello world, to stdout console.log('hello %s', 'world'); // Prints: hello world, to stdout console.error(new Error('Whoops, something bad happened')); // Prints error message and stack trace to stderr: // Error: Whoops, something bad happened // at [eval]:5:15 // at Script.runInThisContext (node:vm:132:18) // at Object.runInThisContext (node:vm:309:38) // at node:internal/process/execution:77:19 // at [eval]-wrapper:6:22 // at evalScript (node:internal/process/execution:76:60) // at node:internal/main/eval_string:23:3 const name = 'Will Robinson'; console.warn(`Danger ${name}! Danger!`); // Prints: Danger Will Robinson! Danger!, to stderr ``` Example using the `Console` class: ```js const out = getStreamSomehow(); const err = getStreamSomehow(); const myConsole = new console.Console(out, err); myConsole.log('hello world'); // Prints: hello world, to out myConsole.log('hello %s', 'world'); // Prints: hello world, to out myConsole.error(new Error('Whoops, something bad happened')); // Prints: [Error: Whoops, something bad happened], to err const name = 'Will Robinson'; myConsole.warn(`Danger ${name}! Danger!`); // Prints: Danger Will Robinson! Danger!, to err ```
@see[source](https://github.com/nodejs/node/blob/v24.x/lib/console.js)
console
.Console.log(message?: any, ...optionalParams: any[]): void (+1 overload)
Prints to `stdout` with newline. Multiple arguments can be passed, with the first used as the primary message and all additional used as substitution values similar to [`printf(3)`](http://man7.org/linux/man-pages/man3/printf.3.html) (the arguments are all passed to [`util.format()`](https://nodejs.org/docs/latest-v24.x/api/util.html#utilformatformat-args)). ```js const count = 5; console.log('count: %d', count); // Prints: count: 5, to stdout console.log('count:', count); // Prints: count: 5, to stdout ``` See [`util.format()`](https://nodejs.org/docs/latest-v24.x/api/util.html#utilformatformat-args) for more information.
@sincev0.1.100
log
(await const response: Responseresponse.Body.json(): Promise<any>
[MDN Reference](https://developer.mozilla.org/docs/Web/API/Request/json)
json
());

When to Use This

Enable API key enforcement when you need to:

  • Prevent unauthorized access to your MCP servers
  • Control which applications can interact with your MCP endpoints
  • Add an extra security layer for production deployments
  • Audit and track MCP server usage through API key attribution

API Reference

Get Current Setting

GET /api/v3/org/project/config

Update Setting

PATCH /api/v3/org/project/config
{
  "require_mcp_api_key": true
}

Consistent Error Response Structure & Union Types Preserved

Consistent Error Response Structure

Tool execution errors now return a standardized response format across all failure types. Previously, the data field was empty on errors—now it always includes status_code and message, matching the structure of successful responses.

What Changed

All error responses from tool execution now include:

  • data.status_code: HTTP status code (or null for non-HTTP errors)
  • data.message: Detailed error message
  • error: Same detailed message at the top level

Before vs After

Previous error response:

{
  "data": {},
  "successfull": false,
  "error": "404 Client Error: Not Found for url: ...",
}

New error response:

{
  "data": {
      "http_error": "404 Client Error: Not Found for url: ...",
      "status_code": 404,
      "message": "Resource not found: The requested item does not exist"
  },
  "successfull": false,
  "error": "Resource not found: The requested item does not exist",
}

Why This Matters

  • Easier parsing: Agents and code can reliably access error details from data.message without special-casing empty data objects
  • Better debugging: Detailed error messages replace generic HTTP error strings
  • Consistent schema: Same response shape whether the tool succeeds or fails

Union Types Preserved in Tool Schemas

Tool schemas now use standard JSON Schema anyOf for union types, providing accurate type information for LLMs and code generators.

What Changed

Two changes affect how types appear in request/response schemas:

ChangeScopeDescription
Nullable fieldsAll toolkitsFields that accept null now use anyOf: [{type}, {type: "null"}] instead of type + nullable: true
Multi-type fields157 toolkitsFields accepting multiple value types (e.g., string | number) preserve the full anyOf array instead of flattening to the first type

Before vs After

For example, the GOOGLECALENDAR_GET_CURRENT_DATE_TIME request schema changes:

Previous (only a single type):

{
  "timezone": {
    "default": 0,
    "description": "Timezone specification...",
    "title": "Timezone",
    "type": "string"
  }
}

Now (Union types preserved):

{
  "timezone": {
    "anyOf": [
      { "type": "string" },
      { "type": "number" }
    ],
    "default": 0,
    "description": "Timezone specification...",
    "title": "Timezone"
  }
}

Similarly, nullable fields like page_token in GOOGLECALENDAR_LIST_CALENDARS:

Previous:

{
  "page_token": {
    "default": null,
    "description": "Token for the page of results to return...",
    "nullable": true,
    "title": "Page Token",
    "type": "string"
  }
}

Now:

{
  "page_token": {
    "anyOf": [
      { "type": "string" },
      { "type": "null" }
    ],
    "default": null,
    "description": "Token for the page of results to return...",
    "title": "Page Token"
  }
}

Why This Matters

  • Accurate schemas: LLMs and code generators see the full set of allowed types
  • Better validation: Input validation can now correctly accept all valid types, not just the first one

Deprecating BEARER_TOKEN auth scheme for 19 toolkits

We've deprecated the BEARER_TOKEN auth scheme for the following 19 toolkits:

  • Airtable
  • Discord
  • Discordbot
  • Gmail
  • Google Classroom
  • Google Search Console
  • Google Calendar
  • Google Docs
  • Google Drive
  • Google Slides
  • Google Super
  • Instagram
  • Ntfy
  • Sapling AI
  • Slack
  • Slackbot
  • Tawk To
  • TikTok
  • Twitter

Recommendation

For these toolkits, we recommend using alternative auth schemes (for example, OAUTH2, API_KEY, or other toolkit-supported schemes) instead of BEARER_TOKEN.

Backward compatibility (explicit)

This change is fully backward compatible:

  • Existing auth configs and connected accounts created with BEARER_TOKEN will continue to function.
  • Creating new auth configs and connected accounts with BEARER_TOKEN will continue to work (e.g., via API/SDK).
  • To discourage new usage, BEARER_TOKEN auth configs / connected accounts will not be displayed in the UI for these toolkits.

Binary Data Support for Proxy Execute

The /api/v3/tools/execute/proxy endpoint now supports binary data for both file uploads and downloads.

File Uploads (binary_body)

To upload a file via the proxy, use the binary_body field in your request payload. This supports two approaches: specifying either a URL pointing to the file or providing the base64-encoded content directly.

Upload File via URL

curl --location 'https://backend.composio.dev/api/v3/tools/execute/proxy' \
  --header 'accept: application/json' \
  --header 'x-api-key: <YOUR_API_KEY>' \
  --header 'Content-Type: application/json' \
  --data '{
    "endpoint": "/upload-endpoint",
    "method": "POST",
    "connected_account_id": "<CONNECTED_ACCOUNT_ID>",
    "binary_body": {
      "url": "{URL_TO_THE_FILE}"
    }
  }'

Upload File via Base64 Content

Supported up to 4MB file size.

curl --location 'https://backend.composio.dev/api/v3/tools/execute/proxy' \
  --header 'accept: application/json' \
  --header 'x-api-key: <YOUR_API_KEY>' \
  --header 'Content-Type: application/json' \
  --data '{
    "endpoint": "/upload-endpoint",
    "method": "POST",
    "connected_account_id": "<CONNECTED_ACCOUNT_ID>",
    "binary_body": {
      "base64": "JVBERi0xLjQKJ...<base64_data>...",
      "content_type": "application/pdf"
    }
  }'

File Downloads (binary_data)

When the proxied request returns a binary response (for example, a PDF or image), the proxy automatically uploads the file to temporary storage, and you receive a signed URL in the binary_data field. This enables you to download large files securely.

File Download Request

curl --location 'https://backend.composio.dev/api/v3/tools/execute/proxy' \
  --header 'accept: application/json' \
  --header 'x-api-key: <YOUR_API_KEY>' \
  --header 'Content-Type: application/json' \
  --data '{
    "endpoint": "{YOUR_ENDPOINT}",
    "method": "GET",
    "connected_account_id": "{YOUR_CONNECTED_ACCOUNT_ID}"
  }'

File Download Response

{
  "data": {},
  "binary_data": {
    "url": "url to the file",
    "content_type": "content type of the file",
    "size": "size of the file",
    "expires_at": "expires at of the file"
  },
  "status": "status code of the response",
  "headers": "headers of the response"
}

Summary

FeatureFieldDescription
File Upload via URLbinary_body.urlProvide a URL pointing to the file to upload
File Upload via Base64binary_body.base64 + binary_body.content_typeProvide base64-encoded content (up to 4MB)
File Downloadbinary_data in responseReceive a signed URL to download binary responses

We'd love your feedback on the new proxy execute capabilities. If anything feels unclear or you have suggestions for improvement, please reach out.

Webhook Payload V3 - Lookahead Announcement

We're introducing Webhook Payload V3 - a redesigned webhook structure that follows industry standards and provides better developer experience. This update affects how you receive trigger events via webhooks and Pusher.

What's Changing?

New Webhook Structure

We're adopting the Standard Webhooks specification for better consistency and reliability.

Headers

A new header will identify the webhook version:

x-composio-webhook-version: V3

Payload Structure

The payload structure is being reorganized to separate Composio metadata from trigger data:

Before (V2):

{
  "log_id": "log_TpxVOLXYnwXZ",
  "timestamp": "2025-12-23T13:06:07.695Z",
  "type": "gmail_new_gmail_message",
  "data": {
    "connection_id": "a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d",
    "connection_nano_id": "ca_xYz9AbCdEfGh",
    "trigger_nano_id": "ti_JZFoTyYKbzhB",
    "trigger_id": "7f8e9d0c-1b2a-3c4d-5e6f-7a8b9c0d1e2f",
    "user_id": "usr-demo-12a3b4c5...",
    // ... actual trigger data mixed with metadata
  }
}

After (V3):

{
  "id": "msg_a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d",
  "timestamp": "2025-12-23T13:06:07.695Z",
  "type": "composio.trigger.message",
  "metadata": {
    "log_id": "log_TpxVOLXYnwXZ",
    "trigger_slug": "GMAIL_NEW_GMAIL_MESSAGE",
    "auth_config_id": "ac_aCYTppZ5RsRc",
    "connected_account_id": "ca_cATYssZ5RrSc",
    "trigger_id": "ti_JZFoTyYKbzhB",
    "user_id": "pg-test-86c9fc84..."
  },
  "data": {
    // Clean trigger data without Composio metadata
  }
}

Key Improvements

  1. Metadata Separation: Composio-specific fields (connection IDs, trigger IDs, user IDs) are now in a dedicated metadata object
  2. Clean Data: The data field now contains only the actual trigger payload without infrastructure metadata
  3. Standardized Type Field: The type field now follows a consistent format (composio.trigger.message) instead of trigger-specific names like gmail_new_gmail_message
  4. Trigger Slug in Metadata: The trigger slug (e.g., GMAIL_NEW_GMAIL_MESSAGE) is now available in metadata.trigger_slug for easy identification
  5. Standards Compliance: Follows Standard Webhooks specification for better interoperability
  6. Consistent Structure: Same payload structure for both webhooks and Pusher channels

Migration Guide

Updating Your Webhook Handlers

If you're accessing Composio metadata fields, update your code:

# Before (V2)
trigger_type = payload["type"]  # "gmail_new_gmail_message"
connection_id = payload["data"]["connection_id"]
trigger_id = payload["data"]["trigger_id"]
message_text = payload["data"]["message_text"]

# After (V3)
trigger_type = payload["type"]  # "composio.trigger.message"
trigger_slug = payload["metadata"]["trigger_slug"]  # "GMAIL_NEW_GMAIL_MESSAGE"
connection_id = payload["metadata"]["connected_account_id"]
trigger_id = payload["metadata"]["trigger_id"]
message_text = payload["data"]["message_text"]
// Before (V2)
const const triggerSlug: anytriggerSlug = payload.type;  // "gmail_new_gmail_message"
const const connectionId: anyconnectionId = payload.data.connection_id;
const const triggerId: anytriggerId = payload.data.trigger_id;
const const messageText: anymessageText = payload.data.message_text;

// After (V3)
const const webhookType: anywebhookType = payload.type;  // "composio.trigger.message"
const const triggerSlug: anytriggerSlug = payload.metadata.trigger_slug;  // "GMAIL_NEW_GMAIL_MESSAGE"
const const connectionId: anyconnectionId = payload.metadata.connected_account_id;
const const triggerId: anytriggerId = payload.metadata.trigger_id;
const const messageText: anymessageText = payload.data.message_text;

Checking Webhook Version

You can detect the webhook version from headers:

webhook_version = headers.get("x-composio-webhook-version", "V2")
if webhook_version == "V3":
    # Use new structure
    metadata = payload["metadata"]
else:
    # Use old structure
    metadata = payload["data"]

Rollout Timeline

  • December 2025: V3 released, opt-in via project settings
  • February 15, 2026: All new organizations will default to V3
  • Existing organizations: Continue using V2 by default, can opt-in to V3 anytime

How to Opt-In

  1. Go to your project settings in the Composio dashboard
  2. Navigate to the Webhooks section
  3. Select "Webhook Payload Version: V3"
  4. Update your webhook handlers to use the new structure
  5. Test thoroughly before enabling in production

Organizations created before February 15, 2026 will remain on V2 by default. You can switch to V3 at your convenience.

Organizations created on or after February 15, 2026 will use V3 by default.

Benefits

  • Better DX: Clear separation between metadata and actual trigger data
  • Standards Compliance: Follows industry-standard webhook specifications
  • Consistency: Same structure across webhooks and Pusher channels
  • Future-Proof: Built on established standards for long-term compatibility

Need Help?

If you have questions about migrating to V3 or need assistance:

Authentication & Configuration Updates Across Multiple Toolkits

Summary

This release includes significant authentication and configuration improvements across 16+ toolkits. The changes standardize Base URL handling, modernize authentication methods, and fix various endpoint configurations to improve reliability and flexibility.

ToolkitChange TypeDescription
MakeBreakingRemoved Region field, replaced with Base URL
LinearImprovementBase URL is no longer configurable
KibanaImprovementRemoved default value for Base URL
InsightlyFixAdded default value for Pod field
HelloBarDeprecatedDeprecated bearer authentication
GongFixAdded default value for Base URL
FormSiteDeprecatedDeprecated bearer auth, added API key authentication
DataScopeFixFixed Get Current User Endpoint
D2L BrightspaceFixUpdated Get Current User Endpoint
ClickUpFixChanged Base URL field type
BubbleBreakingFixed Base URL field, removed Subdomain
Brilliant DirectoriesFixImplemented dynamic Base URL for user endpoint
BraintreeImprovementUpdated to production defaults with dynamic endpoints
Auth0ImprovementReplaced hardcoded endpoint with dynamic tenant Base URL

Breaking Changes

We verified that active usage for these toolkits is practically zero before proceeding with these changes.

Make Toolkit

  • Removed Region field in favor of explicit Base URL configuration
  • Users must now provide the full Base URL instead of selecting a region
  • This change provides more flexibility for custom deployments and regional endpoints

Bubble Toolkit

  • Removed Subdomain field and restructured Base URL handling
  • Users must now provide the complete Base URL instead of just the Subdomain
  • This change standardizes URL configuration across all toolkits

Deprecated Features

HelloBar Toolkit

  • Bearer authentication is now deprecated
  • While still functional, users are encouraged to migrate to newer authentication methods
  • Support for bearer tokens will be removed in a future release

FormSite Toolkit

  • Bearer authentication deprecated in favor of API key authentication
  • New integrations should use API key authentication for improved security
  • Existing bearer token implementations will continue to work but should be migrated

Improvements & Fixes

Configuration Improvements

Linear Toolkit - Base URL is no longer a configurable field. The toolkit now uses a fixed endpoint, simplifying the authentication process.

Kibana Toolkit - Removed the default value for Base URL, allowing for more flexible deployment configurations. Users can now specify custom Kibana instances without overriding defaults.

Gong Toolkit - Added a sensible default value for Base URL to simplify initial setup. New users can connect without manually configuring the endpoint.

Insightly Toolkit - Added default value for the Pod field to streamline configuration. Reduces setup complexity for standard deployments.

ClickUp Toolkit - Fixed the Base URL field type for proper validation and handling. Ensures consistent URL formatting across all operations.

Dynamic Endpoint Updates

Brilliant Directories Toolkit - Implemented dynamic Base URL resolution for the Get Current User Endpoint. Automatically adapts to different deployment environments.

Braintree Toolkit - Updated configuration to use production defaults. Implemented dynamic endpoint resolution for better environment handling. Improved reliability for production deployments.

Auth0 Toolkit - Replaced hardcoded endpoints with dynamic tenant-based URL resolution. Supports multi-tenant deployments without manual configuration. Automatically constructs the correct endpoint based on the tenant configuration.

Endpoint Fixes

DataScope Toolkit - Fixed the Get Current User Endpoint to use the correct API path. Resolves authentication verification issues.

D2L Brightspace Toolkit - Updated the Get Current User Endpoint to match the latest API specifications. Ensures proper user identification and session validation.

Migration Guide

For toolkits with breaking changes, please update your configurations as follows:

  1. Make: Replace Region with the full Base URL (e.g., https://us-east-1.make.com)
  2. Bubble: Replace Subdomain with the full Base URL (e.g., https://myapp.bubbleapps.io)

For deprecated authentication methods:

  • HelloBar & FormSite: Generate new API keys from your account settings and update your authentication configuration

Authentication Updates Across Multiple Toolkits

We've updated authentication configurations for several toolkits to improve security, fix issues, and support additional deployment options.

Summary

ToolkitChange TypeAction Required
AshbyDeprecatedNo
FreshdeskDeprecatedNo
FreshserviceDeprecatedNo
MakeBreakingNew auth config + user reconnect
MixpanelFixNo
Recall AIBreakingNew auth config + user reconnect
Relevance AIBreakingNew auth config + user reconnect
SmartRecruitersBreakingNew auth config + user reconnect
SupabaseImprovementNo
TrelloDeprecatedNo
ZoomInfoDeprecatedNo

Breaking Changes

These toolkits had incorrect or outdated authentication configurations that needed fixing. We verified that active usage for these toolkits is practically zero before proceeding with these changes.

Impact: Existing connections will stop working. You'll need to create new auth configs and ask affected users to reconnect.

Make

Replaced region-based configuration with full base URL input. Users now provide the complete Make instance URL (e.g., https://us2.make.com or https://us1.make.celonis.com) instead of just a region code.

Recall AI

Updated from region-based to full base URL configuration. Fixed field descriptions and metadata. Updated categories to AI/Productivity/Communication and added proper documentation links.

Relevance AI

Simplified authentication by removing deprecated Project ID field. Added conditional mapping for region codes to API subdomains (AU→f1db6c, EU→d7b62b, US→bcbe5a). Region field now defaults to US.

SmartRecruiters

Fixed OAuth configuration with correct SmartRecruiters endpoints. Added proper default scopes for candidates, jobs, and users. Enabled PKCE and added refresh token support.

Deprecated (Still Working)

These changes introduce new auth methods while keeping old ones functional:

Ashby

Added new API Key authentication scheme with automatic base64 encoding and proper authorization headers.

No Action Required: Old Basic Auth method is deprecated but continues to work. Existing connections are unaffected.

Freshdesk

Added new API Key authentication scheme requiring subdomain and API key with automatic base64 encoding.

No Action Required: Old Basic Auth method is deprecated but continues to work. Existing connections are unaffected.

Freshservice

Added new API Key authentication scheme requiring subdomain and API key with automatic base64 encoding.

No Action Required: Old Basic Auth method is deprecated but continues to work. Existing connections are unaffected.

Trello

Marked Bearer Token authentication as deprecated in favor of OAuth authentication.

No Action Required: Old Bearer auth continues to function. OAuth is recommended for new connections.

ZoomInfo

Added new OAuth2 authentication scheme with comprehensive scopes for contacts, companies, audiences, scoops, news, and intent data. Deprecated the old JWT-based Basic authentication. Password field now properly marked as secret.

No Action Required: Old JWT auth continues to function. New connections will use OAuth2.

Non-Breaking Improvements

Mixpanel

Fixed region mapping logic for data residency. Added proper conditional evaluation to map regions to correct API hosts (EU, India, or Standard). Region field is now optional and defaults to Standard server. Service account secret now properly marked as secret.

No Action Required: Existing connections continue to work without changes.

Supabase

Changed base_url field type from auth_config_field to connection_field for both OAuth and API Key schemes. Updated base action logic to respect user-provided base URLs, enabling support for self-hosted Supabase instances.

No Action Required: Existing connections continue to work. Self-hosted instances now supported.

Toolkit Deprecation: Removing Empty Toolkits

What's Changed

We're deprecating 15 toolkits that currently have no supported actions. These toolkits will be reactivated once we add functional actions to them, ensuring you only see integrations that are ready to use.

Deprecated Toolkits

The following toolkits are now deprecated:

  • BREATHEHR, DIXA, EGNYTE, EXPENSIFY, FREEAGENT
  • GUSTO, NUTSHELL, OPENNUTRITION, OYSTERHR, RAKUTEN
  • SALESFLARE, TEAMLEADER, WALGREENS, WHOOP, WIX

Impact on Your Integration

API Behavior Changes

List Toolkits Endpoint

The GET /toolkits endpoint will now exclude deprecated toolkits by default.

Need to see deprecated toolkits? Use the include_deprecated query parameter.

Backward Compatibility

Your existing integrations are safe. All other endpoints continue to work with deprecated toolkits:

  • Retrieve the toolkit details
  • Create auth configurations
  • Manage connected accounts
  • Configure MCP Servers

This ensures zero breaking changes to your current implementations.

Why This Matters

This change helps you:

  • Focus on working integrations - No clutter from non-functional toolkits
  • Avoid integration attempts with toolkits that have no actions
  • Better developer experience with a cleaner, more actionable toolkit list

Questions?

If you have questions or need support with any deprecated toolkit, reach out to our team or check our documentation.

Toolkit Deprecation: Streamlining Our Platform

What's Changed

We're deprecating 60 toolkits that currently have no supported actions. These toolkits will be reactivated once we add functional actions to them, ensuring you only see integrations that are ready to use.

Deprecated Toolkits

The following toolkits are now deprecated:

  • ACCELO, ADOBE, AERO_WORKFLOW, AMAZON, APEX27
  • APPOINTO, APPSFLYER, ATLASSIAN, AUTH0, AXONAUT
  • BATTLENET, BOLDSIGN, BRAINTREE, BREEZY_HR, BREX_STAGING
  • BRIGHTPEARL, BROWSERHUB, CUSTOMER_IO, DEEL, DRIP_JOBS
  • EPIC_GAMES, FACTORIAL, FITBIT, FRONT, GO_TO_WEBINAR
  • GURU, HELCIM, HIGHLEVEL, ICIMS_TALENT_CLOUD, IDEA_SCALE
  • KEAP, LASTPASS, LEVER_SANDBOX, LEXOFFICE, MANY_CHAT
  • MBOUM, MICROSOFT_TENANT, MOXIE, ONCEHUB, POPTIN
  • PRECORO, PRINTNODE, QUALAROO, RAVENSEOTOOLS, RING_CENTRAL
  • RIPPLING, SAGE, SALESFORCE_MARKETING_CLOUD, SEISMIC, SMARTRECRUITERS
  • TAPFORM, TERMINUS, TIMEKIT, TWITCH, VENLY
  • VERO, VISME, WAVE_ACCOUNTING, WIZ, ZOHO_DESK

Impact on Your Integration

API Behavior Changes

List Toolkits Endpoint

The GET /toolkits endpoint will now exclude deprecated toolkits by default.

Need to see deprecated toolkits? Use the new include_deprecated query parameter.

Backward Compatibility

Your existing integrations are safe. All other endpoints continue to work with deprecated toolkits:

  • Retrieve the toolkit details
  • Create auth configurations
  • Manage connected accounts
  • Configure MCP Servers

This ensures zero breaking changes to your current implementations.

Why This Matters

This change helps you:

  • Focus on working integrations - No clutter from non-functional toolkits
  • Avoid integration attempts with toolkits that have no actions
  • Better developer experience with a cleaner, more actionable toolkit list

Questions?

If you have questions or need support with any deprecated toolkit, reach out to our team or check our documentation.

Deprecation of is_local_toolkit Field and Removal of is_local Query Parameter

We're cleaning up the Toolkits API by deprecating the is_local_toolkit response field and removing the is_local query parameter filter.

What's Changing?

Response Field: is_local_toolkit (Deprecated)

The is_local_toolkit field in toolkit API responses is now deprecated. This field was originally intended to indicate whether a toolkit was local to a specific project, but it is no longer meaningful as no toolkits use this classification.

Affected Endpoints:

  • GET /api/v3/toolkits - List toolkits
  • GET /api/v3/toolkits/{slug} - Get single toolkit
  • GET /api/v3/toolkits/multi - Get multiple toolkits

The field will continue to be returned in API responses for backward compatibility, but it will always return false. It is marked as deprecated: true in the OpenAPI specification.

Query Parameter: is_local (Removed)

The is_local query parameter filter has been removed from the following endpoints:

  • GET /api/v3/toolkits
  • GET /api/v3/toolkits/multi

This parameter was used to filter toolkits by their local status, but since no toolkits are classified as local, it served no practical purpose.

Impact on Your Code

If You're Using the is_local Query Parameter

Before:

// This will no longer work
const const toolkits: Responsetoolkits = await function fetch(input: string | URL | Request, init?: RequestInit): Promise<Response> (+1 overload)
[MDN Reference](https://developer.mozilla.org/docs/Web/API/Window/fetch)
fetch
('/api/v3/toolkits?is_local=true');

After:

// Simply remove the is_local parameter
const const toolkits: Responsetoolkits = await function fetch(input: string | URL | Request, init?: RequestInit): Promise<Response> (+1 overload)
[MDN Reference](https://developer.mozilla.org/docs/Web/API/Window/fetch)
fetch
('/api/v3/toolkits');

If You're Reading the is_local_toolkit Response Field

The field will continue to be present in responses but will always return false. You can safely ignore this field or remove any logic that depends on it.

Before:

const const toolkit: anytoolkit = await composio.toolkits.get('github');
if (const toolkit: anytoolkit.is_local_toolkit) {
  // This condition will never be true
  handleLocalToolkit(const toolkit: anytoolkit);
}

After:

const const toolkit: anytoolkit = await composio.toolkits.get('github');
// Remove is_local_toolkit checks - they're no longer meaningful

Tool Router General Availability

The Composio SDKs achieved a significant milestone with Tool Router moving from experimental to stable production status in December 2025. The Tool Router is now a fully supported feature that enables creating isolated MCP sessions with scoped toolkit access across both Python 0.10.1 and TypeScript 0.3.0.

Major Achievements

Native Tool Execution: Both SDKs now support direct tool execution through Tool Router sessions. The TypeScript implementation emphasizes improved type safety and error handling, while Python developers benefit from better integration with provider-wrapped tools.

Webhook Security: A new verification method was introduced. The system now provides secure webhook endpoint validation and signature verification for incoming webhooks, enhancing protection for trigger-based workflows.

Framework Compatibility: The stable Tool Router integrates with multiple AI platforms including OpenAI, Anthropic, LangChain, LlamaIndex, CrewAI, and Vercel AI SDK.

Technical Improvements

The TypeScript SDK resolved significant CommonJS compatibility issues by switching bundlers. This addresses a common developer pain point, particularly for Node.js projects not using ES modules.

The Python SDK extended LangChain provider support to version 1, while simultaneously fixing a critical KeyError occurring when SUPABASE_BETA_RUN_SQL_QUERY is used with Agents.

Migration Path

Users upgrading from experimental APIs should note the simplified approach—the Tool Router API now operates directly rather than through experimental namespaces, with comprehensive migration documentation provided.

Removal of label query parameter from connected accounts API

The label query parameter has been removed from the GET /api/v3/connected_accounts endpoint.

What's changing?

The label query parameter is no longer supported when listing connected accounts. This parameter was previously accepted but had no functional behavior since label ingestion was removed in an earlier update.

Impact

None - This is a cleanup change. The label query parameter was not performing any filtering since the underlying label ingestion functionality was already removed. If your code was passing this parameter, it was being silently ignored.

Migration

No action required. If your code was passing the label query parameter, you can safely remove it from your API calls.

Enhanced Security Masking for Sensitive Fields

We've improved the security masking for REDACTED fields in the following APIs:

What's Changed: Sensitive fields are now partially masked, revealing only the first 4 characters to help with debugging while maintaining security.

Example:

Before: REDACTED
After:  abcd...

Disabling Masking

If you need to disable masking for your use case, you have two options:

  1. Via UI: Navigate to Project SettingsConfiguration tab and update the masking settings
  2. Via API: Use the Patch Project Config API

Typed Responses Across Toolkits

We've updated many toolkits so their outputs are now strongly typed objects instead of a generic response_data blob, meaning tools like Outlook, HubSpot, Notion, etc. now return well-shaped, documented fields you can rely on directly in your code and agents. These improvements apply to the latest toolkit versions—see our toolkit versioning docs for how versions are managed.

Breaking Change for latest Version

If you're using the latest version and your code post-processes the old response_data structure, you'll need to update your code to work with the new flattened, typed response schemas.

Why This Matters

  • Better developer experience for direct execute: clear fields and types
  • Improved agent performance: flatter output shapes with explicit fields reduce nesting and invalid params
  • Clearer docs and type safety: richer metadata for IDEs and autocomplete

Before vs After

Previous (generic, version 20251202_00):

{
  "data": {
    "response_data": { "...": "..." }
  },
  "successful": true
}

Now (typed example – Outlook List Messages, version 20251209_00):

{
  "data": {
    "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users('me')/messages",
    "@odata.nextLink": "https://graph.microsoft.com/v1.0/me/messages?$skip=10",
    "value": [
      {
        "id": "abc123",
        "subject": "Hi there",
        "from": { "emailAddress": { "address": "a@b.com", "name": "Alice" } },
        "hasAttachments": true
      }
    ]
  },
  "successful": true
}

For the exact field mapping per toolkit, open platform.composio.dev → Toolkits → List Messages (or the relevant tool).

Migration Notes

  • Breaking change for consumers on the latest version who post-process the old nested response_data shape: outputs are now flattened and explicitly typed.
  • New and modified fields include richer descriptions and examples; some legacy placeholders were removed.
  • Re-fetch schemas for your tool/version to see the typed definitions. Use the toolkit view in platform.composio.dev for authoritative field details.

Transition to Self-Managed Credentials for Select Applications

This is a non-breaking change. Your existing integrations will continue to work as expected. This change only affects new integrations with the applications listed below.

What's Changing?

Starting today, the following applications will require your own developer credentials instead of Composio-managed credentials:

  • Auth0
  • Blackbaud
  • BoldSign
  • Deel
  • Front
  • GoToWebinar
  • PagerDuty
  • Pipedrive
  • Shopify
  • Strava
  • SurveyMonkey
  • Webex

What You Need to Do

To continue using these applications with Composio:

  1. Create Developer Accounts: Register for developer accounts on the platforms you need
  2. Generate API Credentials: Create OAuth apps following each platform's documentation
  3. Configure in Composio: Add your credentials to Composio using custom auth configs
  4. Test Your Integration: Test your integration with the new credentials

All other Composio applications continue to work with Composio-managed credentials. This change only affects the 12 applications listed above.

Connected Account Expiration for Incomplete Connections

We're implementing automatic expiration for connected accounts that remain in incomplete states, helping maintain a cleaner and more efficient authentication system.

What's Changing?

Connected accounts in Initializing and Initiated states will now automatically expire after 10 minutes. This applies to connection attempts that were started but never completed.

Why This Matters

This change provides:

  • Better Resource Management: Automatically cleans up incomplete connection attempts
  • Improved System Hygiene: Prevents accumulation of stale, unused connection records
  • Enhanced User Experience: Reduces clutter from abandoned authentication flows

This is a non-breaking change. Your existing integrations and completed connections will continue to work as expected. This change only affects connection attempts that are never completed.

Questions?

If you have any questions about this change, please reach out to our support team or check our Connected Accounts documentation.

Required API Key Authentication for MCP URLs

We're strengthening the security of Model Context Protocol (MCP) URLs by making API key authentication mandatory for all requests.

What's Changing?

Starting December 15th, 2025, all new Composio projects must include the x-api-key header when making requests to MCP URLs. This header authenticates your application and ensures secure communication with the Composio platform.

Why This Matters

This change provides:

  • Enhanced Authentication: Ensures only authorized applications can access MCP endpoints
  • Industry Best Practices: Aligns with standard API security patterns

Impact on Existing Projects

For existing projects: We value backward compatibility and understand the need for a smooth transition. Your existing MCP URLs will continue to work without the x-api-key header until April 15th, 2026.

Important: After April 15th, 2026, all MCP URL requests without the x-api-key header will be rejected. Please ensure you update your applications before this date to avoid service disruption.

Note: If you're already passing the x-api-key header in your MCP requests, no action is required—you're all set!

Migration Guide

To adopt this security enhancement in your existing projects:

  1. Locate Your API Key: Find your API key in the Composio dashboard under Project Settings
  2. Update Your Code: Add the x-api-key header to all MCP URL requests
  3. Test Thoroughly: Verify the updated requests work in your development environment
  4. Deploy: Roll out the changes to your production environment

Questions?

If you have any questions about this security enhancement or need assistance with migration, please reach out to our support team or check our MCP documentation.

Toolkit Version Support for Triggers

Summary

Added toolkit version support to trigger operations (create and getType) in both Python and TypeScript SDKs. This allows users to explicitly specify which toolkit version to use when creating trigger instances and retrieving trigger type information, ensuring consistent behavior across different toolkit versions.

Trigger operations now respect the global toolkitVersions configuration set during Composio initialization, providing better control over which trigger versions are used in your applications.

Key Changes

TypeScript SDK (ts/packages/core/)

  • Added toolkit_versions parameter to triggers.create() method
    • Passes the global toolkit versions configuration when creating trigger instances
    • Defaults to 'latest' when no version is specified
  • Modified triggers.getType() to respect global toolkit versions
    • Now accepts toolkit version configuration to fetch trigger types for specific versions
    • Improved error messages to include version-related fixes
  • Updated trigger type documentation with comprehensive examples
  • Added behavior documentation explaining version usage patterns

Python SDK (python/composio/core/models/)

  • Added toolkit_versions parameter to triggers.create() method
    • Uses global toolkit version configuration when creating trigger instances
    • Converts None to omit for API compatibility
  • Modified triggers.get_type() to respect toolkit versions
    • Implemented custom method replacing direct client binding
    • Passes toolkit version configuration to API calls
  • Added comprehensive docstrings explaining version behavior

Behavior

Creating Triggers with Toolkit Versions:

// TypeScript - Configure versions at initialization
const const composio: anycomposio = new Composio({
  apiKey: stringapiKey: 'your-api-key',
  
toolkitVersions: {
    gmail: string;
    github: string;
}
toolkitVersions
: {
gmail: stringgmail: '12082025_00', github: stringgithub: '10082025_01' } }); // Create trigger - uses version '12082025_00' for Gmail const const trigger: anytrigger = await const composio: anycomposio.triggers.create('user@example.com', 'GMAIL_NEW_MESSAGE', { connectedAccountId: stringconnectedAccountId: 'ca_abc123',
triggerConfig: {
    labelIds: string;
    userId: string;
    interval: number;
}
triggerConfig
: {
labelIds: stringlabelIds: 'INBOX', userId: stringuserId: 'me', interval: numberinterval: 60, }, });
# Python - Configure versions at initialization
composio = Composio(
    api_key="your-api-key",
    toolkit_versions={"gmail": "12082025_00", "github": "10082025_01"}
)

# Create trigger - uses version '12082025_00' for Gmail
trigger = composio.triggers.create(
    slug="GMAIL_NEW_MESSAGE",
    user_id="user@example.com",
    trigger_config={"labelIds": "INBOX", "userId": "me", "interval": 60}
)

Retrieving Trigger Types with Specific Versions:

// TypeScript
const const composio: anycomposio = new Composio({
  apiKey: stringapiKey: 'your-api-key',
  
toolkitVersions: {
    github: string;
}
toolkitVersions
: { github: stringgithub: '10082025_01' }
}); // Get trigger type for specific version const const triggerType: anytriggerType = await const composio: anycomposio.triggers.getType('GITHUB_COMMIT_EVENT'); // Returns trigger type for version '10082025_01'
# Python
composio = Composio(
    api_key="your-api-key",
    toolkit_versions={"github": "10082025_01"}
)

# Get trigger type for specific version
trigger_type = composio.triggers.get_type("GITHUB_COMMIT_EVENT")
# Returns trigger type for version '10082025_01'

Benefits

  • Version Control: Explicitly specify which toolkit version to use for triggers
  • Consistency: Ensure trigger behavior remains consistent across toolkit updates
  • Testing: Test trigger integrations with specific versions before updating
  • Debugging: Easier to debug issues by pinning to specific toolkit versions
  • Production Safety: Avoid unexpected changes from automatic version updates

Migration Guide

This is a non-breaking change. Existing code will continue to work with default behavior:

Before (still works):

// Uses 'latest' version by default
const const trigger: anytrigger = await composio.triggers.create('user', 'GITHUB_COMMIT_EVENT', {...});

After (recommended for production):

// Explicitly configure versions for better control
const const composio: anycomposio = new Composio({
  apiKey: stringapiKey: 'your-api-key',
  
toolkitVersions: {
    github: string;
}
toolkitVersions
: { github: stringgithub: '10082025_01' }
}); const const trigger: anytrigger = await const composio: anycomposio.triggers.create('user', 'GITHUB_COMMIT_EVENT', {...});

For more details on toolkit versioning, see the Toolkit Versioning documentation.

Enhanced MCP URL Security Requirements

We're introducing improved security requirements for Model Context Protocol (MCP) URLs to ensure better isolation between user connections and prevent unauthorized access.

What's Changing?

Starting today, all new Composio projects must include at least one of the following parameters in their MCP URLs:

  • user_id - Identifies the specific user
  • connected_account_id - Identifies the specific connected account

Why This Matters

This change ensures that:

  • User Isolation: Each user's connections remain completely separate from others
  • Enhanced Security: Prevents potential cross-user data access scenarios
  • Better Multi-Tenancy: Enables safer multi-tenant application architectures
  • Explicit Access Control: Forces developers to explicitly specify which user or account context they're operating in

Impact on Existing Projects

For existing projects: We understand the importance of backward compatibility. While we've sent email notifications to project owners about upgrading their MCP URLs, your existing integrations will continue to work until January 15th, 2026.

Important: After January 15th, 2026, MCP URLs without user_id or connected_account_id query parameters will no longer be supported. Please ensure you update your MCP URLs before this date to avoid service disruption.

Note: If your MCP URLs already include either user_id or connected_account_id query parameters, no action is required—you can safely ignore this notice.

Implementation Example

Before:

https://platform.composio.dev/v3/mcp/{id}

After (with user_id):

https://platform.composio.dev/v3/mcp/{id}?user_id=user_123

After (with connected_account_id):

https://platform.composio.dev/v3/mcp/{id}?connected_account_id=ca_xyz

Migration Guide

If you're using an existing project and want to adopt this security enhancement:

  1. Review your current MCP URL configuration
  2. Add either user_id or connected_account_id parameter to your URLs
  3. Update your application code to pass the appropriate identifier
  4. Test the updated URLs in your development environment

For more details on choosing the right user identifiers for your application, see our User Management documentation.

Questions?

If you have any questions about this security enhancement or need assistance with migration, please reach out to our support team or check our MCP documentation.

Adds Version Checks for Tool Execution and Improved Execution Speed in TS SDK

Summary

Added version validation for manual tool execution to prevent unexpected behavior when using latest toolkit versions. This ensures users explicitly specify toolkit versions when executing tools manually, while allowing flexibility through a skip flag.

This release also eliminates a lot of redundant API calls made to check connected account during tool execution, effectively increasing the performance of tool execution.

Key Changes

Python SDK (python/)

  • Added ToolVersionRequiredError exception with detailed error messages and fix suggestions
  • Added dangerously_skip_version_check parameter to execute() method
  • Modified _execute_tool() to validate version is not latest unless skip flag is set
  • Automatically passes dangerously_skip_version_check=True for agentic provider flows
  • Added comprehensive test coverage (19 test methods) in test_tool_execution.py

TypeScript SDK (ts/packages/core/)

  • Added ComposioToolVersionRequiredError error class with possible fixes
  • Added dangerouslySkipVersionCheck parameter to execute flow
  • Modified tool execution to validate version before API calls
  • Updated execution type definitions in tool.types.ts and modifiers.types.ts
  • Updated test files with date-based version format (20251201_xx)
  • Improved tool execution by eliminating redundant API calls

Behavior

Before: Tools could be executed with latest version, risking unexpected behavior on toolkit updates

After: Manual execution requires specific version or explicit skip flag:

# Raises ToolVersionRequiredError
tools.execute("GITHUB_CREATE_ISSUE", {...})

# Works - explicit version
tools.execute("GITHUB_CREATE_ISSUE", {...}, version="20251201_01")

# Works - configured toolkit versions
tools = Tools(client, provider, toolkit_versions={"github": "20251201_01"})

# Works - with skip flag (use cautiously)
tools.execute("GITHUB_CREATE_ISSUE", {...}, dangerously_skip_version_check=True)

Breaking Changes

Manual tool execution without version specification now throws an error. Users must either:

  1. Pass explicit version parameter
  2. Configure toolkit versions in SDK initialization
  3. Set environment variable COMPOSIO_TOOLKIT_VERSION_<TOOLKIT_SLUG>
  4. Use dangerously_skip_version_check=True flag

MCP (Model Control Protocol) & Experimental ToolRouter

Composio now introduces comprehensive MCP (Model Control Protocol) support and an experimental ToolRouter for creating isolated, scoped sessions with advanced toolkit management. These features enable seamless integration with modern AI frameworks and provide powerful session-based tool routing capabilities.

Why Use MCP & ToolRouter?

  • Framework Integration: Native MCP support for Vercel AI, Mastra, OpenAI Agents, and LangChain
  • Session Isolation: Create isolated sessions with specific toolkit configurations
  • Advanced Authentication: Flexible auth config management per toolkit
  • Scoped Access: Control which tools are available within each session
  • Multi-Service Workflows: Route tool calls efficiently across different services
  • Development & Testing: Perfect for testing and development with scoped MCP server access

TypeScript SDK (v0.1.53)

Added: MCP API

Core MCP Features:

  • MCP Server Creation: Create and manage MCP server configurations
  • User-Specific URLs: Generate unique MCP server URLs for individual users
  • Toolkit Configuration: Support for multiple toolkits with custom auth configs
  • Tool Filtering: Specify allowed tools per configuration
  • Connection Management: Choose between manual and automatic account management

Basic Usage:

import { class Composio<TProvider extends BaseComposioProvider<unknown, unknown, unknown> = OpenAIProvider>
This is the core class for Composio. It is used to initialize the Composio SDK and provide a global configuration.
Composio
} from '@composio/core';
const const composio: Composio<OpenAIProvider>composio = new new Composio<OpenAIProvider>(config?: ComposioConfig<OpenAIProvider> | undefined): Composio<OpenAIProvider>
Creates a new instance of the Composio SDK. The constructor initializes the SDK with the provided configuration options, sets up the API client, and initializes all core models (tools, toolkits, etc.).
@paramconfig - Configuration options for the Composio SDK@paramconfig.apiKey - The API key for authenticating with the Composio API@paramconfig.baseURL - The base URL for the Composio API (defaults to production URL)@paramconfig.allowTracking - Whether to allow anonymous usage analytics@paramconfig.provider - The provider to use for this Composio instance (defaults to OpenAIProvider)@example```typescript // Initialize with default configuration const composio = new Composio(); // Initialize with custom API key and base URL const composio = new Composio({ apiKey: 'your-api-key', baseURL: 'https://api.composio.dev' }); // Initialize with custom provider const composio = new Composio({ apiKey: 'your-api-key', provider: new CustomProvider() }); ```
Composio
({
apiKey?: string | null | undefined
The API key for the Composio API.
@example'sk-1234567890'
apiKey
: var process: NodeJS.Processprocess.NodeJS.Process.env: NodeJS.ProcessEnv
The `process.env` property returns an object containing the user environment. See [`environ(7)`](http://man7.org/linux/man-pages/man7/environ.7.html). An example of this object looks like: ```js { TERM: 'xterm-256color', SHELL: '/usr/local/bin/bash', USER: 'maciej', PATH: '~/.bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin', PWD: '/Users/maciej', EDITOR: 'vim', SHLVL: '1', HOME: '/Users/maciej', LOGNAME: 'maciej', _: '/usr/local/bin/node' } ``` It is possible to modify this object, but such modifications will not be reflected outside the Node.js process, or (unless explicitly requested) to other `Worker` threads. In other words, the following example would not work: ```bash node -e 'process.env.foo = "bar"' &#x26;&#x26; echo $foo ``` While the following will: ```js import { env } from 'node:process'; env.foo = 'bar'; console.log(env.foo); ``` Assigning a property on `process.env` will implicitly convert the value to a string. **This behavior is deprecated.** Future versions of Node.js may throw an error when the value is not a string, number, or boolean. ```js import { env } from 'node:process'; env.test = null; console.log(env.test); // => 'null' env.test = undefined; console.log(env.test); // => 'undefined' ``` Use `delete` to delete a property from `process.env`. ```js import { env } from 'node:process'; env.TEST = 1; delete env.TEST; console.log(env.TEST); // => undefined ``` On Windows operating systems, environment variables are case-insensitive. ```js import { env } from 'node:process'; env.TEST = 1; console.log(env.test); // => 1 ``` Unless explicitly specified when creating a `Worker` instance, each `Worker` thread has its own copy of `process.env`, based on its parent thread's `process.env`, or whatever was specified as the `env` option to the `Worker` constructor. Changes to `process.env` will not be visible across `Worker` threads, and only the main thread can make changes that are visible to the operating system or to native add-ons. On Windows, a copy of `process.env` on a `Worker` instance operates in a case-sensitive manner unlike the main thread.
@sincev0.1.27
env
.string | undefinedCOMPOSIO_API_KEY,
}); // Create MCP configuration const const mcpConfig: MCPConfigCreateResponsemcpConfig = await const composio: Composio<OpenAIProvider>composio.Composio<OpenAIProvider>.mcp: MCP
Model Context Protocol server management
mcp
.
MCP.create(name: string, mcpConfig: {
    toolkits: (string | {
        toolkit?: string | undefined;
        authConfigId?: string | undefined;
    })[];
    allowedTools?: string[] | undefined;
    manuallyManageConnections?: boolean | undefined;
}): Promise<MCPConfigCreateResponse>
Create a new MCP configuration.
@paramparams - Parameters for creating the MCP configuration@paramparams.authConfig - Array of auth configurations with id and allowed tools@paramparams.options - Configuration options@paramparams.options.name - Unique name for the MCP configuration@paramparams.options.manuallyManageConnections - Whether to use chat-based authentication or manually connect accounts@returnsCreated server details with instance getter@example```typescript const server = await composio.mcpConfig.create("personal-mcp-server", { toolkits: ["github", "slack"], allowedTools: ["GMAIL_FETCH_EMAILS", "SLACK_SEND_MESSAGE"], manuallyManageConnections: false } }); const server = await composio.mcpConfig.create("personal-mcp-server", { toolkits: [{ toolkit: "gmail", authConfigId: "ac_243434343" }], allowedTools: ["GMAIL_FETCH_EMAILS"], manuallyManageConnections: false } }); ```
create
('my-server-name', {
toolkits: (string | {
    toolkit?: string | undefined;
    authConfigId?: string | undefined;
})[]
toolkits
: [
{ toolkit?: string | undefinedtoolkit: 'github', authConfigId?: string | undefinedauthConfigId: 'ac_233434343' }, { toolkit?: string | undefinedtoolkit: 'gmail', authConfigId?: string | undefinedauthConfigId: 'ac_567890123' } ], allowedTools?: string[] | undefinedallowedTools: ['GITHUB_CREATE_ISSUE', 'GMAIL_SEND_EMAIL'], manuallyManageConnections?: boolean | undefinedmanuallyManageConnections: false, }); // Generate server instance for a user const
const serverInstance: {
    name: string;
    type: "streamable_http";
    id: string;
    userId: string;
    allowedTools: string[];
    url: string;
    authConfigs: string[];
}
serverInstance
= await const composio: Composio<OpenAIProvider>composio.Composio<OpenAIProvider>.mcp: MCP
Model Context Protocol server management
mcp
.
MCP.generate(userId: string, mcpConfigId: string, options?: {
    manuallyManageConnections?: boolean | undefined;
}): Promise<{
    name: string;
    type: "streamable_http";
    id: string;
    userId: string;
    allowedTools: string[];
    url: string;
    authConfigs: string[];
}>
Get server URLs for an existing MCP server. The response is wrapped according to the provider's specifications.
@example```typescript import { Composio } from "@composio/code"; const composio = new Composio(); const mcp = await composio.experimental.mcp.generate("default", "<mcp_config_id>"); ```@paramuserId external user id from your database for whom you want the server for@parammcpConfigId config id of the MCPConfig for which you want to create a server for@paramoptions additional options@paramoptions.isChatAuth Authenticate the users via chat when they use the MCP Server
generate
('user123', const mcpConfig: MCPConfigCreateResponsemcpConfig.id: stringid);
var console: Console
The `console` module provides a simple debugging console that is similar to the JavaScript console mechanism provided by web browsers. The module exports two specific components: * A `Console` class with methods such as `console.log()`, `console.error()` and `console.warn()` that can be used to write to any Node.js stream. * A global `console` instance configured to write to [`process.stdout`](https://nodejs.org/docs/latest-v24.x/api/process.html#processstdout) and [`process.stderr`](https://nodejs.org/docs/latest-v24.x/api/process.html#processstderr). The global `console` can be used without importing the `node:console` module. _**Warning**_: The global console object's methods are neither consistently synchronous like the browser APIs they resemble, nor are they consistently asynchronous like all other Node.js streams. See the [`note on process I/O`](https://nodejs.org/docs/latest-v24.x/api/process.html#a-note-on-process-io) for more information. Example using the global `console`: ```js console.log('hello world'); // Prints: hello world, to stdout console.log('hello %s', 'world'); // Prints: hello world, to stdout console.error(new Error('Whoops, something bad happened')); // Prints error message and stack trace to stderr: // Error: Whoops, something bad happened // at [eval]:5:15 // at Script.runInThisContext (node:vm:132:18) // at Object.runInThisContext (node:vm:309:38) // at node:internal/process/execution:77:19 // at [eval]-wrapper:6:22 // at evalScript (node:internal/process/execution:76:60) // at node:internal/main/eval_string:23:3 const name = 'Will Robinson'; console.warn(`Danger ${name}! Danger!`); // Prints: Danger Will Robinson! Danger!, to stderr ``` Example using the `Console` class: ```js const out = getStreamSomehow(); const err = getStreamSomehow(); const myConsole = new console.Console(out, err); myConsole.log('hello world'); // Prints: hello world, to out myConsole.log('hello %s', 'world'); // Prints: hello world, to out myConsole.error(new Error('Whoops, something bad happened')); // Prints: [Error: Whoops, something bad happened], to err const name = 'Will Robinson'; myConsole.warn(`Danger ${name}! Danger!`); // Prints: Danger Will Robinson! Danger!, to err ```
@see[source](https://github.com/nodejs/node/blob/v24.x/lib/console.js)
console
.Console.log(message?: any, ...optionalParams: any[]): void (+1 overload)
Prints to `stdout` with newline. Multiple arguments can be passed, with the first used as the primary message and all additional used as substitution values similar to [`printf(3)`](http://man7.org/linux/man-pages/man3/printf.3.html) (the arguments are all passed to [`util.format()`](https://nodejs.org/docs/latest-v24.x/api/util.html#utilformatformat-args)). ```js const count = 5; console.log('count: %d', count); // Prints: count: 5, to stdout console.log('count:', count); // Prints: count: 5, to stdout ``` See [`util.format()`](https://nodejs.org/docs/latest-v24.x/api/util.html#utilformatformat-args) for more information.
@sincev0.1.100
log
('MCP URL:',
const serverInstance: {
    name: string;
    type: "streamable_http";
    id: string;
    userId: string;
    allowedTools: string[];
    url: string;
    authConfigs: string[];
}
serverInstance
.url: stringurl);

Framework Integration Examples:

// Vercel AI Integration
import { class SSEClientTransport
Client transport for SSE: this will connect to a server using Server-Sent Events for receiving messages and make separate POST requests for sending messages.
@deprecatedSSEClientTransport is deprecated. Prefer to use StreamableHTTPClientTransport where possible instead. Note that because some servers are still using SSE, clients may need to support both transports during the migration period.
SSEClientTransport
} from '@modelcontextprotocol/sdk/client/sse.js';
import { experimental_createMCPClient as import createMCPClientcreateMCPClient } from 'ai'; const const mcpClient: anymcpClient = await import createMCPClientcreateMCPClient({ name: stringname: 'composio-mcp-client', transport: SSEClientTransporttransport: new new SSEClientTransport(url: URL, opts?: SSEClientTransportOptions): SSEClientTransport
Client transport for SSE: this will connect to a server using Server-Sent Events for receiving messages and make separate POST requests for sending messages.
@deprecatedSSEClientTransport is deprecated. Prefer to use StreamableHTTPClientTransport where possible instead. Note that because some servers are still using SSE, clients may need to support both transports during the migration period.
SSEClientTransport
(new var URL: new (url: string | URL, base?: string | URL) => URL
The **`URL`** interface is used to parse, construct, normalize, and encode URL. [MDN Reference](https://developer.mozilla.org/docs/Web/API/URL)
URL
(serverInstance.url)),
}); // Mastra Integration import { class MCPClientMCPClient as class MastraMCPClientMastraMCPClient } from '@mastra/mcp'; const const mcpClient: MastraMCPClientmcpClient = new new MastraMCPClient(args: MCPClientOptions): MastraMCPClientMastraMCPClient({ MCPClientOptions.servers: Record<string, MastraMCPServerDefinition>servers: {
composio: {
    url: URL;
}
composio
: { url: URLurl: new var URL: new (url: string | URL, base?: string | URL) => URL
The **`URL`** interface is used to parse, construct, normalize, and encode URL. [MDN Reference](https://developer.mozilla.org/docs/Web/API/URL)
URL
(mcpSession.url) },
}, }); // OpenAI Agents Integration import {
function hostedMcpTool<Context = unknown>(options: {
    allowedTools?: string[] | {
        toolNames?: string[];
    };
} & ({
    serverLabel: string;
    serverUrl?: string;
    authorization?: string;
    headers?: Record<string, string>;
} | {
    serverLabel: string;
    connectorId: string;
    authorization?: string;
    headers?: Record<string, string>;
}) & ({
    requireApproval?: never;
} | {
    requireApproval: "never";
} | {
    requireApproval: "always" | {
        never?: {
            toolNames: string[];
        };
        always?: {
            toolNames: string[];
        };
    };
    onApproval?: HostedMCPApprovalFunction<Context>;
})): HostedMCPTool<Context>
Creates a hosted MCP tool definition.
@paramoptions - Configuration for the hosted MCP tool, including server connection details and approval requirements.
hostedMcpTool
} from '@openai/agents';
const const tools: HostedMCPTool<unknown>[]tools = [
hostedMcpTool<unknown>(options: {
    allowedTools?: string[] | {
        toolNames?: string[];
    };
} & (({
    serverLabel: string;
    serverUrl?: string;
    authorization?: string;
    headers?: Record<string, string>;
} | {
    serverLabel: string;
    connectorId: string;
    authorization?: string;
    headers?: Record<string, string>;
}) & ({
    requireApproval?: never;
} | {
    requireApproval: "never";
} | {
    requireApproval: "always" | {
        never?: {
            toolNames: string[];
        };
        always?: {
            toolNames: string[];
        };
    };
    onApproval?: HostedMCPApprovalFunction<unknown> | undefined;
}))): HostedMCPTool<...>
Creates a hosted MCP tool definition.
@paramoptions - Configuration for the hosted MCP tool, including server connection details and approval requirements.
hostedMcpTool
({
serverLabel: stringserverLabel: 'composio', serverUrl?: string | undefinedserverUrl: mcpSession.url, }), ];

Added: Experimental ToolRouter

Core ToolRouter Features:

  • Session-Based Routing: Create isolated sessions for specific users and toolkit combinations
  • Dynamic Configuration: Configure toolkits and auth configs per session
  • MCP Server URLs: Each session gets a unique MCP server endpoint
  • Flexible Toolkit Management: Support for string names or detailed toolkit configurations
  • Connection Control: Manual or automatic connection management per session

Basic Usage:

// Create session with simple toolkit names
const const session: anysession = await composio.experimental.toolRouter.createSession('user_123', {
  toolkits: string[]toolkits: ['gmail', 'slack', 'github'],
});

// Create session with auth configs
const const session: anysession = await composio.experimental.toolRouter.createSession('user_456', {
  
toolkits: {
    toolkit: string;
    authConfigId: string;
}[]
toolkits
: [
{ toolkit: stringtoolkit: 'gmail', authConfigId: stringauthConfigId: 'ac_gmail_work' }, { toolkit: stringtoolkit: 'slack', authConfigId: stringauthConfigId: 'ac_slack_team' }, { toolkit: stringtoolkit: 'github', authConfigId: stringauthConfigId: 'ac_github_personal' }, ], manuallyManageConnections: booleanmanuallyManageConnections: true, }); var console: Console
The `console` module provides a simple debugging console that is similar to the JavaScript console mechanism provided by web browsers. The module exports two specific components: * A `Console` class with methods such as `console.log()`, `console.error()` and `console.warn()` that can be used to write to any Node.js stream. * A global `console` instance configured to write to [`process.stdout`](https://nodejs.org/docs/latest-v24.x/api/process.html#processstdout) and [`process.stderr`](https://nodejs.org/docs/latest-v24.x/api/process.html#processstderr). The global `console` can be used without importing the `node:console` module. _**Warning**_: The global console object's methods are neither consistently synchronous like the browser APIs they resemble, nor are they consistently asynchronous like all other Node.js streams. See the [`note on process I/O`](https://nodejs.org/docs/latest-v24.x/api/process.html#a-note-on-process-io) for more information. Example using the global `console`: ```js console.log('hello world'); // Prints: hello world, to stdout console.log('hello %s', 'world'); // Prints: hello world, to stdout console.error(new Error('Whoops, something bad happened')); // Prints error message and stack trace to stderr: // Error: Whoops, something bad happened // at [eval]:5:15 // at Script.runInThisContext (node:vm:132:18) // at Object.runInThisContext (node:vm:309:38) // at node:internal/process/execution:77:19 // at [eval]-wrapper:6:22 // at evalScript (node:internal/process/execution:76:60) // at node:internal/main/eval_string:23:3 const name = 'Will Robinson'; console.warn(`Danger ${name}! Danger!`); // Prints: Danger Will Robinson! Danger!, to stderr ``` Example using the `Console` class: ```js const out = getStreamSomehow(); const err = getStreamSomehow(); const myConsole = new console.Console(out, err); myConsole.log('hello world'); // Prints: hello world, to out myConsole.log('hello %s', 'world'); // Prints: hello world, to out myConsole.error(new Error('Whoops, something bad happened')); // Prints: [Error: Whoops, something bad happened], to err const name = 'Will Robinson'; myConsole.warn(`Danger ${name}! Danger!`); // Prints: Danger Will Robinson! Danger!, to err ```
@see[source](https://github.com/nodejs/node/blob/v24.x/lib/console.js)
console
.Console.log(message?: any, ...optionalParams: any[]): void (+1 overload)
Prints to `stdout` with newline. Multiple arguments can be passed, with the first used as the primary message and all additional used as substitution values similar to [`printf(3)`](http://man7.org/linux/man-pages/man3/printf.3.html) (the arguments are all passed to [`util.format()`](https://nodejs.org/docs/latest-v24.x/api/util.html#utilformatformat-args)). ```js const count = 5; console.log('count: %d', count); // Prints: count: 5, to stdout console.log('count:', count); // Prints: count: 5, to stdout ``` See [`util.format()`](https://nodejs.org/docs/latest-v24.x/api/util.html#utilformatformat-args) for more information.
@sincev0.1.100
log
('Session ID:', const session: anysession.sessionId);
var console: Console
The `console` module provides a simple debugging console that is similar to the JavaScript console mechanism provided by web browsers. The module exports two specific components: * A `Console` class with methods such as `console.log()`, `console.error()` and `console.warn()` that can be used to write to any Node.js stream. * A global `console` instance configured to write to [`process.stdout`](https://nodejs.org/docs/latest-v24.x/api/process.html#processstdout) and [`process.stderr`](https://nodejs.org/docs/latest-v24.x/api/process.html#processstderr). The global `console` can be used without importing the `node:console` module. _**Warning**_: The global console object's methods are neither consistently synchronous like the browser APIs they resemble, nor are they consistently asynchronous like all other Node.js streams. See the [`note on process I/O`](https://nodejs.org/docs/latest-v24.x/api/process.html#a-note-on-process-io) for more information. Example using the global `console`: ```js console.log('hello world'); // Prints: hello world, to stdout console.log('hello %s', 'world'); // Prints: hello world, to stdout console.error(new Error('Whoops, something bad happened')); // Prints error message and stack trace to stderr: // Error: Whoops, something bad happened // at [eval]:5:15 // at Script.runInThisContext (node:vm:132:18) // at Object.runInThisContext (node:vm:309:38) // at node:internal/process/execution:77:19 // at [eval]-wrapper:6:22 // at evalScript (node:internal/process/execution:76:60) // at node:internal/main/eval_string:23:3 const name = 'Will Robinson'; console.warn(`Danger ${name}! Danger!`); // Prints: Danger Will Robinson! Danger!, to stderr ``` Example using the `Console` class: ```js const out = getStreamSomehow(); const err = getStreamSomehow(); const myConsole = new console.Console(out, err); myConsole.log('hello world'); // Prints: hello world, to out myConsole.log('hello %s', 'world'); // Prints: hello world, to out myConsole.error(new Error('Whoops, something bad happened')); // Prints: [Error: Whoops, something bad happened], to err const name = 'Will Robinson'; myConsole.warn(`Danger ${name}! Danger!`); // Prints: Danger Will Robinson! Danger!, to err ```
@see[source](https://github.com/nodejs/node/blob/v24.x/lib/console.js)
console
.Console.log(message?: any, ...optionalParams: any[]): void (+1 overload)
Prints to `stdout` with newline. Multiple arguments can be passed, with the first used as the primary message and all additional used as substitution values similar to [`printf(3)`](http://man7.org/linux/man-pages/man3/printf.3.html) (the arguments are all passed to [`util.format()`](https://nodejs.org/docs/latest-v24.x/api/util.html#utilformatformat-args)). ```js const count = 5; console.log('count: %d', count); // Prints: count: 5, to stdout console.log('count:', count); // Prints: count: 5, to stdout ``` See [`util.format()`](https://nodejs.org/docs/latest-v24.x/api/util.html#utilformatformat-args) for more information.
@sincev0.1.100
log
('MCP URL:', const session: anysession.url);

Advanced Multi-Service Integration:

// Complex workflow session
const const integrationSession: anyintegrationSession = await composio.experimental.toolRouter.createSession('user_789', {
  
toolkits: {
    toolkit: string;
    authConfigId: string;
}[]
toolkits
: [
{ toolkit: stringtoolkit: 'gmail', authConfigId: stringauthConfigId: 'ac_gmail_work' }, { toolkit: stringtoolkit: 'slack', authConfigId: stringauthConfigId: 'ac_slack_team' }, { toolkit: stringtoolkit: 'github', authConfigId: stringauthConfigId: 'ac_github_personal' }, { toolkit: stringtoolkit: 'notion', authConfigId: stringauthConfigId: 'ac_notion_workspace' }, { toolkit: stringtoolkit: 'calendar', authConfigId: stringauthConfigId: 'ac_gcal_primary' }, ], }); // Use with any MCP client const const mcpClient: anymcpClient = new MCPClient(const integrationSession: anyintegrationSession.url);

Framework-Specific Examples:

// Mastra Integration
const const mcpSession: anymcpSession = await composio.experimental.toolRouter.createSession(userId, {
  toolkits: string[]toolkits: ["gmail"],
  manuallyManageConnections: booleanmanuallyManageConnections: true,
});

const const agent: anyagent = new MastraAgent({
  name: stringname: 'Gmail Assistant',
  model: anymodel: openai('gpt-4o-mini'),
  tools: anytools: await mcpClient.getTools(),
});

// OpenAI Agents Integration
const const tools: any[]tools = [
  hostedMcpTool({
    serverLabel: stringserverLabel: 'composio tool router',
    serverUrl: anyserverUrl: const mcpSession: anymcpSession.url,
    
requireApproval: {
    never: {
        toolNames: string[];
    };
}
requireApproval
: {
never: {
    toolNames: string[];
}
never
: { toolNames: string[]toolNames: ['GMAIL_FETCH_EMAILS'] },
}, }), ];

Python SDK (v0.8.17)

Added: MCP Support

Core MCP Features:

  • Server Configuration: Create and manage MCP server configurations
  • Toolkit Management: Support for both simple toolkit names and detailed configurations
  • Authentication Control: Per-toolkit auth config specification
  • Tool Filtering: Specify allowed tools across all toolkits
  • User Instance Generation: Generate user-specific MCP server instances

Basic Usage:

from composio import Composio

composio = Composio()

# Create MCP server with toolkit configurations
server = composio.mcp.create(
    'personal-mcp-server',
    toolkits=[
        {
            'toolkit': 'github',
            'auth_config_id': 'ac_xyz',
        },
        {
            'toolkit': 'slack',
            'auth_config_id': 'ac_abc',
        },
    ],
    allowed_tools=['GITHUB_CREATE_ISSUE', 'SLACK_SEND_MESSAGE'],
    manually_manage_connections=False
)

# Generate server instance for a user
mcp_instance = server.generate('user_12345')
print(f"MCP URL: {mcp_instance['url']}")

Simple Toolkit Usage:

# Using simple toolkit names
server = composio.mcp.create(
    'simple-mcp-server',
    toolkits=['composio_search', 'text_to_pdf'],
    allowed_tools=['COMPOSIO_SEARCH_DUCK_DUCK_GO_SEARCH', 'TEXT_TO_PDF_CONVERT_TEXT_TO_PDF']
)

# All tools from toolkits (default behavior)
server = composio.mcp.create(
    'all-tools-server',
    toolkits=['composio_search', 'text_to_pdf']
    # allowed_tools=None means all tools from these toolkits
)

LangChain Integration:

import asyncio
from composio import Composio
from langchain_mcp_adapters.client import MultiServerMCPClient
from langgraph.prebuilt import create_react_agent

composio = Composio()

mcp_config = composio.mcp.create(
    name="langchain-slack-mcp",
    toolkits=[{"toolkit": "slack", "auth_config_id": "<auth-config-id>"}],
)

mcp_server = mcp_config.generate(user_id='<user-id>')

client = MultiServerMCPClient({
    "composio": {
        "url": mcp_server["url"],
        "transport": "streamable_http",
    }
})

async def langchain_mcp(message: str):
    tools = await client.get_tools()
    agent = create_react_agent("openai:gpt-4.1", tools)
    response = await agent.ainvoke({"messages": message})
    return response

response = asyncio.run(langchain_mcp("Show me 20 most used slack channels"))

Added: Experimental ToolRouter

Core ToolRouter Features:

  • Session Management: Create isolated tool routing sessions for users
  • Toolkit Configuration: Support for both simple toolkit names and detailed configurations
  • Session Isolation: Each session gets its own MCP URL and session ID
  • Flexible Authentication: Per-session auth config management
  • Scoped Tool Access: Control which tools are available within each session

Basic Usage:

from composio import Composio

composio = Composio()

# Create a tool router session
session = composio.experimental.tool_router.create_session(
    user_id='user_123',
    toolkits=['github', 'slack'],
    manually_manage_connections=False
)

print(f"Session ID: {session['session_id']}")
print(f"MCP URL: {session['url']}")

Advanced Configuration:

# Create session with detailed toolkit configurations
session = composio.experimental.tool_router.create_session(
    user_id='user_456',
    toolkits=[
        {
            'toolkit': 'github',
            'auth_config_id': 'ac_github_123'
        },
        {
            'toolkit': 'slack',
            'auth_config_id': 'ac_slack_456'
        }
    ],
    manually_manage_connections=True
)

# Minimal session (no specific toolkits)
session = composio.experimental.tool_router.create_session(
    user_id='user_789'
)

Integration with AI Frameworks:

import asyncio
from composio import Composio
from langchain_mcp_adapters.client import MultiServerMCPClient

composio = Composio()

# Create tool router session
session = composio.experimental.tool_router.create_session(
    user_id='ai_user',
    toolkits=['composio_search', 'text_to_pdf']
)

# Use with LangChain MCP client
client = MultiServerMCPClient({
    "composio": {
        "url": session["url"],
        "transport": "streamable_http",
    }
})

async def use_tool_router():
    tools = await client.get_tools()
    # Use tools in your AI workflow
    return tools

tools = asyncio.run(use_tool_router())

Migration Guide

TypeScript SDK: Migrating to New MCP API

The new MCP API provides enhanced functionality and better integration patterns. Here's how to migrate from the previous MCP implementation:

Before (Legacy MCP)
// Legacy MCP approach (still accessible via deprecated.mcp)
import { class Composio<TProvider extends BaseComposioProvider<unknown, unknown, unknown> = OpenAIProvider>
This is the core class for Composio. It is used to initialize the Composio SDK and provide a global configuration.
Composio
} from '@composio/core';
const const composio: Composio<OpenAIProvider>composio = new new Composio<OpenAIProvider>(config?: ComposioConfig<OpenAIProvider> | undefined): Composio<OpenAIProvider>
Creates a new instance of the Composio SDK. The constructor initializes the SDK with the provided configuration options, sets up the API client, and initializes all core models (tools, toolkits, etc.).
@paramconfig - Configuration options for the Composio SDK@paramconfig.apiKey - The API key for authenticating with the Composio API@paramconfig.baseURL - The base URL for the Composio API (defaults to production URL)@paramconfig.allowTracking - Whether to allow anonymous usage analytics@paramconfig.provider - The provider to use for this Composio instance (defaults to OpenAIProvider)@example```typescript // Initialize with default configuration const composio = new Composio(); // Initialize with custom API key and base URL const composio = new Composio({ apiKey: 'your-api-key', baseURL: 'https://api.composio.dev' }); // Initialize with custom provider const composio = new Composio({ apiKey: 'your-api-key', provider: new CustomProvider() }); ```
Composio
();
// Old MCP server creation const const legacyMCP: anylegacyMCP = await const composio: Composio<OpenAIProvider>composio.deprecated.mcp.createServer({ name: stringname: 'my-server', toolkits: string[]toolkits: ['github', 'gmail'], }); // Direct URL usage const const mcpUrl: anymcpUrl = const legacyMCP: anylegacyMCP.url;
After (New MCP API)
// New MCP API approach
import { class Composio<TProvider extends BaseComposioProvider<unknown, unknown, unknown> = OpenAIProvider>
This is the core class for Composio. It is used to initialize the Composio SDK and provide a global configuration.
Composio
} from '@composio/core';
const const composio: Composio<OpenAIProvider>composio = new new Composio<OpenAIProvider>(config?: ComposioConfig<OpenAIProvider> | undefined): Composio<OpenAIProvider>
Creates a new instance of the Composio SDK. The constructor initializes the SDK with the provided configuration options, sets up the API client, and initializes all core models (tools, toolkits, etc.).
@paramconfig - Configuration options for the Composio SDK@paramconfig.apiKey - The API key for authenticating with the Composio API@paramconfig.baseURL - The base URL for the Composio API (defaults to production URL)@paramconfig.allowTracking - Whether to allow anonymous usage analytics@paramconfig.provider - The provider to use for this Composio instance (defaults to OpenAIProvider)@example```typescript // Initialize with default configuration const composio = new Composio(); // Initialize with custom API key and base URL const composio = new Composio({ apiKey: 'your-api-key', baseURL: 'https://api.composio.dev' }); // Initialize with custom provider const composio = new Composio({ apiKey: 'your-api-key', provider: new CustomProvider() }); ```
Composio
({
apiKey?: string | null | undefined
The API key for the Composio API.
@example'sk-1234567890'
apiKey
: var process: NodeJS.Processprocess.NodeJS.Process.env: NodeJS.ProcessEnv
The `process.env` property returns an object containing the user environment. See [`environ(7)`](http://man7.org/linux/man-pages/man7/environ.7.html). An example of this object looks like: ```js { TERM: 'xterm-256color', SHELL: '/usr/local/bin/bash', USER: 'maciej', PATH: '~/.bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin', PWD: '/Users/maciej', EDITOR: 'vim', SHLVL: '1', HOME: '/Users/maciej', LOGNAME: 'maciej', _: '/usr/local/bin/node' } ``` It is possible to modify this object, but such modifications will not be reflected outside the Node.js process, or (unless explicitly requested) to other `Worker` threads. In other words, the following example would not work: ```bash node -e 'process.env.foo = "bar"' &#x26;&#x26; echo $foo ``` While the following will: ```js import { env } from 'node:process'; env.foo = 'bar'; console.log(env.foo); ``` Assigning a property on `process.env` will implicitly convert the value to a string. **This behavior is deprecated.** Future versions of Node.js may throw an error when the value is not a string, number, or boolean. ```js import { env } from 'node:process'; env.test = null; console.log(env.test); // => 'null' env.test = undefined; console.log(env.test); // => 'undefined' ``` Use `delete` to delete a property from `process.env`. ```js import { env } from 'node:process'; env.TEST = 1; delete env.TEST; console.log(env.TEST); // => undefined ``` On Windows operating systems, environment variables are case-insensitive. ```js import { env } from 'node:process'; env.TEST = 1; console.log(env.test); // => 1 ``` Unless explicitly specified when creating a `Worker` instance, each `Worker` thread has its own copy of `process.env`, based on its parent thread's `process.env`, or whatever was specified as the `env` option to the `Worker` constructor. Changes to `process.env` will not be visible across `Worker` threads, and only the main thread can make changes that are visible to the operating system or to native add-ons. On Windows, a copy of `process.env` on a `Worker` instance operates in a case-sensitive manner unlike the main thread.
@sincev0.1.27
env
.string | undefinedCOMPOSIO_API_KEY,
}); // Step 1: Create MCP configuration const const mcpConfig: MCPConfigCreateResponsemcpConfig = await const composio: Composio<OpenAIProvider>composio.Composio<OpenAIProvider>.mcp: MCP
Model Context Protocol server management
mcp
.
MCP.create(name: string, mcpConfig: {
    toolkits: (string | {
        toolkit?: string | undefined;
        authConfigId?: string | undefined;
    })[];
    allowedTools?: string[] | undefined;
    manuallyManageConnections?: boolean | undefined;
}): Promise<MCPConfigCreateResponse>
Create a new MCP configuration.
@paramparams - Parameters for creating the MCP configuration@paramparams.authConfig - Array of auth configurations with id and allowed tools@paramparams.options - Configuration options@paramparams.options.name - Unique name for the MCP configuration@paramparams.options.manuallyManageConnections - Whether to use chat-based authentication or manually connect accounts@returnsCreated server details with instance getter@example```typescript const server = await composio.mcpConfig.create("personal-mcp-server", { toolkits: ["github", "slack"], allowedTools: ["GMAIL_FETCH_EMAILS", "SLACK_SEND_MESSAGE"], manuallyManageConnections: false } }); const server = await composio.mcpConfig.create("personal-mcp-server", { toolkits: [{ toolkit: "gmail", authConfigId: "ac_243434343" }], allowedTools: ["GMAIL_FETCH_EMAILS"], manuallyManageConnections: false } }); ```
create
('my-server', {
toolkits: (string | {
    toolkit?: string | undefined;
    authConfigId?: string | undefined;
})[]
toolkits
: [
{ toolkit?: string | undefinedtoolkit: 'github', authConfigId?: string | undefinedauthConfigId: 'ac_github_123' }, { toolkit?: string | undefinedtoolkit: 'gmail', authConfigId?: string | undefinedauthConfigId: 'ac_gmail_456' } ], allowedTools?: string[] | undefinedallowedTools: ['GITHUB_CREATE_ISSUE', 'GMAIL_SEND_EMAIL'], manuallyManageConnections?: boolean | undefinedmanuallyManageConnections: false, }); // Step 2: Generate user-specific server instance const
const serverInstance: {
    name: string;
    type: "streamable_http";
    id: string;
    userId: string;
    allowedTools: string[];
    url: string;
    authConfigs: string[];
}
serverInstance
= await const composio: Composio<OpenAIProvider>composio.Composio<OpenAIProvider>.mcp: MCP
Model Context Protocol server management
mcp
.
MCP.generate(userId: string, mcpConfigId: string, options?: {
    manuallyManageConnections?: boolean | undefined;
}): Promise<{
    name: string;
    type: "streamable_http";
    id: string;
    userId: string;
    allowedTools: string[];
    url: string;
    authConfigs: string[];
}>
Get server URLs for an existing MCP server. The response is wrapped according to the provider's specifications.
@example```typescript import { Composio } from "@composio/code"; const composio = new Composio(); const mcp = await composio.experimental.mcp.generate("default", "<mcp_config_id>"); ```@paramuserId external user id from your database for whom you want the server for@parammcpConfigId config id of the MCPConfig for which you want to create a server for@paramoptions additional options@paramoptions.isChatAuth Authenticate the users via chat when they use the MCP Server
generate
('user_123', const mcpConfig: MCPConfigCreateResponsemcpConfig.id: stringid);
const const mcpUrl: stringmcpUrl =
const serverInstance: {
    name: string;
    type: "streamable_http";
    id: string;
    userId: string;
    allowedTools: string[];
    url: string;
    authConfigs: string[];
}
serverInstance
.url: stringurl;
Key Migration Changes
  1. Two-Step Process:

    • Before: Single step server creation
    • After: Create configuration, then generate user instances
  2. Enhanced Configuration:

    • Before: Simple toolkit names only
    • After: Detailed toolkit configs with auth, tool filtering, connection management
  3. User-Specific URLs:

    • Before: Single server URL for all users
    • After: Unique URLs per user for better isolation
  4. Backward Compatibility:

    • Legacy Access: Old MCP functionality remains available via composio.deprecated.mcp
    • Gradual Migration: Migrate at your own pace without breaking existing implementations
Migration Benefits
  • Better Security: User-specific sessions with isolated access
  • Enhanced Control: Fine-grained toolkit and tool management
  • Framework Integration: Native support for modern AI frameworks
  • Scalability: Better resource management and user isolation
Migration Timeline
  • Phase 1: New MCP API available alongside legacy implementation
  • Phase 2: Legacy MCP accessible via deprecated.mcp namespace
  • Phase 3: Full deprecation (timeline to be announced)

Recommendation: Start new projects with the new MCP API and gradually migrate existing implementations to benefit from enhanced features and better framework integration.

Key Benefits & Use Cases

Development & Testing

  • Isolated Environments: Test different toolkit combinations without affecting production
  • Scoped Access: Limit tool access for security and testing purposes
  • Framework Flexibility: Works with any MCP-compatible client or framework

Production Workflows

  • Multi-Service Integration: Seamlessly combine tools from different services
  • User-Specific Sessions: Each user gets their own isolated session with appropriate permissions
  • Authentication Management: Fine-grained control over authentication per toolkit

Framework Compatibility

  • Vercel AI: Native integration with Vercel AI SDK
  • Mastra: Full support for Mastra agents and workflows
  • OpenAI Agents: Direct integration with OpenAI's agent framework
  • LangChain: Complete LangGraph and LangChain compatibility
  • Custom Clients: Works with any MCP-compatible client

Enterprise Features

  • Session Management: Track and manage multiple user sessions
  • Resource Control: Limit concurrent sessions and resource usage
  • Audit Trail: Full logging and monitoring of tool usage
  • Security: Isolated sessions prevent cross-user data access

Migration & Compatibility

Both MCP and ToolRouter features are designed to complement existing Composio functionality:

// Can be used alongside regular tool management
const const regularTools: anyregularTools = await composio.tools.get({ toolkits: string[]toolkits: ['github'] });
const const mcpSession: anymcpSession = await composio.experimental.toolRouter.createSession(userId, {
  toolkits: string[]toolkits: ['gmail', 'slack']
});

// Both approaches can coexist and serve different purposes

The experimental ToolRouter API provides a preview of advanced session management capabilities, while the MCP API offers production-ready Model Control Protocol support for modern AI frameworks.

Bug Fixes

Fixed: ToolRouter Dependency Issue

Python SDK (v0.8.19)

Issue Fixed:

  • ToolRouter Functionality: Fixed ToolRouter tests that were failing due to missing tool_router attribute in HttpClient
  • Dependency Update: Updated composio-client dependency from version 1.9.1 to 1.10.0+ to include ToolRouter functionality
  • Version Compatibility: Resolved compatibility issues between ToolRouter implementation and client library

Details: ToolRouter functionality was briefly broken in versions 0.8.15 to 0.8.18 due to a dependency version mismatch. The composio-client library version 1.9.1 did not include the tool_router attribute, causing all ToolRouter integration tests to fail with AttributeError: 'HttpClient' object has no attribute 'tool_router'.

This has been fixed in version 0.8.19 by:

  • Updating the composio-client dependency to version 1.10.0+
  • Ensuring all ToolRouter functionality is now available
  • All ToolRouter integration tests now pass successfully

Previous Issue:

# This would fail in versions 0.8.15-0.8.18
session = composio.experimental.tool_router.create_session(user_id='test')
# AttributeError: 'HttpClient' object has no attribute 'tool_router'

Fixed in 0.8.19:

# This now works correctly
session = composio.experimental.tool_router.create_session(user_id='test')
# Returns: {'session_id': '...', 'url': '...'}

Fixed: Missing Descriptions in Auth Config Fields

Python SDK (v0.8.17) & TypeScript SDK (v0.1.53)

Issue Fixed:

  • Auth Config Connection Fields: Added missing descriptions to toolkit auth configuration connection fields
  • Auth Config Creation Fields: Added missing descriptions to toolkit auth configuration creation fields
  • Field Documentation: Improved field documentation and help text for better developer experience

Details: Previously, when developers were setting up auth configurations for toolkits, many fields lacked proper descriptions, making it difficult to understand what information was required. This fix ensures all auth config fields now include:

  • Clear, descriptive field labels
  • Helpful placeholder text where appropriate
  • Detailed explanations of field requirements

This improvement affects all toolkits and makes the authentication setup process more intuitive and error-free.

Toolkit Versioning in SDKs

Composio Toolkit Versioning provides granular control over tool versions across all your integrations. Instead of always using the latest version of tools, developers can now specify exact toolkit versions, ensuring consistent behavior and controlled updates in production environments.

Why Use Toolkit Versioning?

  • Version Stability: Pin specific toolkit versions to avoid unexpected changes in production
  • Controlled Updates: Test new toolkit versions before deploying to production
  • Environment Consistency: Ensure the same toolkit versions across development, staging, and production
  • Rollback Capability: Easily revert to previous toolkit versions if issues arise
  • Fine-grained Control: Set different versions for different toolkits based on your needs

Python SDK (v0.8.11)

Added

  • Toolkit Versioning Support: New toolkit_versions parameter for controlling tool versions
    • Added toolkit_versions parameter to Composio class initialization
    • Support for global version setting (e.g., 'latest')
    • Support for per-toolkit version mapping (e.g., {'github': '20250902_00', 'slack': '20250902_00'})
    • Environment variable support with COMPOSIO_TOOLKIT_VERSION_<TOOLKIT_NAME> pattern
    • New toolkit_version.py utility module for version resolution logic

Examples:

# Global version for all toolkits, only `latest` is supported
composio = Composio(toolkit_versions='latest')

# Per-toolkit version mapping
composio = Composio(toolkit_versions={
    'github': '20250902_00',
    'slack': '20250902_00',
    'gmail': '20250901_01'
})

# Using environment variables
# Set COMPOSIO_TOOLKIT_VERSION_GITHUB=20250902_00
composio = Composio()  # Automatically picks up env vars

# Get tools with specific versions
tools = composio.tools.get('default', {'toolkits': ['github']})

TypeScript SDK (v0.1.52)

Added

  • Toolkit Versioning Support: Added toolkitVersions configuration option
    • New toolkitVersions parameter in Composio class constructor
    • Support for global version string or per-toolkit version mapping
    • Environment variable parsing with getToolkitVersionsFromEnv() utility
    • Enhanced getRawComposioToolBySlug() method for version-specific tool retrieval
    • Version-aware tool filtering and search capabilities

Examples:

// Global version for all toolkits
const const composio: anycomposio = new Composio({
  toolkitVersions: stringtoolkitVersions: '20250902_00'
});

// Per-toolkit version mapping
const const composio: anycomposio = new Composio({
  
toolkitVersions: {
    github: string;
    slack: string;
    gmail: string;
}
toolkitVersions
: {
'github': '20250902_00', 'slack': '20250902_00', 'gmail': '20250901_01' } }); // Using environment variables // Set COMPOSIO_TOOLKIT_VERSION_GITHUB=20250902_00 const const composio: anycomposio = new Composio(); // Automatically picks up env vars // Get specific tool version const const tool: anytool = await const composio: anycomposio.tools.getRawComposioToolBySlug( 'GITHUB_GET_REPO', ); // Get tools with version-aware filtering const const tools: anytools = await const composio: anycomposio.tools.get('default', { toolkits: string[]toolkits: ['github'], limit: numberlimit: 10 });

Key Benefits

  • Environment Variables: Set COMPOSIO_TOOLKIT_VERSION_<TOOLKIT_NAME>=<VERSION> for automatic version resolution
  • Flexible Configuration: Choose between global versions or per-toolkit version mapping
  • Backward Compatibility: Existing code works unchanged - versioning is opt-in
  • Version Fallback: Automatically falls back to 'latest' when no version is specified
  • Cross-Platform Consistency: Identical developer experience across Python and TypeScript

Version Format

Toolkit versions follow the format: YYYYMMDD_NN (e.g., 20250902_00) or use 'latest' for the most recent version only supported at global scope and not individual toolkit level.

Environment Variables

# Set specific versions for different toolkits
export COMPOSIO_TOOLKIT_VERSION_GITHUB=20250902_00
export COMPOSIO_TOOLKIT_VERSION_SLACK=20250902_00
export COMPOSIO_TOOLKIT_VERSION_GMAIL=20250901_01

Migration Note

This feature is fully backward compatible. Existing code will continue to work without changes, using the latest versions by default. To enable versioning, simply add the toolkit_versions parameter during SDK initialization.


Additional Updates

  • Package Updates: Bumped all Python provider packages to v0.8.10
  • Documentation: Enhanced API documentation with versioning examples
  • Testing: Added comprehensive test coverage (400+ new test cases) for versioning functionality
  • Examples: New versioning examples demonstrating practical usage patterns

Introducing Composio Auth Links

Composio Auth Links provide a hosted authentication solution that eliminates the need for developers to build custom authentication forms. Instead of manually rendering OAuth consent screens, API key input forms, or custom authentication fields, developers can simply redirect users to a Composio-hosted URL that handles the entire authentication process automatically.

  • Zero UI Development: No need to build forms for OAuth, API keys, or custom fields like subdomains
  • Universal Authentication: Works seamlessly across all supported third-party services
  • Reduced Complexity: Replace complex OAuth flows with a simple redirect
  • Better UX: Professional, consistent authentication experience for end users
  • Faster Integration: Get authentication working in minutes, not hours

Python SDK (v0.8.11)

Added

  • Composio Connect Link Support: New link() method for creating external authentication links
    • Added link() method to ConnectedAccounts class for generating user authentication links
    • Support for callback URL redirection after authentication
    • Enhanced user experience with external link-based authentication flow
    • No manual form rendering required - Composio handles all authentication UI

Examples:

# Basic usage - create a connection request
connection_request = composio.connected_accounts.link('user_123', 'auth_config_123')
redirect_url = connection_request.redirect_url
print(f"Visit: {redirect_url} to authenticate your account")

# Wait for the connection to be established
connected_account = connection_request.wait_for_connection()

# With callback URL
connection_request = composio.connected_accounts.link(
    'user_123',
    'auth_config_123',
    callback_url='<https://your-app.com/callback>'
)

TypeScript SDK (v0.1.51)

Added

  • Composio Connect Links: Added support for composio connect links
    • New link() method in ConnectedAccounts class for generating authentication URLs
    • Support for callback URL redirection with CreateConnectedAccountLinkOptions
    • Comprehensive TypeScript types and validation for link creation options
    • Eliminates need for custom authentication forms - just redirect users to the link

Examples:

// Basic usage - create a connection request
const const connectionRequest: anyconnectionRequest = await composio.connectedAccounts.link('user_123', 'auth_config_123');
const const redirectUrl: anyredirectUrl = const connectionRequest: anyconnectionRequest.redirectUrl;
var console: Console
The `console` module provides a simple debugging console that is similar to the JavaScript console mechanism provided by web browsers. The module exports two specific components: * A `Console` class with methods such as `console.log()`, `console.error()` and `console.warn()` that can be used to write to any Node.js stream. * A global `console` instance configured to write to [`process.stdout`](https://nodejs.org/docs/latest-v24.x/api/process.html#processstdout) and [`process.stderr`](https://nodejs.org/docs/latest-v24.x/api/process.html#processstderr). The global `console` can be used without importing the `node:console` module. _**Warning**_: The global console object's methods are neither consistently synchronous like the browser APIs they resemble, nor are they consistently asynchronous like all other Node.js streams. See the [`note on process I/O`](https://nodejs.org/docs/latest-v24.x/api/process.html#a-note-on-process-io) for more information. Example using the global `console`: ```js console.log('hello world'); // Prints: hello world, to stdout console.log('hello %s', 'world'); // Prints: hello world, to stdout console.error(new Error('Whoops, something bad happened')); // Prints error message and stack trace to stderr: // Error: Whoops, something bad happened // at [eval]:5:15 // at Script.runInThisContext (node:vm:132:18) // at Object.runInThisContext (node:vm:309:38) // at node:internal/process/execution:77:19 // at [eval]-wrapper:6:22 // at evalScript (node:internal/process/execution:76:60) // at node:internal/main/eval_string:23:3 const name = 'Will Robinson'; console.warn(`Danger ${name}! Danger!`); // Prints: Danger Will Robinson! Danger!, to stderr ``` Example using the `Console` class: ```js const out = getStreamSomehow(); const err = getStreamSomehow(); const myConsole = new console.Console(out, err); myConsole.log('hello world'); // Prints: hello world, to out myConsole.log('hello %s', 'world'); // Prints: hello world, to out myConsole.error(new Error('Whoops, something bad happened')); // Prints: [Error: Whoops, something bad happened], to err const name = 'Will Robinson'; myConsole.warn(`Danger ${name}! Danger!`); // Prints: Danger Will Robinson! Danger!, to err ```
@see[source](https://github.com/nodejs/node/blob/v24.x/lib/console.js)
console
.Console.log(message?: any, ...optionalParams: any[]): void (+1 overload)
Prints to `stdout` with newline. Multiple arguments can be passed, with the first used as the primary message and all additional used as substitution values similar to [`printf(3)`](http://man7.org/linux/man-pages/man3/printf.3.html) (the arguments are all passed to [`util.format()`](https://nodejs.org/docs/latest-v24.x/api/util.html#utilformatformat-args)). ```js const count = 5; console.log('count: %d', count); // Prints: count: 5, to stdout console.log('count:', count); // Prints: count: 5, to stdout ``` See [`util.format()`](https://nodejs.org/docs/latest-v24.x/api/util.html#utilformatformat-args) for more information.
@sincev0.1.100
log
(`Visit: ${const redirectUrl: anyredirectUrl} to authenticate your account`);
// Wait for the connection to be established const const connectedAccount: anyconnectedAccount = await const connectionRequest: anyconnectionRequest.waitForConnection(); // With callback URL const const connectionRequest: anyconnectionRequest = await composio.connectedAccounts.link('user_123', 'auth_config_123', { callbackUrl: stringcallbackUrl: '<https://your-app.com/callback>' });

Key Benefits

  • No Form Building: Composio handles OAuth consent, API key collection, and custom field inputs
  • Hosted Authentication Flow: Professional UI that works across all supported services
  • Callback URL Support: Control where users return after successful authentication
  • Connection Waiting: Built-in polling to detect when authentication completes
  • Cross-Platform Consistency: Identical developer experience across Python and TypeScript

Customisation

You can customise the app logo and name showed in the authentication page via the dashboard. Head over your project via platform.composio.dev and choose Settings → Auth Links to upload a new logo and change the name.

Migration Note

This feature replaces manual authentication form development with a simple redirect-based approach, significantly reducing integration time and complexity while providing a better user experience. Auth links are drop in replacement for composio.connectedAccounts.initate, you can safely swap this to composio.connectedAccounts.link