Skip to main content
El envío de Chat usa el mismo contrato que los otros canales: from, to, type y payload. La diferencia: to es el id de la conversación, no un teléfono.

Endpoint

Alcance: 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

Respuesta (200)

Imagen

payload.message (o payload.caption) es la leyenda. Sin payload.mediaUrl400.

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.
Una conversación → data es el objeto del mensaje. Varias → data es un array.

WebSocket (app del usuario)

El socket no usa el body PIV1. Después del auth:
Media en el socket: 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