Feature Request

The official WhatsApp API currently doesn't support Group Chats. Other platforms supporting WhatsApp Groups use unofficial APIs that often break. We will consider building this feature once it is released officially for WhatsApp API. 🔴 Important Note : As of February 2026, Meta has released native Group Chat support through WhatsApp cloud API. However, there's significant restrictions at this time: It is not available for Coexistence users yet Because of this, once Meta expands eligibility and releases full documentation for all account types, we can consider to move forward. This is NOT a limitation on respond.io . This is a limitation set by Meta's team to all WhatsApp API accounts.

Business Problem: The Unreplied filter in Inbox currently only surfaces conversations where the most recent item is an incoming message from the Contact. Missed inbound calls — where a contact tried to reach the business but nobody picked up — are not treated as "unreplied" interactions. This means missed calls don't appear in the Unreplied view, and agents have no standard way to see which contacts attempted to call and were never followed up with. A missed call is arguably the strongest intent signal a contact can send — they wanted a real-time conversation. Yet it's the one inbound interaction that gets zero visibility in the agent's priority queue. Desired Outcome: Treat missed inbound calls the same way incoming messages are treated for the purpose of the Unreplied filter. If a contact calls and the call is missed (unanswered, timed out, or dropped), the conversation should surface in the Unreplied view until an agent responds — whether by calling back, sending a message, or closing the conversation.

With the launch of BSUID, if businesses wants the Phone Number of contacts, they need to ask consent by sending a Meta Approved Template as a request to contact. If contact agrees to share, it will appear on Respond.io as a Contact Card. But it will not auto-update the Contact Field. It needs to be done manually by copying the number and pasting it. Current Workaround: Use "New Incoming Message" webhook, where payload will show contact number under "wa_id" field once contact has consented Problems: Some Agents will miss manually copying and thus the Phone Number is not updated This can easily create discrepancies between the CRM and Respond.io if the CRM gets updated via the incoming webhook without a Workflow being set up properly or the agent doesn't update the contact fields. Desired outcome: To auto-save/update the contact phone number field in respond.io when contacts shared their phone numbers through the request phone number CTA template message

Business Problem: The only way to add a Collaborator via Workflows today is through the @mention in Add Comment workaround, which creates unnecessary comment noise and doesn't support conditional logic. There's also no way to branch a Workflow based on Collaborator state. On the API side, there are no endpoints to manage Collaborators programmatically, and no webhook events for Collaborator changes — so businesses that sync respond.io with their CRM or custom tooling can't keep Collaborator data in sync. Desired Outcome: Workflows: A dedicated "Add Collaborator" step (without needing to post a comment), Branch conditions for Collaborator state (e.g., "Has Collaborators", "Collaborator is Agent A", "Collaborator count > 0"), and dynamic variables like $conversation.collaborators and $conversation.collaboratorCount. API: Endpoints to list (GET), add (POST), and remove (DELETE) Collaborators on a conversation. Include Collaborator data in the existing Get Conversation response. New webhook events (collaborator.added, collaborator.removed) that fire regardless of whether the change was made via UI, Workflow, or API.

Business Problem: As Meta rolls out WhatsApp usernames, a growing share of inbound contacts arrive without a phone number. Their only identifiers are a display name (not unique), a BSUID (stable but buried in Channel Metadata JSON), and a username (human-readable but not surfaced in the UI). Agents cannot reliably identify who they're talking to, distinguish contacts with the same display name, or hand conversations over with a trustworthy reference. Integrations that rely on phone number as the API path identifier (e.g., POST /v2/contact/phone:<number>/comment) break entirely for these contacts. Desired Outcome: Inbox visibility — Show the WhatsApp username on the contact record and conversation header, the same way the phone number appears today. API identifiers — Support username and BSUID as lookup identifiers in the Developer API alongside phone and contact ID (e.g., /v2/contact/bsuid:<id> or /v2/contact/username:<handle>), so integrations work without a phone number. Workflows & exports — Make username and BSUID available as variables in Workflows and in data exports, so these contacts can be routed, tagged, and reported on like any other. Current Limitation: BSUID is stored internally and accessible via Channel Metadata (View JSON), but not surfaced in the contact record, API paths, Workflows, or exports. Username is not displayed anywhere in the platform. Current workaround: Businesses can capture phone numbers shared by username-only contacts via an integration (Zapier/Make/n8n) and save them to the contact record automatically: Subscribe to respond.io 's New Incoming Message webhook → check when a username-only contact's payload includes a phone number (wa_id), indicating they've just shared their number → trigger a respond.io Workflow via Incoming Webhook to update the contact field. The integration tool sends an HTTP request to a respond.io Workflow's Incoming Webhook URL → respond.io stores the payload in a variable → "Update Contact Field" step saves the phone number.

To be able to download from each conversation window with a user the conversations exchanged with a specific user quickly, if possible in a pdf or spreadsheet, but from a single user. Today, when exporting data comes from everyone, without being able to filter the information we want in an organized way that is easy to understand and see

Business Problem: The current cap of 150 Workflows per Workspace is a hard constraint that larger teams and complex operations are hitting. As businesses scale — adding more channels, products, regions, and use cases — the number of Workflows needed grows quickly. Desired Outcome: Increase the maximum number of Workflows per Workspace

Business Problem: Digital marketing teams running Google Ads face challenges connecting ad performance directly to messaging outcomes. While Google Ads supports Click-to-WhatsApp CTAs, attribution is unreliable because WhatsApp does not allow referrer tracking. Without proper attribution, businesses cannot measure ROI accurately, optimize campaigns, or connect Google Ads conversions to lifecycle reporting. Desired Outcome: Provide clear source and campaign attribution for leads entering via Google Ads Click-to-WhatsApp campaigns. Surface Google Ads campaign performance in lifecycle reporting alongside other marketing channels. Use Cases: A retail business runs Google Ads campaigns with Click-to-WhatsApp buttons. Each incoming lead is automatically tagged with campaign source for accurate ROI measurement. A company wants to optimize ad spend by sending conversion goals (e.g., qualified leads, closed deals) back to Google Ads for smarter bidding. Marketing teams can view Google Ads contribution directly in lifecycle reports

Problem Currently, the Respond.io message composer doesn't allow you to properly paste mixed content (text + images) from the clipboard. We have carried out different tests and the behavior is as follows: Text only → is pasted correctly. Only one image → is pasted correctly. Text + 1 image → the text is pasted, but the image appears duplicated. Text + 2 images → the text is pasted, the first image appears duplicated and the second one is not inserted. Desired result That the composer of Respond.io allows you to paste text and images together from the clipboard in a single action, keeping each image only once and respecting the order of the content, in the same way that other rich text editors allow.

Business Problem: The current role-based permissions structure (Agent, Manager, Admin) does not provide enough flexibility for organizations with complex operational workflows. Many businesses — especially those with multiple internal departments — require fine-grained control over what each user can view, edit, or do inside the platform. This leads to risks such as accidental customer replies, unauthorized data edits, or exposing sensitive information to users who should not have access. Desired Outcome Introduce a granular permission system that allows workspace admins to customize access levels per user or per role. This should include the ability to enable or disable specific actions, modules, or permissions, such as: Access to Dashboard, Contacts, Messages, Snippets, Users & Teams (but not Workflows or advanced settings) Read-only access to conversations Restricting ability to reply to contacts Restricting ability to send files, surveys, or voice notes Allowing comments only for inter-team collaboration Use Cases Multi-Team Operational Workflows Some customers (e.g., online stores) have an operations team that reviews cases internally. The desired flow: Customer care assigns a contact to the operations team Operations team reviews history Leaves internal comments Contact is returned to the agent However: The operations team should not reply directly to the customer Replies must be text-only for some agents Operations team should have limited permissions (no surveys, no attachments, no voice notes) Restricting Access to Sensitive Contact Fields Currently, contact fields marked as hidden are only collapsed behind a dropdown — but are still accessible and editable. Organizations need stronger control over field visibility to protect internal or confidential data. View-only fields: Users (at least agents) should be able to see certain fields but not edit them. Fully hidden fields: Some fields should be completely invisible to certain roles (not displayed anywhere in the interface). This is important for companies storing sensitive customer data (financial info, internal IDs, CRM-synced fields, etc.), where only a subset of users should have access or edit rights.