
Esta publicación está dirigida al desarrollador que desea aprovechar al máximo las capacidades de plantillas de correo electrónico de SparkPost. Se asume que estás cómodo leyendo contenido JSON y siguiendo un flujo de programación básico. A medida que se introducen términos que pueden ser nuevos para ti, como RFC 5322, el texto está vinculado a su referencia de origen.
Esta publicación está dirigida al desarrollador que quiere aprovechar al máximo las capacidades de plantillas de correo electrónico de SparkPost. Se asume que te sientes cómodo leyendo contenido JSON y siguiendo el flujo básico de programación. A medida que se introducen términos que pueden ser nuevos para ti, como RFC 5322, el texto está vinculado a su referencia fuente. Con eso fuera del camino, vamos a entrar de lleno.
Las plantillas y capacidades de transmisión de SparkPost hacen que el envío de correos electrónicos sea sencillo. Esas capacidades proporcionan una abstracción para el contenido de texto y HTML, lo que significa que la mayoría de las veces no hay necesidad de codificar directamente el formato del correo electrónico sin procesar que está definido en RFC 5322, anteriormente conocido como (RFC 822). Pero a veces puedes querer crear mensajes más complejos que tengan otras partes de Multipurpose Internet Mail Extensions (MIME) que no están directamente expuestas a través de la interfaz RESTful de SparkPost.
Redacción Simplificada de Correos Electrónicos
Primero, revisemos un escenario ideal para el envío de un correo electrónico. Utiliza el endpoint de transmisión para proporcionar el contenido de texto
y HTML. En segundo plano, SparkPost se encarga de componer un correo electrónico válido RFC 5322. SparkPost insertará variables de sustitución de substitution_data en el contenido de texto y HTML. Esta es una manera poderosa de generar contenido personalizado para cada destinatario en una plantilla común.
Aquí tienes un ejemplo de transmisión con contenido HTML y de texto con substitution_data.
Sustitución de Arreglos de Datos
Muchas personas se dan cuenta de que los endpoints de transmisión y plantilla de SparkPost pueden hacer sustituciones de contenido simple en los encabezados y cuerpos de los correos electrónicos. Pero muchos pasan por alto la capacidad de proporcionar contenido condicional o arreglos de datos que también pueden ser sustituidos. También puedes proporcionar contenido único por destinatario. En este ejemplo enviamos un arreglo de enlaces únicos a cada destinatario.
Esto se logra proporcionando un arreglo JSON de datos que se poblarán en el cuerpo del correo electrónico. Una vez que se proporciona la información, SparkPost usará la lógica en la plantilla para poblarla.
En este ejemplo, SparkPost buscará datos de sustitución llamados “files_html” y realizará un “for each” en cada elemento del arreglo. Creará una fila con el valor de “file” en el elemento “files_html”. Nota el triple rizado alrededor de “loop_var.file“. Esto es porque cada elemento del arreglo contiene HTML y necesitamos decirle al servidor que lo use tal cual y no lo escape. La parte del texto será una etiqueta de texto simple y el URL al archivo.
Aquí está el ejemplo completado y funcionando:
Consejo Profesional: En tu código es recomendable mantener el marcado de vista separado de los datos, pero el objetivo aquí era mantener el ejemplo lo más simple y fácil de seguir posible, así que creamos dos arreglos. Un arreglo es para la parte HTML y el otro es para la parte de Texto. En el uso en producción, sería común tener un conjunto de datos y escribir la lógica en el código de la plantilla.
Adjuntos en Capacidades de Transmisión
El endpoint de transmisión también proporciona una abstracción para el envío de adjuntos. A continuación, verás que los adjuntos se especifican en el arreglo content.attachments donde cada objeto en el arreglo describe un ítem individual adjunto. Así como antes, SparkPost se encargará de codificar texto, HTML, sustituciones e iterar a través del arreglo de adjuntos para codificar un mensaje de correo electrónico debidamente formado.
Las mejores prácticas dictan que el envío de adjuntos se debe evitar a menos que se requiera explícitamente como parte de tu servicio.
A continuación se muestran los campos requeridos para un adjunto:
type: El tipo MIME del adjunto
name: El nombre del archivo del adjunto
data: Datos del archivo codificados en Base64
Así es como se ve un adjunto dentro del contenido de la transmisión:
También puedes enviar “imágenes en línea” en una transmisión. Estas son muy similares a los adjuntos y se especifican en el arreglo content.inline_images, donde cada uno de los objetos inline_image son similares al objeto de adjunto mostrado arriba.
Adjuntos en Plantillas
Ahora que tenemos el contexto adecuado para enviar adjuntos con el endpoint de transmisión, echemos un vistazo a cómo hacerlo con plantillas. Al momento de escribir esto, no hay una abstracción de adjuntos como la que encuentras para transmisiones en línea. Uno podría concluir que las plantillas no se pueden crear con adjuntos. Estarías parcialmente en lo correcto, pero hay una solución alternativa, aunque ya no estarás aislado del formato RFC 5322.
Puedes lograr adjuntos en plantillas codificando el contenido RFC 5322 tú mismo, lo que incluye los adjuntos. La buena noticia es que no perderás la capacidad de seguir usando Substitution Data en tus encabezados de correo electrónico, HTML y partes de texto. Ten en cuenta que este tipo de plantilla limita las sustituciones a los encabezados y la primera parte de HTML y de texto.
Aquí hay un ejemplo de cómo se hace.
Correo Electrónico RFC822
Crea tu correo electrónico RFC 5322 con los datos de sustitución que quieres. Creé este en mi cliente de correo y me lo envié a mí mismo. Una vez que lo recibí, copié la fuente y reemplacé los campos que quiero sustituir dinámicamente.
La última parte MIME en este mensaje verás Content-Disposition: attachment; filename=myfile.txt”. Ahí es donde se define el nombre del archivo. El contenido de tu adjunto será sin duda mucho más complejo, pero este ejemplo intenta mantenerlo simple.
Plantilla Almacenada
Una vez que tengas un correo electrónico RFC 5322 válido, guárdalo usando el formulario email_rfc822 del endpoint de plantilla en lugar de usar los campos text y HTML. Aquí tienes un ejemplo de cómo se ve el content para ese mensaje:
Cuando se complete la solicitud, SparkPost responderá con un identificador único para tu nueva plantilla. Por ejemplo, xxxxxxx.
Envío de la Plantilla
La buena noticia es que crear el contenido RFC 5322 fue la parte difícil. De aquí en adelante enviar esa plantilla con SparkPost es exactamente igual a enviar cualquier otra plantilla.
Aquí está cómo enviamos esa plantilla y poblamos los datos de sustitución:
Plantillas desde la API de un Cliente de Correo
Si estás utilizando un lenguaje de programación que tiene una biblioteca para componer un correo electrónico, puedes usarlo para crear programáticamente la plantilla o incluso enviar el mensaje en línea. Aquí tienes un ejemplo de uso de JavaMail a través del endpoint de transmisión de SparkPost. Este método debería traducirse fácilmente a PHP o tu lenguaje de elección.
Conclusión
Ahora que ves cómo se puede usar SparkPost para enviar correos electrónicos de casi cualquier complejidad, puedes querer echar un vistazo a “SparkPost Supports Sending Email on Apple Watch” o echar un vistazo a la sintaxis de sustitución para ver cómo se puede usar con “if then else”, “expresiones en condicionales” o “Iteración en arreglos” directamente dentro de tu contenido de plantilla o transmisión.