Need native support for visibility-scoped system messages in groups—specifically the ability to send system messages that are only visible to specific users (like Slack's "only visible to you" app integration notes). This would prevent unwanted group notifications and unread count increments for messages that should be private to certain users, improving the overall user experience.

Add full RTL (Right-to-Left) layout support to the CometChat React Native UI Kit v5. When React Native’s I18nManager.forceRTL(true) is enabled, the UI Kit components should automatically adapt their layouts and directional elements for RTL languages such as Arabic and Hebrew. The UI Kit should ensure that: Component layouts correctly mirror in RTL mode. Icons, arrows, alignment, margins, and paddings are appropriately adjusted. Message bubbles and conversation lists follow the expected RTL direction. Navigation and interactive elements maintain correct positioning and behavior. RTL support is documented with the required configuration and any limitations.

Hi, I’m looking for a feature that can instantly display media, links, and documents from a conversation. From what I found, Conversation and Advanced Search seems like the best way to implement this. However, I’ve run into the following error: { "error": { "message": "Conversation and Advanced Search is not available on your current billing plan.", "devMessage": "Your current plan (free-2023-01) does not support the Conversation and Advanced Search feature, including filters such as hasAttachments, hasMentions, hasReactions, hasLinks, and mentionedUids. Please upgrade to a compatible plan to enable this functionality.", "source": "chat-api", "code": "ERR_MESSAGE_SEARCH_RESTRICTION" } } I understand that this feature is only available on certain paid plans. My question is: how can we properly test this in our development/staging environments before making it available to production users? On a related note, I also keep hitting the 100-user limit in our development environment. Most of these users are created purely for testing, so they don’t represent actual production usage. Would it be possible to adjust or increase the user quota for our dev/stage environments so that we can properly test the integration? Or am I approaching this incorrectly? Is there an alternative setup that allows paying customers to test paid features in their development and staging environments without being blocked by production-level feature restrictions or user limits?

Currently, campaigns can only be targeted to one role at a time — the role filter in the dashboard allows a single selection, and the API accepts UIDs rather than roles. Customers with role-based user segments (e.g. Admin, Employee, Customer, Supplier) need to create and send a separate campaign for each role, which is repetitive and hard to manage at scale. Adding multi-role selection so a single campaign can target a combination of roles (e.g. Admin + Customer) would let customers reach the right audience in one send.

Currently, campaigns can only be targeted to one role at a time — the role filter in the dashboard allows a single selection, and the API accepts UIDs rather than roles. Customers with role-based user segments (e.g. Admin, Employee, Customer, Supplier) need to create and send a separate campaign for each role, which is repetitive and hard to manage at scale. Adding multi-role selection so a single campaign can target a combination of roles (e.g. Admin + Customer) would let customers reach the right audience in one send.

Summary Add playback speed controls (0.5x / 1x / 1.5x / 2x) to voice and audio message bubbles, requested by a customer. Current Behaviour Playback speed control is not currently available on React Native or React. Proposed Add a speed toggle cycling 1x → 1.5x → 2x → 0.5x, supporting both voice notes and shared audio files.

Introduce a configurable group moderation mode that allows administrators to restrict a user’s participation without completely removing their access to the group conversation. Currently, banning or kicking a user immediately revokes access to the group and its message history. The requested enhancement is to support a read-only state where restricted users can continue viewing the group’s existing messages but cannot send new messages or receive messages sent after the restriction is applied. This would enable applications to implement user-blocking workflows that comply with App Store and Google Play policies while preserving conversation history. Additionally, for scenarios such as two-member groups, the solution should support preventing the remaining participant from sending new messages as well, effectively freezing the conversation while maintaining historical access. This feature would provide greater flexibility for moderation and safety use cases without requiring custom implementations.

Introduce dedicated webhook/event support for OpenAI moderation timeouts and failures, independent of the configured fallback behavior (Approve or Deny). Currently, when the moderation fallback is set to Approve, messages are delivered even if the OpenAI moderation request times out or fails, and no webhook or notification is generated. This prevents developers from detecting moderation outages, monitoring service health, or triggering operational alerts. The requested enhancement is to expose OpenAI moderation failures through a dedicated webhook or include failure metadata in existing webhooks regardless of the fallback action. This would enable applications to monitor moderation reliability, integrate with alerting systems, and respond appropriately to prolonged OpenAI service disruptions without negatively impacting the end-user experience.

Currently, the React v7 UI Kit's built-in emoji keyboard supports browsing emojis by standard categories but does not provide a way for users to quickly access their most frequently used or preferred emojis. It would be beneficial to introduce a Favorites or Recents tab that allows users to: 1. View recently used emojis. 2. Mark emojis as favorites for quick access. 3. Persist favorite emojis across sessions.

Enable AI conversations to accept and process media messages, including images, PDFs, documents, audio, videos, and other supported file types. This will allow users to share media directly with the AI agent, enabling it to analyze the content, extract relevant information, and generate context-aware responses based on both text and media inputs. This enhancement will make AI interactions more versatile and better support use cases where users need to discuss or obtain insights from files rather than text alone

Introduce support for custom dashboard roles with granular, per-section permission controls. Currently, the dashboard provides only four predefined roles (Owner, Admin, Moderator, and Developer), with fixed permission sets that cannot be customized. This prevents administrators from restricting access to specific dashboard sections, such as allowing access to Integrations while restricting Credentials, or limiting Chat & Call Logs to Admins only. Providing configurable role-based access control (RBAC) with fine-grained permissions for individual dashboard modules (e.g., Logs, Credentials, Webhooks, Features, Integrations, Billing, Settings, etc.) would enable organizations to implement the principle of least privilege, improve security, and better align dashboard access with internal team responsibilities and compliance requirements.

Add support for screen sharing during audio and video calls on Android and iOS. This would allow users to share their device screen with other participants.

We are building an interview platform on the Calls SDK v5. We already have in-call Virtual Background working via the session statics (setVirtualBackgroundBlurLevel, setVirtualBackgroundImage, clearVirtualBackground, showVirtualBackgroundDialog) with hideVirtualBackgroundButton: false. That works well inside an active session. We now need VB (blur + preset image) available on our custom pre-join / waiting-room screen, before joinSession is called, with a live preview in the camera tile. Your own hosted demo at calls.cometchat.io also has no VB on its pre-join lobby (screenshot attached), so we want to confirm whether this is possible at all. Questions: Pre-join VB preview — Is there any supported public API to apply/preview Virtual Background on a local MediaStreamTrack obtained from our own getUserMedia, before an active session exists? The VB engine appears to be bound to the local track only inside an active joinSession. We see previewTrack / previewVirtualBackground slices in the store but found no public setter. Is a green-room / pre-join VB API planned or available? Carry selection into the call — If pre-join VB is not supported, is there a supported way to pass a pre-selected background (blur level or image) into joinSession so it applies immediately on join without the user re-opening the in-call dialog? Note CallSettingsBuilder.setVirtualBackground() is marked @deprecated / has no effect. Dialog-highlight sync — Calling setVirtualBackgroundBlurLevel(n) applies the live blur but does not update the backgrounds[].selected / selectedBackgroundId state that drives the dialog highlight. Result: blur is active but the dialog shows "None", and pressing Done then clears the blur. The sync action (selectBackground(id)) is not exported. Is there a public API to programmatically select a background so the dialog highlight stays in sync?

The total number of users created in a CometChat application should be visible in the CometChat Dashaboard

Currently, there is no webhook or event that notifies integrators when a new conversation is created between users.

Currently, user metadata updates made externally are not automatically synchronized to active SDK sessions. Developers must manually call CometChat.getUser(UID) to fetch the latest metadata, and there is no real-time event or webhook available to notify applications when user metadata changes. We request the following enhancements: Introduce a real-time SDK event/listener that triggers when a user’s metadata or profile information is updated. Provide webhook support for user update events, including metadata changes. Offer an automatic metadata synchronization mechanism for active user sessions, reducing the need for manual polling via getUser(). Ensure updated metadata is reflected across all logged-in devices and sessions in near real time. This enhancement would improve developer experience, reduce network polling, and enable applications to react immediately to user metadata changes without requiring logout/login or periodic refreshes.

Problem Currently, when a message is blocked through Moderation, the backend correctly updates the message state by: Marking the message as blocked for the sender. Converting the message to sender-only, preventing receivers from accessing it. However, this change is only persisted at the data layer. No real-time event is emitted to connected clients, so: Receivers continue to see the original message until they refresh or reconnect. Senders do not immediately see the message updated to its blocked state. The correct state is reflected only after the conversation is re-fetched. Proposed Enhancement Enhance the Moderation flow to emit a real-time message update event whenever a message is blocked. This event should notify all connected clients so they can immediately update the UI. Expected Behavior Sender: The message should instantly update to the "blocked" state. Receivers: The message should be removed or updated immediately based on the sender-only visibility rules. No manual refresh or reconnection should be required for the changes to be reflected.

Description: Add a new notification preference for group conversations: “Notify only for replies to your messages.” When enabled, users will receive notifications only when another group member directly replies to one of their messages. Notifications for all other group messages and activities will be suppressed, allowing users to stay informed about conversations relevant to them while reducing notification noise in active groups. Scope: Applicable only to group conversations. Trigger notifications only for direct replies to the user’s messages. No notifications for other group messages, mentions, or activities unless covered by separate notification settings. User-configurable through the group notification preferences.

We need an option to fetch the group members list in a specific order, such as: By member scope (e.g., Owner, Admin, Moderator, Participant) In alphabetical order by member name

Introduce a configurable setting to increase the current group member limit of 30 users for SMS notifications. At present, SMS notifications are restricted to groups with up to 30 members, and there is no mechanism for developers or administrators to adjust this threshold based on their application’s requirements. This limitation impacts larger communities and enterprise use cases where SMS notifications are critical for user engagement and message delivery. Providing a configurable limit—either at the app, group, or account level—would offer greater flexibility, enable support for larger groups, and allow customers to balance notification reach, cost, and performance according to their specific needs.