Feature Request

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.

Business Problem AI Agents can give customers wrong answers or mishandle requests due to misconfigured instructions — and these problems are often not found out until they already happened. The problem: testing only works one scenario at a time, by hand, in the Test AI Agent panel. There's no way to check a new agent handles every scenario without typing each one out, and no easy way to know if an edit to an existing agent broke something that used to work. Manual testing doesn't scale, so agents launch, and get updated, without being fully tested. Desired Outcome Make it significantly easier to catch these problems before customers do — when setting up a new AI Agent or after editing an existing one. This should include: Tests generated automatically from the AI Agent's instructions Automatic evaluation that clearly shows what works and what needs fixing Suggestions on how to change the AI Agent's instructions to fix what's failing Current Workaround Users have to go through a slow, manual process to think up and type out every test scenario before launching a new AI Agent or when checking an edit to an AI Agent's instructions.

Platform limitation: Currently, a monthly invoice for WhatsApp fee usage is generated at the start of each month and is accessible via Usage History. However, for individual WABA balance top-up transactions, only a receipt is generated — not a formal invoice. Desired Outcome: It would be highly beneficial if users were able to access the invoice for every top up transaction that they make.

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 Problems: Right now, when a contact replies to an Instagram Story with a text message, the AI Agent receives a static placeholder — (Story Reply) — instead of the actual text the contact typed. This means the AI Agent has no visibility into what the contact actually said, and is forced to start the conversation from scratch or ask for context again, making the interaction feel robotic. Desired Outcome: Enable the AI Agent to receive and act on the actual text from Instagram Story Replies so it can respond meaningfully without requiring the contact to repeat themselves. To achieve this, the AI Agent should: Receive the actual text typed in a Story Reply, instead of the (Story Reply) placeholder Process the reply text to understand context and intent, just like a regular message

Business Problem: When the other party reacts to a message on Respond.io , there is no indication on the user's end. This lack of visibility can lead to misunderstandings, as users may assume the customer did not acknowledge the message. Desired Outcome: Reactions Display: Implement a feature to display reactions to messages within the Respond.io platform. Use Case: Ensuring that users can see when a customer reacts to a message, such as a thumbs-up, helps in understanding that the message has been acknowledged and avoids miscommunication. Current Workaround: There is no current workaround, leading to potential communication gaps and assumptions that the message was not acknowledged.

I want to track the database of each seller and it doesn't allow more than 100 per page, I should all go out and export them to an xlx or csv

Business problem: AI Agent currently can crawl Knowledge Sources defined for AI Agent. However, it's hard for platform users to identify which part or snippet of the Knowledge Source that the AI Agent is referencing. Without a log to tell the user what Knowledge Source it is referencing, platform users can not identify clearly which part of the Knowledge Source they should improve or change so that the AI Agent can provide more accurate answers Desired outcome: When an AI Agent replies, there should be a log to tell the platform user what part of the Knowledge Source is being crawled. This can be an activity log or an information call-out for users to refer with a "snippet" or source of the Knowledge Source

Business problem: As a user with Telnyx Hosted SMS numbers, I want to be able to connect these numbers to respond.io 's Telnyx channel so that I can use my existing business lines for SMS without having to purchase new numbers from Telnyx Currently, respond.io only retrieves purchased Telnyx numbers during channel setup - Hosted SMS numbers (numbers ported to Telnyx for SMS while voice stays with another provider) are not returned, resulting in a "No phone number found" error and blocking channel connection entirely Desired outcome: Hosted SMS numbers should be visible in the Telnyx channel connection flow alongside purchased numbers Users should be able to connect and use their hosted SMS numbers for SMS messaging on respond.io Use cases: A business that keeps voice calls with their existing provider (e.g. Ooma) but wants to use Telnyx for SMS messaging, and manage those conversations in respond.io A business with existing Telnyx hosted SMS numbers that wants to consolidate customer messaging into respond.io without migrating to a purchased Telnyx number Current workaround: Custom Channel - users can connect their hosted SMS numbers via respond.io 's Custom Channel as a workaround, though this requires more technical setup and is not as seamless as the native Telnyx channel connection flow

Business problem: AI Agents are often setup with instructions that look fine in setup but fail in production because there’s no post-setup QA: gaps, conflicts, and unsafe promises slip through, creating bad answers, compliance risk, and extra human handoffs. Teams end up debugging by visual checking instead of a repeatable checklist, for example: Frequent failure modes: conflicting rules (e.g., “auto-detect language” vs. hardcoded first message), undefined placeholders/links, and broken URLs. Operational gaps: pricing shared without delivery country, multi-currency in a single reply, vague handoff criteria, and missing refusal scripts (delivery/stock/payment). Resulting impact: lower trust/adoption, higher support load, slower time-to-live, and escalations that could have been prevented. Desired outcome: Provide a one-click “Validate instructions” action (right after Agent setup/edit) that scans the instruction set, flags issues with clear severity, and offers concrete, safe-by-default fixe — so teams can trust AI Agents confidently. Readiness checklist: must-haves for handoff rules, consent copy, stop/unsubscribe variants, product links, and technical notes on demand instructions. UX & reporting: inline validator with warnings for conflicting instructions