Endpoint
chat:messages:send. Cada envío consume 1 crédito (CHAT_MESSAGE).
El path POST /v1/chat/conversations/{id}/messages sigue válido: el id de la conversación va en la URL y el cuerpo es el mismo (type + payload), sin to.
Campos
Con JWT del miembro, no envíes
senderExternalUserId: el remitente es el token.
La respuesta usa type en mayúsculas (TEXT, IMAGE, AUDIO, FILE).
Texto
Imagen
payload.message (o payload.caption) es la leyenda. Sin payload.mediaUrl → 400.
Audio
Archivo
Responder a un mensaje
replyToId también puede ir en payload.replyToId.
JWT del miembro
La app autenticada con el JWT no envía API Key.Varias conversaciones en el mismo pedido
to acepta lista. Cada id es una conversación del mismo workspace.
data es el objeto del mensaje. Varias → data es un array.
WebSocket (app del usuario)
El socket no usa el body PIV1. Después delauth:
messageType (image | audio | file) y mediaUrl HTTPS, o payload.type / payload.mediaUrl. El type del frame sigue siendo message.send.
REST (backend) → POST /v1/chat/messages. Tiempo real en la app → WebSocket.
Tipo fuera del techo de la app o del interruptor de la sala → 403 CHAT_CAPABILITY_DISABLED. DIRECT con bloqueo entre usuarios → 403 CHAT_USER_BLOCKED. Detalles: Capacidades y bloqueo.
En el WebSocket, message.send también acepta type (text | image | audio | file) y mediaUrl (HTTPS). recording.start solo vale si la sala tiene audio activo.
Próximos pasos
- Usuario y agente: quién aparece como remitente
- Eventos de webhooks
- Alcances de la API Key

