Migrating triggers from V1 to V2
This guide covers migrating from Composio's older V1 trigger slugs (e.g. SLACK_RECEIVE_MESSAGE)
to the V2 triggers, which are a real step up on the security front. Your existing connected
accounts carry over — this is a slug + endpoint change, not a re-auth.
Available today for Slack and Slackbot. V2 is rolling out toolkit by toolkit — Slack and Slackbot are live now, and more will follow. If your V1 triggers are on a toolkit not yet listed here, there's nothing to do until V2 lands for it.
Already on the V2 slugs (SLACK_CHANNEL_MESSAGE_RECEIVED, SLACK_DIRECT_MESSAGE_RECEIVED,
SLACK_MESSAGE_REACTION_ADDED)? You're done — nothing to do.
Why V2
V2 triggers run on a dedicated, per-app webhook endpoint with security advancements built in:
- Signature verification at ingress — every request is cryptographically verified (HMAC-SHA256) against your signing secret, so third parties can't spoof events onto your triggers.
- Replay protection — requests with a stale Slack timestamp (outside a 5-minute window) are rejected.
- Per-user authorization — for private channels and DMs, only the users actually authorized for an event have their triggers fire.
- Automatic handshakes — Composio answers Slack's
url_verificationchallenge for you.
Slug mapping
Each deprecated slug maps to a V2 equivalent. The _RECEIVE_*_MESSAGE family consolidates into one
*_CHANNEL_MESSAGE_RECEIVED trigger that you narrow with a channel_type filter.
| Deprecated (Slack / Slackbot) | V2 replacement |
|---|---|
SLACK_RECEIVE_MESSAGE / SLACKBOT_RECEIVE_MESSAGE | SLACK_CHANNEL_MESSAGE_RECEIVED / SLACKBOT_CHANNEL_MESSAGE_RECEIVED |
SLACK_RECEIVE_GROUP_MESSAGE | SLACK_CHANNEL_MESSAGE_RECEIVED (filter channel_type) |
SLACK_RECEIVE_MPIM_MESSAGE | SLACK_CHANNEL_MESSAGE_RECEIVED (filter channel_type) |
SLACK_RECEIVE_THREAD_REPLY | SLACK_CHANNEL_MESSAGE_RECEIVED |
SLACK_RECEIVE_BOT_MESSAGE | SLACK_CHANNEL_MESSAGE_RECEIVED |
SLACK_RECEIVE_DIRECT_MESSAGE / SLACKBOT_RECEIVE_DIRECT_MESSAGE | SLACK_DIRECT_MESSAGE_RECEIVED / SLACKBOT_DIRECT_MESSAGE_RECEIVED |
SLACK_REACTION_ADDED / SLACKBOT_REACTION_ADDED | SLACK_MESSAGE_REACTION_ADDED / SLACKBOT_MESSAGE_REACTION_ADDED |
How to migrate
Two steps: set up a V2 webhook endpoint (one-time, per Slack app), then switch your trigger slugs.
On Composio-managed OAuth this is already provisioned — skip to step 2. If you bring your own
Slack app, follow
Configuring the webhook endpoint:
discover the schema, create the endpoint, store your signing secret and app-level token, and point
your Slack app's Event Subscriptions → Request URL at the returned webhook_url.
Some toolkits have provider-specific setup (e.g. Notion's verification flow) — see the toolkit's FAQ.
Recreate your trigger instances on the V2 slugs from the mapping table above:
curl -X POST "https://backend.composio.dev/api/v3.1/trigger_instances/SLACK_CHANNEL_MESSAGE_RECEIVED/upsert" \
-H "x-api-key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "connected_account_id": "CONNECTED_ACCOUNT_ID", "trigger_config": {} }'Sharing one Slack OAuth app across multiple Composio projects? On V2 each OAuth app is tied to a single project — that's what gives every project its own event isolation and rate limits, so one project's webhook volume can't affect another. Pick the project that should own the app, or register a separate Slack app per project.