> ## Documentation Index > Fetch the complete documentation index at: https://internal.softcrum.com/llms.txt > Use this file to discover all available pages before exploring further. # messaging > messaging es cómo cualquier cosa de la suite alcanza a una persona. Decide si un mensaje puede enviarse, por qué canal, lo renderiza, lo encola en el carril correcto, lo entrega por un proveedor y registra qué pasó con él. > Traducción. Autoritativo: [`../../../modules/messaging/prd.md`](/modules/messaging/prd). > `messaging` es cómo cualquier cosa de la suite alcanza a una persona. Decide si un mensaje puede > enviarse, por qué canal, lo renderiza, lo encola en el carril correcto, lo entrega por un proveedor > y registra qué pasó con él — todo rastreable hasta el evento que lo causó. ## Para quién es | Persona | Contrata este módulo para | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | **Responsable de marketing** (tenant) | Enviar una campaña de cumpleaños, un recordatorio de puntos por vencer o un blast a un segmento — y saber cuántos llegaron. | | **Desarrollador** (tenant) | Que los mensajes transaccionales simplemente funcionen: un OTP llega en segundos, un comprobante nunca lo bloquea un opt-out de marketing. | | **Member** | Recibir lo que pidió y nada que no pidió, y cambiar de opinión en un clic. | | **Nosotros** | Entregar las notificaciones de todos los demás módulos sin que cada uno invente su propio camino. | ## El problema hoy Dos problemas, y uno es nuestro. **El del tenant** es que las herramientas de engagement tratan consentimiento, supresión y quiet hours como configuraciones de campaña en vez de compuertas. Un mensaje sale a alguien que se dio de baja la semana pasada porque la lista se exportó antes, y eso es un reclamo ante un regulador, no un bug. **El nuestro** es un número duro de la investigación: **el rate limit de Resend es por team, a través de todas las API keys** — todos los tenants comparten un presupuesto. Un blast de marketing puede dejar sin OTPs ni comprobantes a todos los demás. Ese hallazgo es por qué existe ADR-015 y por qué los carriles duales están en F1a y no como preocupación de escalamiento. Una plataforma donde la campaña de un cliente rompe el login de otro no es multi-tenant, diga lo que diga la base de datos. ## Qué hace *(normativo)* * Resuelve **si y dónde** enviar, con una función pura en cascada sobre cuatro niveles de configuración más las compuertas del propio destinatario (ADR-019). * Renderiza **plantillas** con variables validadas contra las definiciones de atributos reales. * Encola en **dos carriles por canal** — el transaccional siempre gana al de marketing (ADR-015). * Entrega por **adaptadores de canal** tras un puerto, de modo que un canal nuevo es un adaptador y no una cirugía. * Registra cada envío desde `queued` hasta `opened`, **unido por `correlation_id` al evento de dominio que lo causó**. * Mantiene **supresiones** automáticas desde rebotes duros y quejas, verificadas en cada envío. * Da al member un **centro de preferencias** por canal y por categoría. * Corre **campañas**: blasts a un segmento, y automatizaciones permanentes por evento, propiedad de fecha o entrada a segmento. ## Lo que NO hace *(normativo)* * **No es un diseñador de plantillas.** Las plantillas son componentes React Email en el repositorio, versionados como código. Un editor visual es superficie de producto que quizá queramos después; no es lo que hace que los mensajes salgan. * **No es una consultoría de deliverability.** Automatizamos SPF/DKIM y el warm-up, y exponemos tasas de rebote y queja. La reputación es en última instancia el comportamiento de envío del tenant. * **No es una bandeja de entrada.** Las respuestas van a la dirección del propio tenant. * **Sin contenido de mensajes en analítica.** Contamos envíos, aperturas y clics. Lo que se escribió queda con el registro del envío y se borra con el titular al suprimirse. * **Ni WhatsApp ni Live Activities en F1.** Ambos son F2 y necesitan vendor y ADR (DEC-E1). ## Éxito | Medida | Objetivo | Para | | ---------------------------------------------------------------------------------- | ----------------------------------------------- | --------------------- | | Un blast a máximo throughput mientras los OTP de otro tenant mantienen su latencia | probado por el perfil k6 `blast-vs-otp` | certificación, pre-G1 | | Latencia de entrega transaccional | segundos, p95 bajo carga con marketing saturado | certificación, pre-G1 | | Envíos que alcanzan a un destinatario suprimido o sin consentimiento | **cero**, por construcción | siempre | | Correlación desde un evento de dominio hasta un mensaje entregado | rastreable end to end en una consulta | G1-Engage | | Dominio de envío del tenant verificado y templado | bajo una hora de esfuerzo del tenant | G1-Engage | ## Modelo comercial Los mensajes son una **métrica medida** con precios unitarios publicados por canal (ADR-016) — email y push nos cuestan distinto y se cobran por separado. El enforcement es duro al 110% (DEC-G2), porque un envío sin límite es una cuenta sin límite para nosotros. Una capacidad es add-on: un **dominio de envío propio** (DEC-F4). El default es un subdominio compartido, que funciona; un tenant que quiere correo desde su propio dominio paga la configuración y el aislamiento de reputación que trae. ## Fases | Fase | Contenido | Objetivo | | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- | | **F1a** | Cascada y configuración de canales · plantillas · envíos y estados · supresiones y preferencias · despacho de carril dual · adaptadores email, in-app, webhook y push | G1-Engage, 2026-11-01 | | **F1b** | Campañas y disparadores · dominios de envío y warm-up · adaptador SMS (tras su ADR de proveedor) | post-G1 | | **F2** | WhatsApp · Live Activities · fallback entre canales (DEC-E4) · un diseñador de plantillas si se pide | 2027 | ## Cumplimiento y riesgo Este módulo es donde una falla de consentimiento se vuelve un evento regulatorio, así que el consentimiento no se consulta: es una compuerta que no se puede saltar. * **Transaccional nunca es opt-out** (DEC-E3), y marketing nunca sale sin otorgamiento activo. No hay configuración de tenant que cambie ninguna de las dos. * **Las supresiones sobreviven a la supresión de datos** como identificador hasheado sin perfil. Borrarlas permitiría volver a escribirle a una persona borrada. * **El contenido del mensaje es dato personal.** Se borra con el titular; solo quedan conteos. El riesgo operativo principal es la reputación del proveedor: la mala lista de un tenant daña el dominio compartido de todos. Mitigado con límites de warm-up, supresión automática, umbrales de rebote y queja que pausan a un remitente, y dominios propios para quienes envían volumen. ## Dependencias `core` para contactos, consentimiento y segmentos — dura y de una sola dirección. Resend, FCM, Upstash. `QueuePort` y `NotificationChannelPort` (enmienda A1). Todos los demás módulos dependen de este, y lo alcanzan solo por eventos de dominio. ## Preguntas abiertas | # | Pregunta | Decide | Para | | - | ---------------------------------------------------------------------------------------------------------- | ------ | ---------------------------- | | 1 | Umbrales de rebote y queja que pausan automáticamente el envío de un tenant — ¿qué números? | Daniel | antes de aprobar FS-MSG-0008 | | 2 | ¿El tracking de aperturas y clics viene activo por defecto, dado que exige píxel y reescritura de enlaces? | Daniel | antes de aprobar FS-MSG-0003 | ## Changelog | Versión | Fecha | Cambio | Por qué | Autor | | ------- | ---------- | ---------------- | ------- | ---------------------- | | 0.1.0 | 2026-08-17 | Borrador inicial | — | daniel + claude-opus-5 |