Em poucas palavras
- O campo
fromaceita valores diferentes conforme o canal: telefone, endereço, @usuário ou nome de recurso. - Quando houver um ID e um alias, o backend resolve o alias dentro do workspace da chave e respeita as restrições da API Key.
- Prefira o ID do recurso em integrações persistentes; use alias quando for mais prático para configurar ou ler o payload.
O que cada canal aceita
Cada endpoint documenta seu próprio campo. Por exemplo, a presença do WhatsApp aceita
from e mantém instanceId como alias legado; a API de envio de e-mail espera um endereço em from.
Exemplo: Instagram pelo @usuário
Use o username da conta do Instagram conectada para selecionar a instância remetente:to continua sendo o identificador do destinatário exigido pela API oficial (IGSID). O @ só seleciona a conta de origem.
Quando o alias não identificar uma única conta
Se nomes repetidos apontarem para mais de um recurso, a API responde409 AMBIGUOUS_SENDER e pede o ID do recurso. Um alias de outro workspace nunca seleciona recursos de lá: a busca fica limitada ao workspace da API Key. As restrições instanceIds, pushAppIds e equivalentes continuam valendo depois da resolução.
O campo legado instanceId continua aceito em rotas que declaram esse alias. Nas rotas com from, esse é o campo preferido. Consulte a referência do canal para saber se um alias específico é aceito naquela operação.