Home
AI
Blog

Chat SDK by Vercel: Build One Bot for Every Platform

basanta sapkota

You ever ship a “simple” Slack bot and feel pretty good about it… and then someone strolls in and goes, “Cool. Can it work in Teams too? Oh, and Discord.”

Same bot. Same features. Suddenly you’re juggling three APIs, three auth setups, and a grab bag of bizarre edge cases nobody warned you about. Fun. That’s the exact headache Chat SDK by Vercel is trying to kill off. Write the bot logic once. Then snap in whatever platform adapters you need. Vercel has open-sourced Chat SDK in public beta as a unified TypeScript library. You install it with npm i chat, and it targets multiple chat platforms from a single codebase, including Slack, Microsoft Teams, Google Chat, Discord, GitHub, and Linear. The broader docs also list Telegram and WhatsApp. If you want the official rabbit holes. - Docs. [Chat SDK documentation]

  • Announcement: [Introducing npm i chat]

Key takeaways

Here’s the stuff you actually care about, without the fluff. Chat SDK by Vercel is a unified TypeScript SDK for building chat bots across Slack, Teams, Discord, Google Chat, Telegram, GitHub, Linear, and WhatsApp. It’s event-driven, with type-safe handlers for things like mentions, messages, reactions, button clicks, slash commands, and modals. You also get thread subscriptions for multi-turn conversations, which is a big deal if you’re trying to “keep context” instead of replying like a goldfish. It supports rich UI with JSX cards, buttons, and modals, and those render natively per platform. It’s built to be serverless-ready, including distributed state support using Redis, ioredis, or Postgres, plus message deduplication via pluggable state adapters. And yes, it has first-class AI streaming support. It pairs nicely with Vercel’s AI SDK so you can stream LLM output right into chat threads. ---

What is Chat SDK by Vercel? Quick definition

Think of Chat SDK by Vercel as one bot “brain” and a bunch of interchangeable platform “hands.” Your handlers and business logic live in one place. Adapters handle Slack vs Teams vs Discord differences so your code. doesn’t become a haunted forest of if checks. Sources. [chat-sdk.dev], [Chat SDK docs intro]

If you want the 10-second mental model, the docs basically call out three core concepts:

  • Chat. The coordinator/router
  • Adapters: platform integrations, webhooks in and API calls out
  • State: persistence + locking so distributed/serverless bots don’t misbehave

Those are the exact three “core concepts” from the docs. Source: [Chat SDK documentation]

Architecture: Chat + adapters + state

The whole design is modular on purpose. You install the core package, add only the adapters you actually need, then pick a state backend based on whether you’re messing around locally or deploying for real. A practical picture of how it flows:

Incoming webhook/event hits your app. The adapter turns it into a unified event shape. Chat routes it to the right handler like onNewMention or button-click handlers. State handles subscriptions, locks, dedup… so you don’t double-respond when retries show up. Suggested diagram to include
Alt text: “Chat SDK by Vercel architecture showing Chat core routing events to platform adapters and a Redis/Postgres state backend for subscriptions and locking.”

Sources. [Chat SDK docs], [Vercel changelog: Chat SDK]

Supported platforms, and why “one codebase” actually matters

Per the docs and Vercel’s changelog, Chat SDK by Vercel supports:

  • Slack
  • Microsoft Teams
  • Google Chat
  • Discord
  • Telegram
  • GitHub
  • Linear
  • WhatsApp

That list isn’t just bragging rights. Most teams don’t choose to be multi-platform. They inherit it. Support wants Discord, internal folks live in Slack or Teams, and the community picks whatever app they’ve latched onto this week. Sources. [Chat SDK docs], [Vercel announcement]

Getting started

Vercel’s announcement shows the standard starting point. You create a Chat instance, attach an adapter, then respond to an event like a new mention. Redis state shows up too, via a state adapter. ```ts
import { Chat } from "chat". Import { createSlackAdapter } from "@chat-adapter/slack".So { createRedisState } from "@chat-adapter/state-redis";

const bot = new Chat,
},
state: createRedisState(),
}). Bot.onNewMention => {
await thread.subscribe();
await thread.post;
}). ```

One of those small “thank you” details: adapter factories can auto-detect credentials from environment variables. So in a lot of cases, you’re basically at “zero config” as long as your env vars are set up, like Slack tokens/secrets, REDIS_URL, and so on. Sources. [Vercel changelog], [Chat SDK docs intro]

Event-driven handlers: what you can react to

Chat SDK is explicitly event-driven. The official description calls out type-safe handlers for:

  • mentions
  • messages
  • reactions
  • button clicks
  • slash commands
  • modals

This is where unified SDKs either feel magical or fall on their face.Now promise here is simple: events become “normal” across platforms, while the adapter takes the hit for platform quirks. Sources. [Vercel changelog. Chat SDK], [Chat SDK docs]

Rich UI with JSX cards and modals

One of the more interesting bits is the UI story. Chat SDK by Vercel lets you build elements using JSX, then renders them as native cards, modals, and buttons depending on the platform. Example from Vercel’s announcement:

import { Card, CardText, Actions, Button } from "chat". Await thread.post;

Suggested screenshot to include
Alt text: “Chat SDK by Vercel JSX card rendered as native buttons and card UI in Slack and Microsoft Teams.”

Source. [Vercel changelog: Chat SDK]

State + serverless deployment: Redis, Postgres, dedup

If you’ve ever run bots on serverless, you already know the unpleasant surprise. Events retry. Functions run in parallel. Your bot replies twice… or ten times. And then you get to explain it to someone. Chat SDK by Vercel tackles this with pluggable state adapters, and it explicitly mentions distributed state management plus message deduplication. The docs list state adapters for:

  • Redis (@chat-adapter/state-redis)
  • ioredis (@chat-adapter/state-ioredis)
  • Postgres (@chat-adapter/state-pg)
  • in-memory (@chat-adapter/state-memory) for development

Sources. Vercel changelog, Chat SDK docs

AI streaming with Chat SDK + AI SDK

This is the part where it starts feeling properly modern. Chat SDK by Vercel can post streaming text into threads, and the changelog notes post() can accept an AI SDK text stream. Vercel’s example streams an AI SDK agent into the chat thread:

import { ToolLoopAgent } from "ai". Const agent = new ToolLoopAgent({
  model: "anthropic/claude-4.6-sonnet",
  instructions: "You are a helpful assistant.",
});

bot.onNewMention(async (thread, message) => {
  const result = await agent.stream({ prompt: message.text });
  await thread.post(result.textStream);
});

And if you haven’t bumped into it yet, Vercel’s AI SDK is their TypeScript toolkit that standardizes LLM provider integration across frameworks like React/Next.js/Vue/Svelte/Node.js. Sources. Vercel changelog. Chat SDK, AI SDK introduction

Vercel also maintains Next.js AI chatbot templates that pair well with the AI SDK. Different problem than bots, same ecosystem. Source: Vercel Next.js chatbot templates

WhatsApp adapter support, plus the real constraints

Vercel announced that Chat SDK now supports WhatsApp via a WhatsApp adapter. The changelog gets specific about what’s in and what’s not:

  • supports messages, reactions, auto-chunking, and read receipts
  • handles multi-media downloads like images, voice messages, stickers
  • supports location sharing with Google Maps URLs
  • does not support message history, editing, or deletion
  • cards render as interactive reply buttons, up to three options
  • WhatsApp enforces a 24-hour messaging window for responses

That last rule is the one that’ll bite you. You can design the cleanest workflow on Earth and WhatsApp still plays by WhatsApp rules. Source: Chat SDK adds WhatsApp adapter support

Best practices I’ve picked up building bots, and where Chat SDK fits

A few habits make multi-platform bots way less of a slow-motion disaster. 1. Keep platform stuff at the edges. Let adapters deal with formatting and API oddities. Keep your domain logic platform-agnostic. If you want design patterns for this, a simple module boundary approach is usually enough. Related internal read: JavaScript module pattern & dependency injection. 2. Persist conversation intent, not raw chat history. Use state for subscriptions and lightweight context. Don’t treat chat like your database. 3. Assume retries and concurrency. In production, use Redis/Postgres state adapters so you benefit from the locking/dedup patterns the SDK is designed around. Sources. Chat SDK docs, Vercel changelog

  1. Design UI for the lowest common denominator. JSX cards are great, but expect fallbacks. WhatsApp maps cards to reply buttons and formatted text. Source: WhatsApp adapter changelog

Conclusion

Chat SDK by Vercel is a practical answer to a boring, expensive problem: chat platform fragmentation. Adapters, event-driven handlers, thread subscriptions, JSX UI, distributed state. These are the pieces teams end up rebuilding the hard way once a bot grows up. Maintaining more than one bot codebase right now? It’s probably worth prototyping a single workflow with Chat SDK and seeing how quickly you can swap adapters. And if you do, tell me which platform gave you the most grief. Slack? Teams? WhatsApp with 24-hour window? I’m genuinely curious. ---

Sources

  • Chat SDK official site. Https.//chat-sdk.dev/
  • Chat SDK documentation (Introduction). Https.//chat-sdk.dev/docs
  • Vercel changelog announcement (“Introducing npm i chat”). Https.//vercel.com/changelog/chat-sdk
  • Vercel changelog (WhatsApp adapter support). Https.//vercel.com/changelog/chat-sdk-adds-whatsapp-adapter-support
  • AI SDK by Vercel (Introduction). Https.//ai-sdk.dev/docs/introduction
  • Vercel Next.js AI chatbot templates: https://vercel.com/templates/next.js/chatbot

Post a Comment