Correos transaccionales interactivos mediante la API de envío

La mayoría de los remitentes de correo transaccional solo renderizan HTML plano. POST /api/v1/send en modo de plantilla, en cambio, renderiza uno de tus propios proyectos del estudio — con el motor de alternativas completo y los bloques interactivos incluidos — con mergeData haciendo las veces de la fila de valores dinámicos, así que un recibo o correo de confirmación que dispare tu backend puede llevar un bloque de Calificación o una venta adicional de Producto exactamente igual que lo haría un envío de marketing.

Asunto

Your order receipt

La mayoría de los remitentes de correo transaccional solo renderizan HTML plano. POST /api/v1/send en modo de plantilla, en cambio, renderiza uno de tus propios proyectos del estudio, con el motor de alternativas completo y los bloques interactivos incluidos. Un recibo o confirmación que dispare tu backend puede llevar un bloque de Calificación o una venta adicional de Producto exactamente igual que lo haría un envío de marketing.

Un recibo es uno de los correos con mayor tasa de apertura que envía una empresa — y casi siempre el más plano, porque normalmente lo genera la primera librería transaccional que fue fácil de conectar, no algo con un sistema de diseño detrás.

Diséñalo una vez, dispáralo desde tu backend

Construye el recibo o la confirmación como un proyecto normal del estudio, con los bloques que tengan sentido — una Calificación para el CSAT posterior a la compra, un Producto de venta adicional de un artículo relacionado. Tu backend entonces llama a la API de envío en modo de plantilla con el ID del proyecto y un objeto mergeData que hace las veces de los valores dinámicos de ese pedido específico.

Márcalo como transaccional, correctamente

Configurar type como "transactional" omite la supresión por cancelación de suscripción — un recibo aún debe llegar a alguien que canceló su suscripción de marketing — pero nunca la supresión por rebote, ya que una dirección realmente inválida no debería seguir recibiendo correos sin importar el tipo de envío.

Está autenticado como cualquier integración por API

Una clave de API con nombre por cuenta, autenticada con Bearer, se genera y revoca desde la sección Desarrolladores del panel. Un encabezado Idempotency-Key evita que una solicitud reintentada envíe el recibo dos veces.

Lo que no se traslada

El modo de formato libre (sin projectId, solo html/text en bruto) omite el pipeline de renderizado por completo — sin etiquetas de combinación, sin motor de alternativas, enviado exactamente como se indica. Esa es la opción correcta para algo como un código OTP puntual; el modo de plantilla es el que vale la pena usar en cuanto el propio correo se beneficia de un bloque interactivo.

Primeros pasos

Construye la plantilla transaccional como un proyecto del estudio con los bloques interactivos que quieras, genera una clave de API bajo Desarrolladores, y llama a POST /api/v1/send en modo de plantilla con tu mergeData y type: "transactional".

Una secuencia típica de creación y envío

  1. 1

    Construye la plantilla transaccional como un proyecto del estudio

    Diseña el recibo o la confirmación una sola vez en el estudio, con los bloques interactivos que tengan sentido — una Calificación, un Producto de artículo relacionado, un Botón de estado.

  2. 2

    Genera una clave de API

    Crea una clave de API con nombre bajo Desarrolladores en el panel — autentica cada llamada a la API de envío como un token Bearer.

  3. 3

    Llama a la API de envío en modo de plantilla

    Tu backend hace POST a /api/v1/send con el ID del proyecto y un objeto mergeData que hace las veces de los valores dinámicos de ese pedido o evento específico.

  4. 4

    Márcalo como transaccional

    Configura type como "transactional" para que el envío omita la supresión por cancelación de suscripción (la supresión por rebote sigue aplicando) — la semántica correcta para un recibo que el destinatario necesita sin importar sus preferencias de marketing.

Preguntas frecuentes

¿Un correo transaccional enviado mediante la API puede incluir los mismos bloques interactivos que una campaña normal?

Sí — el modo de plantilla renderiza un proyecto existente del estudio exactamente igual que lo haría renderEmail() para cualquier otro envío, así que cada bloque y el motor de alternativas de tres niveles completo se trasladan de forma idéntica.

¿Cómo llegan los datos por destinatario a la plantilla, si no hay una fila de fuente de datos para una llamada a la API?

El objeto mergeData en el cuerpo de la solicitud hace las veces de una fila de fuente de datos — hasta 100 campos planos de clave/valor se resuelven en las etiquetas de combinación {{field}} del proyecto para esa llamada.

¿Cuál es la diferencia entre el type "transactional" y "marketing" en el mismo endpoint?

El campo type controla qué lista de supresión se verifica: transactional omite la supresión por cancelación de suscripción (un recibo aún debe llegar a alguien que canceló su suscripción de marketing) pero nunca la supresión por rebote; marketing respeta ambas.

¿Hay un límite de tasa en la API de envío?

Sí — 60 solicitudes por minuto por clave de API, además del mismo tope de volumen mensual por cuenta que comparte cualquier otra vía de envío; un encabezado Idempotency-Key evita que una solicitud reintentada envíe el correo dos veces.

¿Puedo enviar un correo HTML de formato libre por el mismo endpoint en lugar de un proyecto del estudio?

Sí — omitir projectId y en su lugar enviar html/text directamente usa el modo de formato libre, enviado tal cual sin pipeline de renderizado ni etiquetas de combinación; el modo de plantilla (con projectId) es el que lleva los bloques interactivos y el motor de alternativas.

Crea esto en el estudio

Empieza con el plan gratuito: todos los bloques interactivos y el motor de alternativas completo están incluidos en cada plan.