Outbound — Agente responde desde el CRM

Caso: el agente Juan, logueado en el CRM, abre el tab WhatsApp del contacto y escribe "Ya estamos revisando, dame 5 min".

Secuencia

Agent provisioning on-the-fly

La primera vez que Juan envía algo, el integration-api hace:

1. SELECT * FROM support_agent_mappings WHERE crm_user_id = 'juan_id' → vacío.
2. GET /api/v1/users/juan_id al CRM → {email: "juan@semtec.hn", name: "Juan Pérez"}.
3. POST /platform/api/v1/users en Chatwoot con CHATWOOT_PLATFORM_APP_TOKEN → crea user + devuelve access_token.
4. POST /api/v1/accounts/2/agents → lo asocia al account como rol agent.
5. INSERT INTO support_agent_mappings → cache del mapping.

Las siguientes 1000 respuestas de Juan reusan el token cacheado.

Fix del toast espúreo

Antes: el SSE publicaba type=whatsapp_message para TODO (inbound y outbound), y el frontend filtraba por direction. El filtro ocultaba el toast pero el badge del bell igual subía.

Ahora:

• publishRealtimeEvent del outbound emite type=whatsapp_echo.
• publishRealtimeEvent del inbound emite type=whatsapp_message.
• useNotifications.js ignora whatsapp_echo antes del unshift → bell no sube, toast no aparece.
• ContactWhatsApp.vue acepta ambos types para sincronizar el timeline del contacto abierto.

Propagación de identidad

El OutboundJob lleva:

{
  "sender_type": "crm_agent",
  "sender_user_id": "665a…",
  "sender_name": "Juan Pérez"
}

El gateway persiste esos campos en whatsapp_messages. El mirror a Chatwoot los usa para elegir el token correcto. La UI los usa para renderizar el header de la burbuja outbound.

Siguiente: Outbound desde Chatwoot — el camino inverso.