Probar una plantilla antes de que la reciba alguien
Montar una plantilla es un acto de fe: guardas un templateId de Resend y te enteras de si el texto
encaja cuando un cliente recibe el correo. El panel de superadmin lo evita: eliges una plantilla del
tenant, escribes una dirección y la manda.
Un envío de prueba es un envío. Misma cola, mismo
NotificationLog, con esa dirección como destinatario. Lo único que cambia es el asunto, que va con[Prueba]delante.
Eso es deliberado: una ruta paralela “de mentira” probaría una tubería que no es la que usan los clientes. Si el envío funciona aquí, funciona en producción; y si falla, falla por el mismo motivo.
Los tres pasos
1 · El panel pide la lista de plantillas del tenant
El desplegable solo ofrece las que ese tenant tiene dadas de alta, no el catálogo de códigos que el productor sabe enviar. Probar un código que no existe no enseña nada: responde 404 y ya lo sabías.
2 · El productor valida antes de encolar
El endpoint de superadmin comprueba que hay plantilla con ese código, en canal EMAIL y en ese
tenant. notification-api lo comprobaría igual al resolverla, pero respondería con un error de
pasarela; validar en el productor deja un 404 que nombra el problema.
3 · Se encola como cualquier otro aviso
Con una diferencia: la clave de idempotencia es nueva en cada envío. Los avisos reales la derivan del hecho que los provoca, para que un reintento del traspaso no encole dos veces lo mismo; en una prueba quieres justo lo contrario, porque pulsar dos veces significa “mándamelo otra vez”.
Las variables
El panel las rellena con valores de ejemplo (TOKEN-DE-PRUEBA, una URL de activación) a partir de
la tabla de referencia que ya mantiene: qué claves manda el productor con cada código. Sin eso la
plantilla llega con los huecos vacíos y no se ve si el texto encaja, que es justo lo que se quería
mirar.
La tabla es la única pieza que hay que mantener a mano: si un emisor cambia las claves que manda, hay que cambiarla ahí, o la prueba mentirá por omisión.
Qué te dice cada fallo
| Respuesta | Qué pasó |
|---|---|
| 404 de plantilla | Ese tenant no tiene esa plantilla en email. Suele ser el tenant equivocado, no el código: las plantillas cuelgan del tenant de entrega, ver tenantId contra sourceTenantId |
| 400 de dirección | El correo no es válido; no llega a encolarse |
| 400 “EMAIL templates require templateId” | La fila existe pero está a medias. Ver Añadir una plantilla nueva |
| 503 | El productor no tiene configurado el servicio de notificaciones |
| 202 y nada en la bandeja | Se encoló bien: el problema está más allá. Mira el estado de la fila en el registro de envíos, ver La vida de un log de notificación |
Lo que no comprueba
- Que el destinatario real lo reciba. Un
BOUNCEDen el registro es información del proveedor sobre esa dirección; otra puede comportarse distinto. - El remitente de otro tenant. El
Fromsale del tenant desde el que pruebas, y si no tiene, del global. Una clínica con remitente propio hay que probarla desde el suyo. - Los push. La prueba es solo de email: un push necesita además un dispositivo registrado al que mandarlo, y eso ya no es “una dirección que escribes”.
Dónde está
En el panel de superadmin, Plantillas → el tenant → pestaña Email, debajo de la lista. El
productor lo expone como un endpoint de superadmin (POST /superadmin/tenants/:id/templates/test en
petid-api), así que también se puede llamar sin panel.