Base de conocimiento

Plantillas

Un cuerpo escrito una vez, versionado y enviado muchas veces: desde el redactor, desde tu propio código o por un agente.

Detalles

Una plantilla pertenece a la conexión y no a la persona que la escribió, que es justamente la razón por la que se sustituyó la primera versión de esto. Aquella estaba indexada por usuario: la plantilla de un compañero era invisible para una clave de API del espacio de trabajo, de modo que una integración no podía enviar lo que sí veía la persona que la había configurado, y eliminar la cuenta del autor se llevaba consigo las plantillas del espacio de trabajo. Las filas se conservaron en lugar de descartarse.
Dos formas de crear un cuerpo. Un árbol de bloques sobre los componentes de @react-email/components (Section, Row, Column, Container, Text, Heading, Button, Link, Img, Hr, Markdown, CodeBlock, CodeInline), validado a medida que se escribe, de modo que un nodo incorrecto o un href inseguro se rechaza en la misma llamada que lo escribió en vez de llegar como un correo roto. O el marcado que hayas renderizado tú mismo: si tus plantillas ya son componentes de react-email en tu propio repositorio, renderízalas allí con @react-email/render y envía el HTML, que se sanea una sola vez cuando se publica la versión.
Veintitrés puntos de partida y uno en blanco, en una galería y no en un menú, porque son cosas que hay que mirar antes de elegir entre ellas, así que cada tarjeta muestra el propio correo. Bienvenida y verificación, recibos y facturas, envíos y renovaciones, resúmenes y anuncios, ordenados bajo cuatro encabezados, y cada uno se abre en el editor visual con todas sus piezas movibles, reestilizables y eliminables. Elijas el que elijas, llega como borrador, así que nada se puede enviar hasta que lo publiques.
La galería es la única parte de esto que existe solo en la aplicación. Quien llegue a las plantillas desde tu propio código o desde un agente envía un cuerpo (un documento de bloques o tu propio marcado) en lugar de nombrar un punto de partida, así que los veintitrés son un sitio por donde empezar y no un catálogo desde el que instalar.
Los slots con nombre y los props con nombre son los dos tipos de hueco, escritos como {{key}} en el cuerpo y en el asunto. Un slot lo rellena quien edite la plantilla y lleva un valor por defecto, de modo que un envío que no nombre nada se sigue renderizando. Un prop se suministra en el envío, y uno marcado como required rechaza el envío cuando falta: un 422, y no sale ningún correo. Ese rechazo es el motivo de declararlo: la alternativa es un mensaje que sale con un hueco en blanco donde debería ir el número de pedido, algo que nada reporta y que nadie puede deshacer.
Una versión publicada queda congelada. Editar el cuerpo de una plantilla publicada crea un borrador nuevo en lugar de reescribir lo que está en vivo, así que los envíos siguen resolviendo lo mismo que resolvían ayer hasta que alguien publique, y un envío que fija un número de versión no se ve afectado ni siquiera entonces. El cuerpo se compila al publicar, que es lo que hace que una plantilla que no se renderiza falle para quien la publica y no para un destinatario.
La vista previa renderiza exactamente lo que produciría un envío sin enviarlo, e informa de lo que sigue vacío en lugar de rechazarlo. Una plantilla en vista previa suele ser una plantilla en construcción, y quien la escribe rellenando un bloque cada vez no debería tener que satisfacer todos los props para ver lo que lleva hasta ahora.
Cada plantilla lleva su propio registro de lo que ha enviado: cuántos salieron en los últimos siete, treinta o noventa días, cuáles se abrieron y en cuáles se hizo clic, una serie día a día y un desglose según de dónde vino cada envío: el redactor, tu código, un agente o la cola. Cada tasa nombra su propio denominador en lugar de tomarlo prestado, porque son realmente distintos: las aperturas se cuentan sobre los mensajes que llevaban un píxel, los clics sobre los mensajes que llevaban un enlace reescrito, y un mensaje puede llevar uno sin el otro. Una vista previa no se registra nunca, y un envío de prueba se cuenta aparte y se deja fuera de todas las cifras, porque nunca salió.
Ese registro es honesto sobre lo que no puede ver, que es la razón para fiarse de la mitad que sí ve. Un envío se empareja con su registro de entrega por el propio envío, y solo el correo enviado desde tu propio código o desde la cola lleva uno. Un mensaje enviado desde el redactor, desde un agente o por el asistente, no. Así que una plantilla usada sobre todo desde el redactor llega con la mayoría de sus envíos sin emparejar, y el número de no emparejados se muestra como una cifra propia en vez de integrarse como si nadie los hubiera abierto.
Cuatro superficies sobre un único servicio, para que «qué significa publicar» tenga una respuesta y no tres que hoy coinciden. El botón Plantillas del redactor ofrece las publicadas y SUSTITUYE el mensaje por la que elijas en lugar de pegarla dentro: el envío nombra la plantilla, la versión se fija en el momento en que la eliges y el cuerpo se renderiza donde fue creado, de modo que una publicación entre elegir y hacer clic no puede cambiar lo que sale, y una maquetación que el redactor no habría podido contener sobrevive intacta. Lo que rellenas ahí son los valores, no el cuerpo. /templates son nueve endpoints detrás de los scopes templates:read y templates:write, envueltos método a método por el SDK. Enviar una necesita un permiso de envío además de un permiso de plantillas, así que una clave emitida a una herramienta de redacción puede crear y publicar sin poder enviarle correo a nadie. El servidor MCP incluye cinco herramientas: listar, leer, previsualizar, crear y enviar. Deliberadamente no hay ninguna herramienta para actualizar, eliminar ni publicar una ya existente. Una edición crea un borrador al que el siguiente envío no resolvería, y una eliminación no se puede deshacer. Editar un cuerpo guardado es una pantalla: /workspace/templates ofrece un lienzo de bloques con una paleta y un inspector, una vista previa en vivo al lado, y Guardar y Publicar como actos separados, que es lo que convierte una versión publicada en algo que puedes dejar en paz mientras trabajas en la siguiente.
200 plantillas por conexión, un documento de bloques con un tope de 500 bloques, ocho niveles de anidamiento, 20.000 caracteres en cualquier valor y 100 slots y 100 props; un cuerpo enviado como marcado con un tope de un millón de caracteres, y un asunto de 998. Cada uno de esos límites es una protección frente a un script descontrolado y no un límite de plan, cada uno rechaza con un mensaje que nombra la cifra por la que rechazó, y nada de las plantillas está detrás de un nivel de suscripción.