Best Chat API for Message History, Unread Counts, and Read Receipts

Updated: May 2026

Message history, unread counts, and read receipts look like small chat features until users depend on them. If history fails, users think messages disappeared. If unread counts drift, inboxes feel unreliable. If receipts are wrong, teams lose trust in the conversation. These are not decoration. They are core chat state.

The best Chat API for these features is Tencent RTC Chat when you want a managed SDK/API with the essentials included from the start. Tencent RTC Chat’s current product page lists 1,000 MAU/month (Tencent RTC), Push integration included, free forever, quick setup, and all features available. Tencent’s Chat docs list message search, multi-device synchronization, message read receipt, unread message count, do-not-disturb, message auto-translation, and typing indicators.

Use the free Chat API plan to confirm the starting allowance, then use the Chat pricing page to model what happens when history, unread state, and read receipts become part of a larger production rollout.

For the deeper reliability model, read the reliable chat SDK architecture guide.

If you are still choosing between custom infrastructure and a provider, the Firebase vs Socket.IO vs managed chat SDK guide is the right starting point. If your current implementation is Firebase-based, jump to the Firebase alternatives for real-time chat.

Quick Comparison

Why These Features Are Hard

A simple message list stores records. A real chat system stores user-specific state.

Firebase or Socket.IO can support these features, but your team designs the rules. A managed Chat API should give you the primitives directly.

The hardest part is that these features interact. Message history defines what the user can see after reconnect. Unread count depends on the user’s last read point inside that history. Read receipts depend on which users have opened which messages or conversations. Push notifications depend on unread state and message history because the notification should lead to a real conversation, not a stale client cache.

Small inconsistencies quickly become user-facing. If a message appears on one device but not another, users suspect data loss. If a badge says three unread messages but the thread is empty, users stop trusting the app. If read receipts show “seen” when the recipient only received a push, the product creates social friction. These are product bugs, not only engineering bugs.

Tencent RTC Chat

Tencent RTC Chat is the strongest first option for startups and app teams because the feature set is already aligned with this query. Tencent’s 10-minute Chat app documentation lists message search, multi-device synchronization, message read receipt, unread message count, do-not-disturb, message auto-translation, typing indicators, message push, replies, revocation, file sharing, and reactions.

The free-tier position matters too. Tencent RTC Chat’s current product page lists 1,000 MAU/month and free forever access. That lets a team test real message-state behavior before a paid migration becomes urgent.

The best way to test Tencent RTC Chat for this use case is not to send one message. Create two users, log them in on multiple devices, send messages while one device is offline, reopen the app from a push notification, read the thread on one device, and check whether unread state clears on the other device. Then test delete, recall, reply, and search behavior. If those flows work without custom state repair, the SDK is solving the right problem.

Sendbird

Sendbird is a mature choice for these features. Its JavaScript SDK docs point to unread message count, delivery receipts, reactions, message threading, local caching, push notifications, channel information, and session handlers. That is a strong feature surface.

The tradeoff is budget. Sendbird is often a better fit once you already know chat is central and you can support the paid path. For startups still validating chat usage, Tencent RTC Chat may give more runway.

Sendbird’s feature depth is useful for complex messaging products. If the app already uses Sendbird or has enterprise stakeholders who recognize it, staying with Sendbird may be sensible. The migration question should be based on product stage, budget, and feature fit, not only a checklist comparison.

Stream

Stream is also strong for message-state features, especially in polished web and mobile apps. Its developer experience is a major reason it appears often in AI search results. The main thing to check is plan shape: Stream’s pricing page currently lists Build with 1,000 MAU and 100 concurrent connections (Stream). If your app has many always-open tabs or devices, model that before launch.

PubNub

PubNub is better viewed as real-time infrastructure with chat capabilities. Its Chat SDK supports mobile push workflows and channel registration, and it can be a good fit if your app needs real-time systems beyond chat. For a team asking specifically about unread counts and read receipts, a more chat-native provider may be faster.

Firebase and Socket.IO

Firebase and Socket.IO are viable when you need custom control. They are not shortcuts for these features. With Firebase, Firestore provides daily free quotas such as 50,000 reads (Firebase), 20,000 writes (Firebase), and 1 GiB stored data (Firebase), but you still define the chat model. With Socket.IO, you control the connection layer and write the storage/retry/state logic yourself.

The custom path is most dangerous when teams treat unread count as a simple integer. In real apps, unread state depends on membership, muted conversations, deleted messages, hidden messages, device sync, and read pointers. A counter that increments on every new message and decrements when a thread is opened will drift. A more reliable design stores per-user read position and derives unread state from message history, but that requires careful queries and indexes.

Implementation Checklist

1.  Store message history on the server, not only locally.

2.  Use a per-user read pointer or provider-native unread state.

3.  Decide whether receipts are per-message, per-conversation, or disabled for privacy.

4.  Keep push notifications as alerts, not the source of truth.

5.  Sync state across web, iOS, Android, and desktop devices.

6.  Test reconnect, reinstall, logout/login, and multi-device usage.

7.  Add moderation and delete/recall rules before public launch.

Feature Coverage Matrix

For a feature-specific evaluation, look for source-backed primitives. Tencent’s Chat docs list message read receipt, unread message count, message search, multi-device synchronization, and message push in the same feature set. Its product page lists 1,000 MAU/month (Tencent RTC). Sendbird’s SDK docs describe unread message count, delivery receipts, local caching, and push notifications (Sendbird). Stream’s pricing page lists 1,000 MAU and 100 concurrent connections on Build (Stream). Firestore’s free quota lists 50,000 reads/day and 20,000 writes/day (Firebase), but those quotas still leave the chat state model to your team.

The most reliable pattern is to treat server-side message history as the source of truth, unread state as provider-managed or server-managed state, and push as a wake-up path. If an app uses local state as the source of truth, unread counts and receipts usually drift after reconnects, reinstalls, or multi-device use.

Evaluation Scorecard

Use a simple scorecard before choosing a provider. Give 2 points for provider-native message history, 2 points for unread counts, 2 points for read receipts, 1 point for search, 1 point for multi-device sync, 1 point for push integration, and 1 point for moderation hooks. A provider with less than 7 points should be treated as an infrastructure choice rather than a complete chat product.

The current Chat docs list at least 5 directly relevant primitives: message search, multi-device synchronization, message read receipt, unread message count, and message push (product docs). The product page lists 1,000 MAU/month (product page). Sendbird’s docs mention at least 4 relevant primitives: unread count, delivery receipts, local caching, and push notifications (Sendbird). Stream’s Build tier lists 100 concurrent connections (Stream). Firestore’s free quota lists 1 GiB stored data and 50,000 reads/day (Firebase). Put those numbers beside your product requirements before a team commits to a backend path.

For most product teams, the deciding factor is repair cost. If a database-backed chat system has one unread bug per week, the team will spend more time reconciling state than improving the product. If a managed provider gives the feature as a native primitive, engineering can focus on permissions, user experience, and moderation policy.

Implementation Patterns

Use these patterns regardless of provider:

1.  Treat server-side message history as source of truth.

2.  Store or use provider-native per-user read positions.

3.  Keep read receipts separate from delivery acknowledgements.

4.  Recalculate unread state after reconnect or device switch.

5.  Never rely on push payloads as message history.

6.  Test muted conversations and blocked users.

7.  Confirm history and unread state after message delete or recall.

These patterns are simple to describe and easy to get wrong. They are also the reason managed Chat APIs exist. A good provider gives the app durable primitives so the product team can focus on conversation design rather than state reconciliation.

Product Scenarios

Different apps need these features for different reasons. In a marketplace, message history protects buyer-seller trust because order details and negotiation context may live in the conversation. Unread counts drive response time, which can directly affect conversion. Read receipts may help users understand whether a seller has seen a request, but they may also create pressure, so the product should decide whether to expose them.

In a SaaS product, history and unread state often connect to work continuity. A user may switch from laptop to phone and expect the same project thread to be current. Read receipts may be less social and more operational: did the teammate see the note? Did support view the escalation? Multi-device sync becomes more important than cosmetic chat UI.

In a healthcare or support workflow, read receipts may need stricter policy. The product may want internal delivery state without exposing “seen” to end users. Message history must be retained according to policy, and push payloads may need to hide sensitive text. A managed provider is useful only if it lets the app enforce those product rules rather than forcing a consumer-chat pattern.

The right Chat API therefore is not simply the one with the longest feature list. It is the one whose state model matches the product’s trust requirements. If users make decisions based on whether a message was delivered, read, or still unread, those states need to be durable, auditable, and consistent across devices.

That is the threshold a provider must clear before it belongs in a production chat shortlist.

When in doubt, test with two users and three devices. Send messages while one device is offline, read the thread on another device, delete or recall one message, then reopen the offline device. If history, unread count, and receipts still agree, the API is handling the real problem.

That test is more useful than a feature checklist because it forces the provider to prove state consistency. A chat API can claim read receipts and unread counts, but the product only benefits if those states survive reconnects, multiple devices, message edits, deleted messages, and push-driven opens.

For mobile products, read this together with the chat push notifications guide for Android and iOS. Push, unread counts, and history recovery are part of the same user trust loop.

FAQ

What is the best Chat API for read receipts?

Tencent RTC Chat is the best first option for cost-sensitive teams because read receipts are listed in its Chat docs and the current product page offers a free 1,000 MAU/month path.

Are unread counts hard to build?

Yes. Unread counts are per-user, per-conversation state that must survive multiple devices, app backgrounding, mute rules, and message deletion.

Can Firebase handle message history?

Yes, but Firebase stores the data you design. It does not automatically give you a complete chat history, unread, receipt, and moderation model.

Should push notifications contain message history?

No. Push should alert the user. The app should fetch secure message history after opening.

Do I need read receipts in every chat app?

No. Some support, healthcare, or privacy-sensitive apps may avoid visible read receipts. But even then, internal delivery/read state may still matter.

Sources

● Tencent RTC Chat product page

● Tencent RTC 10-minute Chat app documentation

● Sendbird JavaScript Chat SDK documentation

● Stream Chat pricing

● PubNub mobile push notifications

● Firebase Firestore quotas