Sendbird sells the chat that lives inside your product: SDKs for chat, voice and video, with AI agents layered on more recently. It has historically priced against monthly active users, which is the detail that sends most people looking — the bill grows with your success rather than with your usage.
Before shortlisting a replacement, work out which of these you are:
You need in-app chat, cheaper
- Users genuinely talk to each other in your product
- The conversation needs product context around it
- You need moderation, roles and history
- The problem is the invoice, not the channel
You need to reach people
- Chat works fine; almost nobody opens it
- Push notifications are opted out of or ignored
- The messages are time-sensitive
- You are paying per active user to talk to people who are not active
If it is the first: the chat SDK shortlist
| Alternative | What it is | Pick it when |
|---|---|---|
| Stream | Chat, feeds and video SDKs, the closest direct equivalent | You want a like-for-like swap with mature SDKs and do not want to change your architecture |
| CometChat | Chat SDK with a lot of prebuilt UI | You want to ship the interface as well as the plumbing, quickly |
| Twilio Conversations | One thread that can span in-app chat, SMS and WhatsApp | The same conversation needs to continue when the customer is not in the app |
| PubNub / Ably | Realtime message infrastructure rather than a chat product | You want to build the chat semantics yourself and just need reliable delivery and presence |
| Matrix (Synapse, Element) | An open federated protocol with end-to-end encryption, self-hosted | You need to own the data, or you need real E2EE — see secure messaging API |
| Rocket.Chat | Open-source team chat you can self-host, with APIs | Internal or workspace-shaped chat rather than customer-facing product chat |
| Your own database and a websocket | Not a joke for simple cases | The chat is a support thread with a text box and no presence, typing or moderation requirements |
The migration cost is the message history, not the SDK
Swapping the client library is a sprint. Moving years of messages, attachments, read state and threading between two providers' data models is the project. Ask every shortlisted vendor for their import path before you ask for a discount.
If it is the second: the channel is the problem
In-app chat has one structural weakness that no vendor can engineer away. It reaches the people who open the app. For a product people live in, that is everyone. For a product people use monthly — a garage, a clinic, a marketplace, most B2C software — it is a small and shrinking fraction, and paying per monthly active user to message people who are not monthly active is a strange way to spend money.
The phone does not have that weakness. A text message arrives on the lock screen of a device the customer is already holding, with no app to open, no push permission to have granted, and no account to be logged into.
| In-app chat | The phone | |
|---|---|---|
| Requires the app installed | Yes | No |
| Requires the app opened | Yes | No |
| Requires a push permission | Effectively yes | No |
| Works for a lapsed customer | No | Yes |
| Priced against | Monthly active users | Lines and messages |
| Good for user-to-user conversation | Yes | No — you do not want to be the middle of that |
Which phone channel depends on who you are messaging. SMS reaches everyone and looks like everything else in the inbox. RCS is better on Android and worse everywhere else. iMessage is the one that arrives in blue, reads as a person rather than a broadcast, and carries typing indicators, read receipts and full-quality media — and Apple publishes no API for it, which is why a whole category of vendors exists to bridge the gap.
Do not move the wrong conversations
Marketplace conversations between two users, anything that needs moderation, anything where the platform must stay in the middle for good commercial reasons, and anything requiring in-product context should stay in the app. Reminders, confirmations, updates, follow-ups and one-to-one support are the ones that get read on the phone and ignored in the app.
What that costs, roughly
A hosted iMessage line is a flat monthly cost — the published floor is $19/month, most useful plans land between $39 and $100, and dedicated business lines run higher. There is no per-active-user component, which is the entire structural difference from a chat SDK bill.
- [What each provider charges](/pricing) — every published number in the category, in one table.
- [Who sells an iMessage API](/answers/who-sells-an-imessage-api) — the field, sorted by what each vendor actually is.
- [iMessage API vs RCS API](/compare/imessage-api-vs-rcs) — if the fleet you are messaging is mostly Android.
- [When not to use iMessage](/guides/when-not-to-use-imessage) — the honest limits, before you move anything.
Common questions
- What is the best Sendbird alternative?
- It depends which half of the problem you have. For in-app chat, Stream and CometChat are the nearest equivalents and Twilio Conversations adds SMS and WhatsApp in the same thread. For self-hosting, Matrix or Rocket.Chat. If the real issue is that customers do not open the app, the alternative is a phone channel rather than another SDK.
- Is Sendbird the same as Twilio?
- No. Sendbird sells chat, voice and video SDKs that live inside your product. Twilio is a communications platform whose core business is reaching people outside your product — SMS, voice, WhatsApp — with Conversations layering in-app chat on top of that. They overlap in the middle and are aimed at different starting points.
- Can I replace in-app chat with text messaging?
- Sometimes. Notifications, reminders, confirmations, two-way support for consumer businesses and anything time-sensitive all work better on the phone. Anything that needs message history tied to in-product context, moderation of user-to-user conversation, or both sides kept on the platform should stay in the app.
- Why does an iMessage site come up when searching for Sendbird alternatives?
- Because a meaningful share of that search is people whose in-app chat is not being read, and the honest answer for them is a different channel rather than a different SDK. If you want a chat SDK, the shortlist above is the useful part of this page.