Skip to main content
O envio do Chat usa o mesmo contrato dos outros canais: from, to, type e payload. A diferença: to é o id da conversa, não um telefone.

Endpoint

Escopo: chat:messages:send. Cada envio consome 1 crédito (CHAT_MESSAGE). O path POST /v1/chat/conversations/{id}/messages continua válido: o id da conversa vai na URL e o corpo é o mesmo (type + payload), sem to.

Campos

Com JWT do membro, não envie senderExternalUserId: o remetente é o token. A resposta usa type em maiúsculas (TEXT, IMAGE, AUDIO, FILE).

Texto

Resposta (200)

Imagem

payload.message (ou payload.caption) é a legenda. Sem payload.mediaUrl400.

Áudio


Arquivo


Responder a uma mensagem

replyToId também pode ir em payload.replyToId.

JWT do membro

O app autenticado com o JWT não manda API Key.

Várias conversas no mesmo pedido

to aceita lista. Cada id é uma conversa do mesmo workspace.
Uma conversa → data é o objeto da mensagem. Várias → data é um array.

WebSocket (app do usuário)

O socket não usa o body PIV1. Depois do auth:
Mídia no socket: messageType (image | audio | file) e mediaUrl HTTPS, ou payload.type / payload.mediaUrl. O type do frame continua sendo message.send. REST (backend) → POST /v1/chat/messages. Tempo real no app → WebSocket. Tipo fora do teto do app ou do interruptor da sala → 403 CHAT_CAPABILITY_DISABLED. DIRECT com bloqueio entre os usuários → 403 CHAT_USER_BLOCKED. Detalhes: Capacidades e bloqueio. No WebSocket o message.send também aceita type (text | image | audio | file) e mediaUrl (HTTPS). recording.start só vale se a sala tiver audio ligado.

Próximos passos