Feature Requests

PT: Adicionar suporte/classe responsável por enviar mensagens para Canais do WhatsApp. Assim como já existe para grupos, os canais são muito utilizados por marcas para comunicar e como possuem um identificador próprio (@newsletter) não são compatíveis com a estrutura atual da API. Endpoints como: /fetchAllChannels/{instance} para retornar os canais que o número participa, além de ajustar o parâmetro "number" da classe Message, por exemplo, /message/sendText/{instance} para aceitar o envio de um JID de canal seria o ideal, permitindo o disparo de mensagens para este recurso. EN: Add support or new class for sending messages to WhatsApp Channels. Just as it already exists for Groups, Channels are widely used by brands for communication, and since they have their own identifier (@newsletter), they are not compatible with the current API structure. Endpoints such as /fetchAllChannels/{instance} to return the channels the number participates in, in addition to adjusting the "number" parameter of the Message class, for example, /message/sendText/{instance} to accept the sending of a channel JID would be ideal, allowing the message sending for this resource. Casos de Uso / Use Cases • PT: Enviar links de posts semanais do blog para o canal da marca; • PT: Enviar atualizações diárias sobre uma campanha para participantes do canal; • PT: Enviar ofertas e comunicação publicitária programada para o canal da marca; • EN: Send links of the weekly blog posts to the brand's channel; • EN: Send daily updates about a campaign to channel participants; • EN: Send offers and scheduled advertising communications to the brand's channel; GitHub Issue #1723 and #1857 https://github.com/EvolutionAPI/evolution-api/issues/1723 https://github.com/EvolutionAPI/evolution-api/issues/1857

PT: Não existe atualmente uma rotina de testes automatizados no projeto. Isso é essencial para garantir que funcionalidades existentes não quebrem à medida que o código é atualizado. A solicitação é para implementar testes unitários e de features que cubram as principais áreas da aplicação, ajudando a prevenir regressões e manter a qualidade do código. EN: Currently, there is no automated testing routine in the project. This is critical to ensure that existing features do not break as the codebase evolves. The request is to implement unit tests and feature tests covering the main areas of the application, helping to prevent regressions and maintain code quality. Casos de Uso / Use Cases • PT: Detectar regressões antes de chegar em produção; melhorar a confiabilidade do deploy contínuo. • EN: Catch regressions before reaching production; improve reliability of continuous deployment. 🔗 GitHub Issue #1627 https://github.com/EvolutionAPI/evolution-api/issues/1627

PT: Adicionar suporte a um nó que envia uma mensagem e aguarda uma resposta antes de prosseguir no fluxo. A resposta pode ser texto, botão interativo, etc. Isso permitiria fluxos de automação mais dinâmicos e conversacionais, capturando a interação do usuário antes de seguir para os próximos passos. EN: Add support for a node that sends a message and waits for a reply before continuing the flow. The reply can be text, button interactions, etc. This would enable more dynamic and conversational automation flows by capturing user interaction before proceeding to the next steps. Casos de Uso / Use Cases • PT: Criar fluxos de atendimento que aguardam confirmação do usuário; coletar input interativo antes de seguir para próxima ação. • EN: Build customer support flows that wait for user confirmation; collect interactive input before executing the next action. 🔗 GitHub Issue #1860 https://github.com/EvolutionAPI/evolution-api/issues/1860

PT: Atualmente não é possível enviar headers customizados nos eventos de webhook na versão self-hosted. Essa funcionalidade já existe no Cloud e é útil para validar a origem das requisições e adicionar informações de segurança. A solicitação é adicionar suporte para configurar headers customizados para os webhooks disparados pela Evolution API. EN: Currently, it is not possible to send custom headers with webhook events in the self-hosted version. This feature already exists in the Cloud version and is useful to validate the origin of requests and add security information. The request is to add support for setting custom headers for webhooks triggered by Evolution API. Casos de Uso / Use Cases • PT: Garantir que apenas eventos legítimos sejam aceitos; adicionar tokens de autenticação no header. • EN: Ensure only legitimate events are processed; add authentication tokens in the header. 🔗 GitHub Issue #1933 https://github.com/EvolutionAPI/evolution-api/issues/1933

PT: Adicionar uma funcionalidade que permita consumir a fila de mensagens de cada instância com um delay aleatório definido pelo usuário (ex.: entre 5 e 30 segundos). Isso faria com que as mensagens fossem disparadas de forma mais espaçada e natural, reduzindo o risco de bloqueios e tornando o comportamento mais próximo do “humano”. EN: Add a feature to allow each instance to consume its message queue with a random delay defined by the user (e.g., between 5 and 30 seconds). This would space out message sending, making it look more natural and reducing the risk of being flagged or blocked. Casos de Uso / Use Cases • PT: Evitar disparo massivo em curto intervalo; reduzir detecção por uso anormal; tornar a API mais confiável. • EN: Prevent massive bursts of messages; reduce detection of abnormal usage; increase API reliability. 🔗 GitHub Issue #1863 https://github.com/EvolutionAPI/evolution-api/issues/1863

PT: Ao integrar com o Chatwoot via POST https://{server-url}/chatwoot/set/{instance} com autoCreate: true, a plataforma hoje gera automaticamente o QRCode. A solicitação é permitir desabilitar essa geração automática (ex.: com um parâmetro disableQr: true ou opção equivalente), para cenários em que a criação da inbox/contato deve ocorrer sem iniciar o fluxo de pareamento via QR. EN: When integrating with Chatwoot using POST https://{server-url}/chatwoot/set/{instance} with autoCreate: true, the platform automatically generates a QR code. This request proposes an option to disable that automatic QR generation (e.g., a disableQr: true flag or equivalent), for scenarios where the inbox/contact should be created without triggering the pairing QR flow. Casos de Uso / Use Cases • PT: Provisionar instâncias/inboxes no Chatwoot sem expor o QR; controlar quando e como o QR será exibido; fluxos de onboarding em etapas. • EN: Provision Chatwoot inboxes without exposing the QR; control when/how the QR is shown; staged onboarding flows. 🔗 GitHub Issue #1833 https://github.com/EvolutionAPI/evolution-api/issues/1833

PT: Hoje não existe um endpoint que permita buscar contatos usando um label específico. A proposta é criar um endpoint que, dado um label, retorne todos os contatos associados a ele. Isso possibilitaria, por exemplo, disparar mensagens em massa apenas para contatos de um determinado label. EN: Currently, there is no endpoint to fetch contacts using a specific label. The proposal is to add an endpoint that, given a label, returns all contacts associated with it. This would allow, for example, sending bulk messages only to contacts within that label. Casos de Uso / Use Cases • PT: Disparar campanhas segmentadas por label; listar contatos de um grupo específico para relatórios. • EN: Send targeted campaigns by label; list contacts of a specific group for reporting. 🔗 GitHub Issue #1843 https://github.com/EvolutionAPI/evolution-api/issues/1843

PT: Hoje a credencial do OpenAI não permite trocar o Base URL. Essa funcionalidade é importante para usar provedores compatíveis com API OpenAI, como o Groq (ex.: https://api.groq.com/openai/v1 ). A proposta é adicionar um campo Base URL na criação/edição da credencial para que o usuário possa apontar para outro endpoint, mas mantendo a mesma estrutura de nós e chamadas. EN: Currently, the OpenAI credential does not allow changing the Base URL. This feature is needed to support OpenAI-compatible providers such as Groq (e.g., https://api.groq.com/openai/v1 ). The request is to add a Base URL field when creating/editing the credential so users can target a different endpoint while still using the same node and API structure. Casos de Uso / Use Cases • PT: Usar provedores compatíveis com API OpenAI sem precisar modificar código; integrar Groq para transcrição de áudio. • EN: Use OpenAI-compatible providers without code changes; integrate Groq for audio transcription. 🔗 GitHub Issue #1467 https://github.com/EvolutionAPI/evolution-api/issues/1467

PT: O UPDATE usado no whatsapp.baileys.service.ts faz table scan porque filtra dados dentro de campos JSON, sem aproveitar índices. Isso está gerando alto consumo de CPU em ambientes de produção, especialmente com tabelas grandes (5GB+) e muitas instâncias (ex.: 130+). Solução proposta: • Extrair os campos filtrados para colunas dedicadas com índice (opção preferida), ou • Criar índices de expressão no JSON e reescrever a query para usar operadores indexáveis. EN: The UPDATE query in whatsapp.baileys.service.ts performs a full table scan because it filters on JSON fields without using indexes. This causes very high CPU usage in production with large tables (5GB+) and many instances (e.g., 130+). Proposed solution: • Extract the filtered fields into indexed columns (preferred option), or • Create expression indexes on the JSON fields and rewrite the query to use index-supported operators. Casos de Uso / Use Cases • PT: Melhorar performance em ambientes com muitas instâncias; reduzir consumo de CPU e travamentos no banco. • EN: Improve performance in high-load environments; reduce CPU usage and DB contention. 🔗 GitHub Issue #1441 https://github.com/EvolutionAPI/evolution-api/issues/1441

PT: Hoje só existe a função ignoreJids para excluir grupos/contatos. A proposta é adicionar a função oposta: uma lista de JIDs permitidos (whitelist). Assim, o bot só interage com grupos/contatos explicitamente definidos. Benefícios: • Maior controle sobre onde o bot atua • Segmentação mais precisa para campanhas • Evita disparos acidentais em grupos irrelevantes EN: Currently we only have the ignoreJids function to exclude groups/contacts. This feature request proposes adding the opposite functionality: a list of allowed JIDs (whitelist). The bot would interact only with the specified groups/contacts. Benefits: • More control over where the bot operates • Better targeting for campaigns • Prevents accidental triggers in irrelevant groups Casos de Uso / Use Cases • PT: Disparar campanhas apenas para grupos de clientes selecionados; garantir que bots só funcionem em grupos de interesse. • EN: Run campaigns only for selected customer groups; ensure bots operate only where relevant. 🔗 GitHub Issue #871 https://github.com/EvolutionAPI/evolution-api/issues/871